W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2020

Re: [csswg-drafts] [css-inline-3] Define em-top and em-bottom baselines (#5312)

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

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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:12 UTC