- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jul 2020 14:58:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Define em-top and em-bottom baselines`, and agreed to the following: * `RESOLVED: Accept the addition of the terms with the current proposed definitions.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Define em-top and em-bottom baselines<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5312<br> <TabAtkins> fantasai: The canvas API has a handful of metrics that it allows getters for<br> <TabAtkins> fantasai: They decided to defer to CSS Inline for their definitions<br> <fantasai> https://drafts.csswg.org/css-inline-3/#baseline-types<br> <TabAtkins> fantasai: We ahve a section in css-inline which defines a bunch of metrics, their opentype equivs<br> <TabAtkins> fantasai: They're taking a dependency on ascent and descent metrics for the purpose of font bounding box<br> <TabAtkins> fantasai: There's another metric in this canvas spec that we dont' have a definition for in the CSS spec<br> <fantasai> https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent<br> <TabAtkins> fantasai: So I propose we include that<br> <fantasai> fontBoundingBoxAscent/Descent<br> <TabAtkins> fantasai: Those map to our ascent/descent<br> <fantasai> emHeightAscent/Descent<br> <TabAtkins> fantasai: Then there's the em height ascent/desent<br> <fantasai> "highest top of the em squares in the inline box"<br> <TabAtkins> 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<br> <TabAtkins> fantasai: So the proposal is we define that metric, so the canvas api spec can hook into it<br> <TabAtkins> fantasai: Even if we don't end up using the metric in our own spec<br> <TabAtkins> fantasai: I talked to jfkthame about what he thinks the metric should be<br> <AmeliaBR> +1 for keeping all definitions in one place<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/5312#issue-654391546<br> <TabAtkins> fantasai: Idea is [in the issue]<br> <fantasai> Proposed definition from me and @jfkthame is:<br> <fantasai> 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)<br> <fantasai> if none of the ideographic baselines are defined, use the ascent and descent normalized proportionally so they add up to 1em<br> <TabAtkins> florian: So dont' use the actual size, but use the proportions?<br> <TabAtkins> faceless2: Lots of fonts dont' have these metrics add up to 1, so normalizing is important<br> <Rossen_> q?<br> <TabAtkins> AmeliaBR: So looks like midpoint of ascent/descent, then .5em both ways.<br> <TabAtkins> AmeliaBR: So it might be larger or smaller than ascent/descent if they weren't 1em apart originally?<br> <TabAtkins> fantasai: Yes. And bias toward the ideographic lines if they exist, they're more likely to be 1em apart<br> <TabAtkins> fantasai: They're also more likely to be in the center of where the ink falls, because they're centrally painted<br> <TabAtkins> 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.<br> <TabAtkins> Rossen_: Koji, any opinion on this?<br> <TabAtkins> koji: I generally support defining this.<br> <TabAtkins> koji: Been discussing with our canvas team aobut it<br> <TabAtkins> koji: Tehy're not really well-defined<br> <TabAtkins> koji: How to do it, I think we need more investigation/discussion.<br> <TabAtkins> koji: I'm asking in the issue some questions, and not sure what the correct way to define it is yet.<br> <TabAtkins> koji: So no concrete proposal yet, but think we need more investigation to make this move.<br> <TabAtkins> 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...<br> <TabAtkins> Rossen_: I think there's alignment behind exposing these metrics and roughly defining them as suggested<br> <TabAtkins> Rossen_: Possibly with tweaks as we adjust<br> <TabAtkins> Rossen_: Are you against that?<br> <TabAtkins> koji: Not all my questions are answered yet. Like, font top metric is visual, but we probably need to support vertical flow.<br> <Rossen_> q?<br> <TabAtkins> Rossen_: I think elika just answered that in the issue about 30s ago.<br> <TabAtkins> AmeliaBR: What is the actual use-case for these metrics? ARe we expecting people to use them to draw boxes around their text?<br> <TabAtkins> AmeliaBR: Knowing that might inform what a useful definition is.<br> <TabAtkins> fantasai: I think they'll be used to position the text.<br> <TabAtkins> Rossen_: There are more and more solutions taking a dependency on canvas today for word-like or excel-liek apps<br> <TabAtkins> Rossen_: So more and more need doing higher-fidelity typography thru canvas<br> <TabAtkins> iank_: The exact use-cases are basically "everything youc an imagine someone wanting to do when laying out text". It's pretty broad.<br> <TabAtkins> AmeliaBR: Right, the question is what this adds to the existing terms, and is this proposed dfn solving what's needed?<br> <TabAtkins> AmeliaBR: I don't know, bc I don't know what the people who added this metric were thinking about.<br> <Rossen_> q?<br> <TabAtkins> fantasai: Well the current ascent/descent metrics aren't interoperable, so one thing this adds is a consistent answer for something ascent/descent-like.<br> <TabAtkins> fantasai: The font metrics used for these differ depending on browser/OS currently.<br> <jfkthame> q+<br> <TabAtkins> fantasai: So at least in cases where we have ideographic metrics, we can get a consistent cross-platform answer here.<br> <TabAtkins> koji: This wouldn't be interoperable, right? It relies on ascent/descent.<br> <TabAtkins> fantasai: Yeah, it's just closer to interop.<br> <TabAtkins> koji: Is Gecko okay to change to match this?<br> <Rossen_> ack jfkthame<br> <TabAtkins> jfkthame: I think we'd be fine with this, it's fairly close to what Gecko already does.<br> <TabAtkins> 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.<br> <TabAtkins> jfkthame: I think there's a legit expectation for those to be 1em apart.<br> <TabAtkins> jfkthame: But it's not clear where the text falls in the em square if ascent+descent doesn't equal 1em.<br> <TabAtkins> jfkthame: So that's where this normalization comes in, giving a sensible definition to where the em square is<br> <TabAtkins> Rossen_: Do we know what current word formatters do in this case?<br> <TabAtkins> koji: There's one definition in opentype saying the ideographic em box with almost the same algo proposed here<br> <TabAtkins> koji: Except opentype says it only exists for cjk fonts, and it's udnefined otherwise<br> <TabAtkins> Rossen_: Is it a problem to define it for non-cjk?<br> <TabAtkins> koji: We tried to do some work there. When we used platform ascent/descent, it was quite bad<br> <TabAtkins> koji: We then used [s-type?] ascent/descent, we use that for underline position.<br> <TabAtkins> koji: we probably need more heuristic investigations<br> <fantasai> s/s-type?/sTypo/<br> <TabAtkins> koji: In canvas we dont' ahve font cascading, right?<br> <TabAtkins> 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.<br> <TabAtkins> AmeliaBR: Canvas does do font fallback like CSS does.<br> <TabAtkins> Rossen_: So looking for progress.<br> <castastrophe> I have to drop for a meeting, back online around noon<br> <TabAtkins> fantasai: I'm happy to put a note in saying that these metrics are for canvas, and not meant for CSS.<br> <TabAtkins> fantasai: I think we should add the terms and dfns, and note we dont' plan to use them in CSS.<br> <TabAtkins> fantasai: And then if there are changes to the algo needed, we can address that in further issues.<br> <chris_> 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<br> <TabAtkins> RESOLVED: Accept the addition of the terms with the current proposed definitions.<br> <TabAtkins> <br dur=15m>, right?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5312#issuecomment-667164455 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 July 2020 14:58:57 UTC