00:26:56 innovati has joined #css 01:07:55 innovati has joined #css 02:30:12 geheimnis` has joined #css 04:43:57 Rossen_ has joined #css 04:44:15 Rossen_ has changed the topic to: day 4 agenda: https://wiki.csswg.org/planning/virtual-summer-2020#friday 05:08:37 hober has joined #css 05:36:53 good morning heycam|away ! 05:37:06 or afternoon or whtaever 07:16:59 innovati has joined #css 07:50:17 rego has joined #css 11:52:09 plh has joined #css 13:12:34 castastrophe has joined #css 13:21:46 castastrophe has joined #css 13:51:29 Rossen_ has joined #css 13:51:50 Zakim has joined #css 13:52:02 Zakim, start meeting 13:52:02 RRSAgent, make logs Public 13:52:03 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 13:57:34 AmeliaBR has joined #css 13:58:38 present+ Rossen Atanassov, Microsoft 14:00:32 faceless2 has joined #css 14:01:45 alisonmaher has joined #css 14:01:52 present+ 14:02:13 present+ 14:02:18 present+ 14:02:27 jfkthame has joined #css 14:02:34 present+ Rossen Atanassov 14:02:35 present+ 14:02:48 present+ 14:02:51 present+ 14:04:17 dholbert has joined #css 14:04:30 present+ 14:04:32 I don't seem be able to join on video? I enter the code (***-dama-***) but then am told no-one else is here... 14:04:34 oriol has joined #css 14:04:43 present+ 14:04:51 faceless2, doing that same thing worked for me FWIW 14:05:16 present+ 14:06:17 present+ 14:09:01 ScribeNick: TabAtkins 14:09:33 Topic: Should ::first-letter include space separator? 14:09:37 github:https://github.com/w3c/csswg-drafts/issues/5154 14:09:57 drousso has joined #css 14:10:09 present+ 14:10:13 tantek has joined #css 14:10:22 present+ 14:11:00 astearns: We got the examples tantek was asking for 14:11:18 astearns: For Norwegian and the other language [French, I think], it makes sense to add those space separators, since they're in the markup 14:11:46 astearns: A little afraid of turning it on for other langs, becuase if you have an open-quote and capital letter, and all you want is the quote itself, maybe people are adding spaces to create the separation currently? 14:12:10 florian: I think dauwhe said they were inserting spaces to adjust visual separation for English content, so they would want the space included. 14:12:21 tantek: I tried to do a little more research as well. 14:12:24 tantek: Didn't have time to upload 14:12:33 [shows Elements of Typographic STyle] 14:12:49 tantek: ON p64, there's some first-letter effects with leading punct, including with guillarmes 14:13:25 tantek: So the point I'm making here is that it's not the entire thing is the first letter, it's that the punctuation is skipped over, only the letter is embiggened, then the punct is situated next to it. 14:13:36 tantek: So I'm concerned we might be doing the wrong thing. 14:13:56 astearns: There's a separate issue addressing that layout, and the current suggestion to get that addressed requires the punct to be part of the ::first-letter 14:14:08 q+ 14:14:09 tantek: Ok [shows an example in English too]. Maybe we should consider these issues together. 14:14:19 It's issue 2040 14:14:22 astearns: I'll drop it in the minutes. 14:14:56 ack fantasai 14:15:16 fantasai: So this is about whether we include the space *when* there is a quotation mark, not about the quotation mark itself. 14:15:24 fantasai: If we want French and English to be the same, we need to include it. 14:15:37 there is also https://github.com/w3c/csswg-drafts/issues/4988 for changing size of components of initial-letter 14:15:39 fantasai: As astearns said, 2040 is about the formatting question if you want the punct and letter different. 14:15:54 q? 14:16:01 fantasai: Richard said we didn't need to include U+0020 space, becuase the spaces used here are typically other spaces, not the standard word separator. 14:16:06 q+ to comment on U+0020 14:16:17 fantasai: So if we're really concerned, we cna exclude u+0020 and only include the other spaces. 14:16:32 fantasai: And note that the punct by itself wont' be picked up as a ::first-letter anyway; you need a letter. 14:16:45 AmeliaBR: I'm not sure about ignoring u+0020, lots of people will type this with a stadnard space 14:16:48 ack AmeliaBR 14:16:53 AmeliaBR: But probably the more exotic spaces can be ignored. 14:17:03 chris_ has joined #css 14:17:16 present+ 14:17:29 AmeliaBR: The one common thing from tantek's examples, and some in the issue, where the initial punct is different than the letter, they all have the letter as big. So to do that, we at least need the characters up to the letter to be included. 14:17:39 rrsagent, here 14:17:39 See https://www.w3.org/2020/07/31-css-irc#T14-17-39 14:17:42 Anyone who's fussy about typography will use the correct space, I think :) 14:18:00 AmeliaBR: If we dont' come up with a special solution for people who want the punct to be offset or smaller, there's always the option of people including spans to mark off certain characters. 14:18:09 ack florian 14:18:09 florian, you wanted to comment on U+0020 14:18:12 if I paste this here does it work? https://github.com/w3c/csswg-drafts/issues/2040 14:18:20 florian: Good guides about typography will say to use various spaces, but most people dont' know how to type those. 14:18:29 I think we should allow the regular space, even though I'm fussy about typography 14:18:37 florian: At least in French, it's pretty common to say ordinary spaces, probably same in Norwegian. So I'd include standard space. 14:18:47 q? 14:19:19 tantek: My concern is that if we just flip this on, we'll cause pages that have not been tested with this to suddenly have first-letters that didn't before. 14:19:31 tantek: And end up with big punctuation as well as big letters. 14:19:42 tantek: That might come as a surprise to authors who are used to not doing that automatically. 14:19:47 tantek: And I'm not sure it's the right default. 14:20:08 tantek: So if it is punct-space-letter, maybe the letter itself should be the only thing included as the ::first-letter, and the pucnt gets normal inline styling. 14:20:10 fremy has joined #css 14:20:16 tantek: That would look closer tothe typography examples. 14:20:19 q+ 14:20:28 tantek: I'm concerned we have yet another place where we do the wrong thing typographically by default. 14:20:44 tantek: The web has a tradition of this, liek the way large text messes up the line rhythm. 14:20:48 so now we need a term for "the characters before the first actual letter"? 14:20:53 tantek: So I'm concerned if we add one more papercut. 14:21:10 chris_, we need a pseudo-element, yes :) 14:21:13 q+ 14:21:24 tantek: 5154 shows what browsers are currently doing 14:21:48 tantek: There's an example with th eleading quote... [missed] 14:22:06 ack fantasai 14:22:10 fantasai: I think tantek is getting caught up in the not-perfect 14:22:14 in the examples provided for this issue, the punctuation *does* take the same styling as the letter: https://github.com/w3c/csswg-drafts/issues/5154#issuecomment-659129316 14:22:16 ::first-letter-before 14:22:21 fantasai: I think you're forgetting that English and French punct have the same problem and have to be treated the same way 14:22:35 ack florian 14:22:36 fantasai: We need to include the space to keep these on-par, and having them be inconsistent is bad 14:23:02 florian: Having ::firs-tletter select the letter and not the preceding punct seems bad, it's already complicated, sounds scary. 14:23:03 s/bad/bad and doesn't solve those problems anyway/ 14:23:20 florian: As to compat, Safari does it already. So there's some amount of content out there probably already depending on it. 14:23:20 http://www.typografi.org/dropcaps/assets/sitatstrek-anf%C3%B8rselstegn_714.jpg 14:23:30 florian: So in this example we actually do want the included thing to be large. 14:23:47 florian: In other cases we wont' want the punct large, but those apply equally to the exisdting punct-letter without space. 14:24:05 TabAtkins: Florian touched on it at the end, one of the big concerns Tantek brought up 14:24:12 TabAtkins: is wanting to address differently-sized punctuation wrt first-letter 14:24:26 TabAtkins: But that's already the case. If there's no space, we already have that problem, already have to solve it. 14:24:32 TabAtkins: It's not relevant to this issue. 14:24:35 ack TabAtkins 14:25:15 Rossen_: So I think there were several reasons for ahving this, including some existing shipping impls 14:25:23 Rossen_: So it's probably not a compat risk, or at least not a big one. 14:25:24 q+ 14:25:48 ack tantek 14:25:54 tantek: I don't actuallys ee the Safari example as proof of no compat problem 14:26:02 tantek: Safari applies all th epunct as well. 14:26:19 tantek: It wouldn't surprise me if there's special-casing going on here, looks like impl by accident. 14:26:27 tantek: Looking at an example with a massive preceding dash. 14:26:39 tantek: It woudlnt' surprise me if people are already not giving that styling to Safari to avoid that problem. 14:26:51 astearns: Also in CHrome 14:27:01 Slight tangent, but while testing I discovered that browsers treat quotes in the markup different from quotes inserted via `::before { content: open-quote }`. Is that expected, or just part of all the bugs? 14:27:02 tantek: Ok. So that's a bug, and I dont' thinkw e should be designing based on a bug. 14:27:11 q 14:27:14 florian: We're not saying it's a bug, we're saying it's desirable. 14:27:26 tantek: I'm talking justa bout the hyphen. 14:27:51 tantek: Because of that I think authors might be picking different techniques. So maybe we dont' have a compat problem at all then, because nobody's using it. 14:28:06 florian: If there is a real compat problem we'll find tou and revisit 14:28:17 faceless2: The big hyphen was actually a desired effect 14:28:25 http://www.typografi.org/dropcaps/assets/sitatstrek-anførselstegn_714.jpg 14:28:26 s/tou/out/ 14:28:47 tantek: I'm convinced by the examples, we shoudl do this, but we should make it dependent on solving 2040 14:28:53 tantek: That would be my compromise proposal 14:28:59 tantek: I think this group can solve that. 14:29:24 fantasai: We need to do one thing at a time. These are two separate features that happen to work together. 14:29:39 fantasai: So let's just get opening quotes working the same between langs. 14:29:59 present+ 14:30:15 tantek: They're both ::first-letter 14:30:28 [back and forth] 14:30:43 q? 14:30:52 +1 to resolving on this now 14:31:01 TabAtkins: Today, a single quote and no space, will be combined together. 14:31:13 TabAtkins: and the quote won't be sized "correctly" in that case either. 14:32:18 Rossen_: Okay, so it sounds like people are all okay with the proposal as it exists. Tantek, you had an objection based on no examples; we now have those. Do you still object? 14:32:44 tantek: I strongly prefer that we make this resolution dependent on 2040, but I won't object. 14:33:10 Rossen_: So any objections? 14:33:28 RESOLVED: Spaces separating punct from first letter dont' stop ::first-letter 14:34:18 Topic: Define em-top and em-bottom baselines 14:35:03 github: https://github.com/w3c/csswg-drafts/issues/5312 14:35:41 fantasai: The canvas API has a handful of metrics that it allows getters for 14:35:55 fantasai: They decided to defer to CSS Inline for their definitions 14:35:55 https://drafts.csswg.org/css-inline-3/#baseline-types 14:36:08 fantasai: We ahve a section in css-inline which defines a bunch of metrics, their opentype equivs 14:36:21 fantasai: They're taking a dependency on ascent and descent metrics for the purpose of font bounding box 14:36:33 fantasai: There's another metric in this canvas spec that we dont' have a definition for in the CSS spec 14:36:37 https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent 14:36:38 fantasai: So I propose we include that 14:36:47 fontBoundingBoxAscent/Descent 14:36:56 fantasai: Those map to our ascent/descent 14:37:09 emHeightAscent/Descent 14:37:09 fantasai: Then there's the em height ascent/desent 14:37:26 "highest top of the em squares in the inline box" 14:37:33 fantasai: Which don't have a definition in HTML; the deifnition is "to the highest top of the em squares in the inline box", and I'm not sure what that really means 14:37:45 fantasai: So the proposal is we define that metric, so the canvas api spec can hook into it 14:37:53 fantasai: Even if we don't end up using the metric in our own spec 14:38:00 fantasai: I talked to jfkthame about what he thinks the metric should be 14:38:03 +1 for keeping all definitions in one place 14:38:24 https://github.com/w3c/csswg-drafts/issues/5312#issue-654391546 14:38:29 fantasai: Idea is [in the issue] 14:38:29 Proposed definition from me and @jfkthame is: 14:38:29 if the ideographic-top + ideographic-bottom or ideographic-central baselines are defined by the font, emHeightAscent is 0.5em above the ideographic-central and emHeightDescent is 0.5em below. (This will normally make ideographic-top = emHeightAscent and ideographic-bottom = emHeightDescent, but if ideographic-top and ideographic-bottom are not 1em apart it will normalize the distance to 1em) 14:38:35 if none of the ideographic baselines are defined, use the ascent and descent normalized proportionally so they add up to 1em 14:39:04 florian: So dont' use the actual size, but use the proportions? 14:39:18 faceless2: Lots of fonts dont' have these metrics add up to 1, so normalizing is important 14:39:19 q? 14:39:29 AmeliaBR: So looks like midpoint of ascent/descent, then .5em both ways. 14:39:43 AmeliaBR: So it might be larger or smaller than ascent/descent if they weren't 1em apart originally? 14:40:00 fantasai: Yes. And bias toward the ideographic lines if they exist, they're more likely to be 1em apart 14:40:24 fantasai: They're also more likely to be in the center of where the ink falls, because they're centrally painted 14:40:46 fantasai: It works out well for CJK, and it works out fine for other writing system so long as these metrics are halfway reasonably defined. 14:41:06 Rossen_: Koji, any opinion on this? 14:41:29 koji: I generally support defining this. 14:41:37 koji: Been discussing with our canvas team aobut it 14:41:45 koji: Tehy're not really well-defined 14:42:00 koji: How to do it, I think we need more investigation/discussion. 14:42:22 koji: I'm asking in the issue some questions, and not sure what the correct way to define it is yet. 14:42:35 koji: So no concrete proposal yet, but think we need more investigation to make this move. 14:43:00 Rossen_: If the current approach is something we can resolve for now, and then refine as we go if we identify it's not the precise math we need... 14:43:13 Rossen_: I think there's alignment behind exposing these metrics and roughly defining them as suggested 14:43:23 Rossen_: Possibly with tweaks as we adjust 14:43:30 Rossen_: Are you against that? 14:43:47 dlibby has joined #css 14:44:01 koji: Not all my questions are answered yet. Like, font top metric is visual, but we probably need to support vertical flow. 14:44:10 q? 14:44:19 Rossen_: I think elika just answered that in the issue about 30s ago. 14:44:47 AmeliaBR: What is the actual use-case for these metrics? ARe we expecting people to use them to draw boxes around their text? 14:44:56 AmeliaBR: Knowing that might inform what a useful definition is. 14:45:02 fantasai: I think they'll be used to position the text. 14:45:27 Rossen_: There are more and more solutions taking a dependency on canvas today for word-like or excel-liek apps 14:45:42 Rossen_: So more and more need doing higher-fidelity typography thru canvas 14:46:26 iank_: The exact use-cases are basically "everything youc an imagine someone wanting to do when laying out text". It's pretty broad. 14:46:51 AmeliaBR: Right, the question is what this adds to the existing terms, and is this proposed dfn solving what's needed? 14:47:05 AmeliaBR: I don't know, bc I don't know what the people who added this metric were thinking about. 14:47:10 q? 14:47:37 fantasai: Well the current ascent/descent metrics aren't interoperable, so one thing this adds is a consistent answer for something ascent/descent-like. 14:47:52 fantasai: The font metrics used for these differ depending on browser/OS currently. 14:48:09 q+ 14:48:12 fantasai: So at least in cases where we have ideographic metrics, we can get a consistent cross-platform answer here. 14:48:27 koji: This wouldn't be interoperable, right? It relies on ascent/descent. 14:48:36 fantasai: Yeah, it's just closer to interop. 14:48:52 koji: Is Gecko okay to change to match this? 14:49:06 ack jfkthame 14:49:06 jfkthame: I think we'd be fine with this, it's fairly close to what Gecko already does. 14:49:56 jfkthame: I think omst of the use-cases are better served by canvas's ascent/descent metrics, but those don't necessarily add up to 1em, and there's a legacy expectation that canvas text baseline has a top/bottom values which are specified to be the top and bottom of the em square. 14:50:11 jfkthame: I think there's a legit expectation for those to be 1em apart. 14:50:27 jfkthame: But it's not clear where the text falls in the em square if ascent+descent doesn't equal 1em. 14:50:44 jfkthame: So that's where this normalization comes in, giving a sensible definition to where the em square is 14:50:54 Rossen_: Do we know what current word formatters do in this case? 14:51:47 koji: There's one definition in opentype saying the ideographic em box with almost the same algo proposed here 14:51:57 koji: Except opentype says it only exists for cjk fonts, and it's udnefined otherwise 14:52:28 Rossen_: Is it a problem to define it for non-cjk? 14:52:39 koji: We tried to do some work there. When we used platform ascent/descent, it was quite bad 14:53:03 koji: We then used [s-type?] ascent/descent, we use that for underline position. 14:53:10 koji: we probably need more heuristic investigations 14:53:16 s/s-type?/sTypo/ 14:53:22 koji: In canvas we dont' ahve font cascading, right? 14:53:50 koji: So if we define this in CSS, this is okay for the primary font, but going to the fallback algo would be bad. I'm concerned about that. 14:54:01 AmeliaBR: Canvas does do font fallback like CSS does. 14:54:33 Rossen_: So looking for progress. 14:55:07 I have to drop for a meeting, back online around noon 14:55:18 fantasai: I'm happy to put a note in saying that these metrics are for canvas, and not meant for CSS. 14:55:38 smfr has joined #css 14:55:40 fantasai: I think we should add the terms and dfns, and note we dont' plan to use them in CSS. 14:55:49 fantasai: And then if there are changes to the algo needed, we can address that in further issues. 14:56:37 Rossen, for the CSS OM Color item, Lea and I would like to present our work before the discussion opens up. About 10 minutes should do it. [10:56] == Rossen is away: Away 14:56:41 RESOLVED: Accept the addition of the terms with the current proposed definitions. 14:57:07
, right? 14:58:53 Topic: end 15:02:02 dlibby has joined #css 15:10:51 Topic: initial-letter alignment with overflow:sunk 15:10:55 github:https://github.com/w3c/csswg-drafts/issues/5329 15:11:14 s/overflow:sunk/over-sunk letter/ 15:11:16 s/with overflow:sunk/when over-sunk/ 15:11:44 faceless2: When you have an initial-letter smaller than the space given, how do you align it within that gap? 15:11:54 faceless2: Existing spec aligns it to the bottom, elika proposes we change it to the top 15:12:04 fantasai: It fixes a use-case I had for indic scripts, and the OP's case which is Latin 15:12:32 fantasai: The proposal is to do this when the size is less than the sink value. 15:12:52 fantasai: If size is > sink, we want to align to the bottom metric, because we want the top of the letter to be above th eparagraph 15:13:04 fantasai: But when size < sink, we align to the top metric so we're pulling up 15:13:21 florian: And the initial dfn just only considered one case and we forgot the secon dhalf? 15:13:24 fantasai: pretty mcuh 15:13:29 Rossen_: Any other opinions? 15:14:06 RESOLVED: When 'over-sunk', an initial-letter is aligned with the top metrics instead. 15:14:21 Topic: end 15:14:54 ScribeNick: fantasai 15:14:56 Topic: Houdini 15:15:16 s/Houdini/Houdini Layout/ 15:15:53 Topic: String based inline layout API 15:16:08 github:https://github.com/w3c/css-houdini-drafts/issues/990 15:16:38 Rossen_: More and more desire to be able to perform typographic text layout from Canvas 15:16:58 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Canvas/FormattedText.md 15:17:01 Rossen_: There were some proposals put forward to essentially expose API in the platform that will allow developers to do that 15:17:04 Rossen_: e.g. ^ 15:17:26 Rossen_: When I looked at it, and when we discussed it, my initial reaction was, hey, we have Houdini, and Houdini Custom Layout API was intended to handle exactly this 15:17:53 Rossen_: Overall idea, instead of performing layout that is based on a particular subsection of DOM that has text, inline markup, etc. 15:18:11 Rossen_: Instead expose an API that simply, for custom layout or maybe different API, takes as input a string 15:18:17 Rossen_: and does layout into the given space 15:18:24 Rossen_: If Houdini is not able to handle this, we are failing this on some higher level 15:18:46 Rossen_: So talked about it with iank_ and he expanded in the issue why this makes perfect sense and is good fit for the API 15:18:55 Rossen_: Since then see that some additional comments by Travis and ? 15:19:00 Rossen_: from Edge Team 15:19:15 q+ 15:19:16 Rossen_: and I wanted to essentially turn this into a question and ask, does it seem like a reasonable API? 15:19:37 q+ 15:19:43 Rossen_: Is this a good API to add, given intended functionality? 15:19:59 Rossen_: Will it serve the purpose motivating the other proposal? 15:20:32 AmeliaBR: Ian had a question in the issue about, once you've laid out, how do you query back the position of content? 15:20:43 AmeliaBR: If you're going down that road, might look at APIs from SVG 15:20:56 AmeliaBR: Can't promise they'll be all you want, but if can harmonize it's better 15:21:10 AmeliaBR: More specifically on the proposal, like the idea of being able to run layout separately from full CSS layout context 15:21:18 AmeliaBR: And re-using Houdini Layout APIs sounds good 15:21:27 AmeliaBR: I'm concerned about being based on simple text strings 15:21:37 AmeliaBR: As soon as you go beyond the simplest things, need annotations 15:21:56 AmeliaBR: Need info on languages, need markup for bidi, going to need nest it with italic phrase inside regular text phrase, etc. 15:21:58 q+ 15:22:07 AmeliaBR: So it might be better to keep thinking of styling a DOM fragment 15:22:17 AmeliaBR: but DOM fragment doesn't necessarily need to be attached to the document 15:22:26 AmeliaBR: Because you will need some hierarchy of content 15:22:40 Rossen_: what you're asking for already exists, just extending to handle string only 15:22:40 ack AmeliaBR 15:23:04 ack fremy 15:23:11 fremy: One issue of doing with strings is, if you have ? such as text selection 15:23:17 fremy: Doesn't work if you don't have something in the DOM to select 15:23:22 fremy: Don't know the use case for the text 15:23:32 fremy: But selection is something users expect, and problematic if we can't handle selection 15:23:41 fremy: But at the same time, think about what Amelia said 15:23:47 fremy: if you have something in the DOM to represent the string 15:23:54 fremy: [something about spans] 15:24:00 fremy: If in the DOM, you can copy and paste, etc. 15:24:11 fremy: A lot of times you don't want to have everything possible in CSS 15:24:17 fremy: Sounds useful in many cases 15:24:31 sushanth has joined #css 15:24:33 ack iank_ 15:24:49 iank_: The linked formatted text explainer is much more well thought out 15:24:52 iank_: and seems pretty good 15:25:01 iank_: Amelia brought up point wrt doing on document fragments 15:25:09 iank_: Issue there is, this API wanted to work inside of workers 15:25:13 iank_: because have the Canvas API 15:25:23 iank_: I don't think needs that much of hierarchy 15:25:34 iank_: styling particular runs is roughly equivalent to structured hierarchy 15:25:35 q+ 15:25:43 iank_: One thing to think about there is bidi reordering, though 15:25:55 iank_: To harmonize APIs 15:26:04 iank_: call out some core ? or mixins that can be shared between the APIs 15:26:09 iank_: Once you have a line of text, what info can you query? 15:26:22 q 15:26:25 iank_: no reason they should be different 15:27:16 ??: Motivation was apps, like photoshop / excel 15:27:30 sushanth: API was trying to give them ability to do multiline text 15:27:31 s/??/sushanth/ 15:27:42 sushanth: Houdini, they have control over canvas context they'd want text to be rendered? 15:27:47 sushanth: Paint Worklet, Houdini controls context 15:27:57 sushanth: but these cases rendering other things, just want a few lines of text 15:28:12 sushanth: In terms of measuring API, we went towards existing Canvas Text Metrics API 15:28:17 sushanth: exposes same set of things 15:28:31 sushanth: Not the same as SVG, but has precedence on having some APIs 15:28:35 sushanth: Chromium has advances as well 15:28:43 q+ 15:28:55 sushanth: I think last question, selection / background / borders missing from this API 15:29:02 sushanth: with metrics can implement this 15:29:06 sushanth: in JS 15:29:12 q? 15:29:13 sushanth: Just wanted basic multiline text 15:29:46 jfkthame: I wanted to comment that what I've seen of the text metrics API for canvas there, particularly advances from Chromium, that really does not address the needs of international text well 15:30:00 jfkthame: Does not handle that one character can map to arbitrary number of glyphs and vice versa 15:30:36 jfkthame: the mapping between glyphs and characters can be quite complex, and it doesn't handle that 15:30:54 Rossen__ has joined #css 15:30:57 q? 15:31:21 AmeliaBR: Hadn't clicked through to explainer previously, and only saw the examples in the issue. Explainer looks like a much more complex model, allows annotations 15:31:33 AmeliaBR: if that's extended to handle i18n issues, that's a good start [wrt bidi and lang?] 15:31:41 AmeliaBR: Might be useful to export a DOM fragment to this format 15:31:49 AmeliaBR: so if you have CSS-styled markup in Canvas Shadow DOM or in your SVG 15:32:01 AmeliaBR: and want to run through this API to get layout, would be a great feature 15:32:11 q 15:32:21 q+ 15:32:53 Rossen__: SVG has had this capability request for the longest time 15:33:04 Rossen__: some such as inkscape that support, no renderers 15:33:09 Rossen__: Want it in Canvas 15:33:20 Rossen__: If for every one of these [sound breaks] 15:34:35 AmeliaBR: He was talking about how SVG has long wanted formatted multiline text, haven't been able to get implemented in browsers, so will be very jealous if Canvas gets it before we do 15:34:41 ack sushanth 15:34:53 sushanth: Point about advances in text metrics, it's incomplete 15:34:58 sushanth: flag to get it to wokr 15:35:04 sushanth: Does handle multiple glyphs per characters 15:35:15 sushanth: We augmented with hierarchy to allow advances within ? 15:35:48 Guest60 has joined #css 15:35:49 sushanth: It addresses multiple chars into single glyph is that it gives you the same advance value 15:35:54 present+ 15:35:59 sushanth: They'll all have the same advance value 15:36:06 present+ 15:36:09 sushanth: advance = position from the start 15:36:11 Rossen___ has joined #css 15:36:24 q? 15:36:24 jfkthame: That won't be any different than a zero-width character right? 15:36:26 This is similar to how the SVG API works: multiple characters will match to the same glyph box 15:36:28 sushanth: true 15:36:35 sushanth: Some other issues also? 15:36:50 Rossen__: Main point I wanted to make before network drop... 15:37:01 Rossen__: If we're not looking for ways to harmonize Houdini APIs with rest of platform 15:37:15 Rossen__: failing main use case of exposing ? to other things like Canvas and SVG 15:37:31 s/?/text layout/ 15:37:31 Rossen__: As we all know, text seems very benign and easy, when you thinking only about a few ascii glyphs 15:37:39 Rossen__: breaks based on simple logic 15:37:42 Rossen__: Things get increasingly complex 15:37:51 Rossen__: to the point where you're mostly ending up re-implementing layout for CSS 15:37:57 Rossen__: which now intended to be exposed as Houdini APIs 15:38:01 q+ 15:38:15 ack fantasai 15:38:16 fantasai, you wanted to ask us to get Myles's opinion before signing off on anything like this 15:38:29 q+ 15:38:41 fantasai: Just wanted to say, I echo concerns about getting i18n right. 15:38:49 q- 15:38:49 q+ 15:38:54 fantasai: Also want to say, I would be very uncomfortable resolving to add a new major text API without Myles signing off 15:39:05 fremy: Was thinking about use case, the idea is to run this in workers 15:39:10 fremy: because can't ? directly 15:39:21 fremy: So that's why don't want to take something from the DOM and draw it 15:39:23 s/?/access the DOM/ 15:39:27 fremy: ... 15:39:34 fremy: HTML content and canvas can automatically update 15:39:37