- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Jan 2020 11:37:31 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `make text of leading-trim interoperable?`, and agreed to the following:
* `RESOLVED: Spec that text-top/bottom and background boxes of inlines ought to match`
* `RESOLVED: make leading-trim's text value match the same value for text-top/text-bottom/etc`
<details><summary>The full IRC log of that discussion</summary>
<emilio> Topic: make text of leading-trim interoperable?<br>
<RossenF2F> github:https://github.com/w3c/csswg-drafts/issues/3978<br>
<fantasai> https://drafts.csswg.org/css-inline-3/#leading-trim-property<br>
<emilio> fantasai: we have some proposals in the early-brainstorming phases, and one of them is leading-trim which allows you to visually align some text so that it's aligned with the top of an image or such<br>
<emilio> ... there's several values like cap-height x-height etc<br>
<emilio> ... and the normal one which is laying out the text and then add the half-leading<br>
<emilio> ... but there's also leading-trim which doesn't add the half-leading<br>
<emilio> ... koji pointed out that these metrics don't have interop<br>
<emilio> ... so if we did trim out the half-leading above and below the text we'd probably get no interop<br>
<emilio> florian: can you clarify what's not interoperable? I think unless you use line-height normal stuff should mostly match<br>
<emilio> fantasai: different browsers use different font-metrics<br>
<emilio> ... I don't have a solution and don't understand the full issue from koji, but I hope we can close it somehow<br>
<emilio> koji: in the current implementation stuff is not interoperable. I'd like to ask about jfkthame and myles' opinion if any<br>
<emilio> jfkthame: I don't have an answer here, it's not clear to me there'd be any useful metric for text-top value because the metrics in font vary considerably across fonts<br>
<emilio> ... so the ascender in a font may or may not what you actually want. It may correspond to the ascenders of some glyphs, but it may instead have been defined to allow for accents are such<br>
<emilio> ... so that's probably not what you want as a designer<br>
<emilio> ... not clear there's a good answer<br>
<emilio> fantasai: there's vertical-align: text-{top,bottom}, we should probably be consistent with them<br>
<emilio> jfkthame: I'd bet that's not interoperable<br>
<RossenF2F> q?<br>
<emilio> koji: jfkthame is right, even with the same font Chrome peeks different ascent behavior in mac / windows to match platform behavior<br>
<myles> q+<br>
<fantasai> s/even/but even/<br>
<emilio> ... I'd like browsers to match at least given the same font binary<br>
<emilio> faceless: we've been trying to figure out what browsers do<br>
<emilio> ... we find different behavior between FF and Chrome when a font specifies a zero line-gap in OS/2<br>
<emilio> ... not sure if this is about<br>
<emilio> fantasai: that's probably the answer for why line-height is not interoperable. But this feature should probably not use line-gap<br>
<RossenF2F> ack myles<br>
<fantasai> s/line-height/line-height: normal/<br>
<emilio> myles: there's content out there that places elements so that they match up what the browser does... Whatever we do, let's say we add some switch to have an interoperable metric. It probably can't be default behavior<br>
<emilio> fantasai: this is opt-in<br>
<fantasai> initial value is auto, which just does the usual thing with half-leading and whatever<br>
<fantasai> s/auto/normal/<br>
<emilio> stantonm: I think if you give authors the ability to do this even for a particular case of having a font it'd be nice<br>
<emilio> myles: there are three ascent/descend pairs in fonts, I don't think we want three options<br>
<emilio> koji: I agree... Any specific set you can accept?<br>
<emilio> myles: not particularly, I just have like a general aversion to parsing font files, and any interoperable solution requires code that parses font files, and that makes me sad myles<br>
<emilio> hober: in terms of a general principle I think there's a good thing that browser engines can rely on other platform frameworks<br>
<emilio> ... the job of parsing fonts is the job of the font library not the browsers<br>
<emilio> fantasai: can you pull out the cap height and such metrics?<br>
<emilio> myles: I think the best answer is we work very closely with coretext<br>
<emilio> fantasai: one of the goals of these features is exposing the values the font author has chosen, the remaining issue is that which metrics are not interoperably chosen across platforms, so we'd hit the issue of authors hitting different results on different platforms<br>
<emilio> ... I have two related concerns here: Can we give authors an interoperable way to strip the half-leading? If not, can we strip the half leading without stripping down all the way to the cap height?<br>
<emilio> myles: Not 100% sure about the question but I don't think we can change default text rendering<br>
<emilio> fantasai: we're not proposing that<br>
<emilio> ... one of the features that we drafted is that you remove the half leading so that you get to align with the specified line-height<br>
<emilio> ... I think we have two options, either figure out an interoperable metric<br>
<emilio> ... or drop this value<br>
<fantasai> https://drafts.csswg.org/css-inline-3/#propdef-leading-trim-over<br>
<emilio> florian: right now, the total size you add after the leading is well defined, but the leading itself is not interoperable so we don't know the starting point<br>
<emilio> fantasai: there's several places where the top and bottom edge of the text comes into play<br>
<emilio> ... one is vertical alignment<br>
<emilio> ... the other is when we're trying to draw backgrounds and borders<br>
<emilio> ... so the content box edges of the inline<br>
<emilio> ... I don't think that's well defined<br>
<emilio> koji: canvas exposes this but I don't think it's interoperable<br>
<dbaron> s/canvas/canvas TextMetrics/<br>
<emilio> fantasai: the last one is vertical-align text-{top,bottom}<br>
<emilio> ... but I don't know what they do<br>
<emilio> ... so I don't know what to put in the spec<br>
<emilio> myles: so if text layout is different between browsers, is it so bad that these new properties are also different between browsers? we're already in this world<br>
<emilio> fantasai: I think authors want a little bit more control / consistency about what's happening in the documents<br>
<RossenF2F> q?<br>
<RossenF2F> ack dbaron<br>
<emilio> ... the other thing is that I'm supposed to write the spec for these things, and I don't know what to put in them right now<br>
<emilio> dbaron: myles has asked about the lack of interop. I think that causes real bugs for minority browsers<br>
<emilio> ... like cases where a minimal amount of space perturbs the whole layout<br>
<emilio> ... we do hit these things occasionally, probably a bit less during the last few years, probably because of the choice of layout techniques people are using lately is changing<br>
<emilio> RossenF2F: but that's not true for the long tail of the web<br>
<RossenF2F> +1 to dbaron<br>
<emilio> dbaron: there's another source of lack of interop about how you deal with all these sizes for text / inlines when these things have multiple fonts in them<br>
<RossenF2F> q?<br>
<emilio> ... sort of the same points fantasai mentions but even more complicated and less interoperable<br>
<emilio> ... so probably worth separating it<br>
<emilio> fantasai: we can also drop the feature of leading-trim that allows you to drop the half-leading<br>
<emilio> ... but I'd still have the issue of text-top/text-bottom<br>
<dbaron> s/perturbs the whole layout/perturbs the whole layout (e.g., if going from 20px high to 21px high bumps into a float and moves it to a totally different position)/<br>
<emilio> florian: with flex / grid people can do more robust design and they're more likely to start trying improve typography, and then these interop differences are more likely to come up<br>
<dbaron> s/another source of lack of interop/another source of lack of interop (which we discussed when we last met at Keio University in Tokyo)/<br>
<emilio> fantasai: what do people do for text-top / text-bottom<br>
<emilio> ?<br>
<emilio> hober: myles described a simple way to do this with information you already have in the engine. Can we specify that as a baseline?<br>
<emilio> RossenF2F: what's that?<br>
<emilio> myles: that's using the ascent / descent that you already have during text layout<br>
<emilio> RossenF2F: that feels like "keep doing what you're doing", which may be fine but I want to clarify what you're trying to say<br>
<emilio> myles: I agree that interoperability is good<br>
<emilio> ... but I think there are constraints that make that difficult<br>
<emilio> ... I also think that this is worth a warning on the spec given this is a new feature<br>
<emilio> florian: so this is about using text-top/text-bottom, whatever they're currently doing right?<br>
<emilio> ... but that's exactly about what this issue is about<br>
<myles> s/I also think that this is worth a warning on the spec given this is a new feature//<br>
<emilio> koji: I think we need at least one interoperable value<br>
<emilio> ... so that authors can have control<br>
<emilio> myles: in some other issue I proposed somewhere else is additional descriptors in @font-face<br>
<emilio> ... that the browser could use<br>
<emilio> faceless: for fonts that have incorrect info that'd be of huge help<br>
<emilio> myles: and that also allows avoiding to parse font files<br>
<emilio> hober: that is a good idea, I think<br>
<emilio> koji: I'm fine with that<br>
<emilio> florian: so you'd add descriptors for where the text-top / text-bottom are and the browser would use these values<br>
<emilio> ... everywhere<br>
<emilio> ... seems worth looking into<br>
<emilio> myles: it's in some comment of some issue a long time ago, can dig it up<br>
<fantasai> testcase for content-edge vs vertical-align: text-top http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7710<br>
<emilio> florian: if we manage to characterize how these behaviors differ we could let authors choose<br>
<emilio> myles: that'd reintroduce the problem of parsing font files<br>
<emilio> fantasai: so we should open an issue about this against fonts-5, and that'd get rid of the interoperability<br>
<emilio> ... the other thing is how we define how to use these metrics<br>
<emilio> ... at least in Firefox on Linux the text-top edge seems to be the same as the background of the inline, so if that happens in other platforms we can specify that they have to match<br>
<emilio> fremy: they don't seem to match in Chrome<br>
<emilio> florian: It matches here<br>
<emilio> koji: I think it can change across OSes<br>
<emilio> fantasai: does it match on Safari?<br>
<emilio> florian: yeah, looks like<br>
<emilio> dbaron: they don't see to match by a pixel in Firefox here, but might be a pixel-snapping issue<br>
<emilio> fantasai: I'd like to resolve that text-top and the background-box of inlines use the same metrics<br>
<fremy> (I want to clarify, that neither Chrome nor Firefox do match on my Windows device)<br>
<dbaron> (I see a 1px mismatch for the serif example.)<br>
<emilio> ... can we resolve that they ought to match<br>
<emilio> florian: so the non-matching behavior is something we want to fix?<br>
<emilio> dbaron: we could try to understand why they don't match first<br>
<emilio> RossenF2F: but the intent is pretty good modulo bugs/rounding issues<br>
<emilio> RESOLVED: Spec that text-top/bottom and background boxes of inlines ought to match<br>
<emilio> RESOLVED: make leading-trim's text value match the same value for text-top/text-bottom/etc<br>
<tantek> both really hoping this works / happy to see this from a web author perspective, and frankly a bit suspicious about odd pixel compat issues that will show up when this stuff gets tweaked in implementations<br>
<emilio> fantasai: we should try to request vendors to describe what's happening to have better spec text<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3978#issuecomment-578095991 using your GitHub account
Received on Friday, 24 January 2020 11:37:33 UTC