[css-inline-3] make text of leading-trim interoperable?
#3978
Labels
Comments
This isn’t quite an accurate characterization. I said it didn’t sound like a bad idea; I didn’t say I want it. |
|
Oh, sorry and thank you, apparently I misunderstood, apologies and thank you for clarifying that. @fantasai was hesitant to support platform-specific text metrics in this new property, I'm happy to go without it. |
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: make `text` of `leading-trim` interoperable?<fantasai> I think the issue was https://github.com//issues/674#issuecomment-333541595 <dael> github: https://github.com//issues/3978 <dael> astearns: This is F2F leftover <dael> koji: The leading-trim has text repesenting text-topa nd text-bottom. text-top and -bottom isn't browser interop or even on same browser across OSs. prop is to define. One prop is to use specific asender and descender. Another is em height. This isn't defined in CSS but algo is from geck <dael> koji: Seems to do a good job for non-tall scripts <dael> fantasai: I don't think I agree with a platform text value for this metric. I think people looking to trima re looking for a particular value. Does make sense to have other two, ascent, descent and em height. If we want to define an existing keyword to do that or add a new I'm less sure <dael> fantasai: Interesting question of these metrics which do we want <dael> myles: Like to not parse tables myself. Likely look up the functions. not sure if that defetes purpose. <dael> fantasai: It means you cant read the metrics? <dael> myles: Can but takes a lot of code to get the table and figure out the values and convert <dael> koji: If you call core text ascendant and descendant aren't interop <fantasai> s/metrics/sTypo metrics/ <dael> myles: If there was a interop field we prop would jsut hook that field up to core text field which deferts purpose of interop field so that's unfortunate <dael> koji: Clarify, the division of leading trim where authors use webfonts so it's the same bianary on all platforms and borwsers. If they use font-top they see different layout result. For this property I think having the same result for same font value is quite important <fantasai> +1 to koji <dael> astearns: Your last comment is that if for whatever reason web font is serving two values typo text won't be interop if metrics are different in font files. We're looking for interop if same font files is served. <dael> astearns: I don't know if it's the case that if you have the same font file that the different text rendering systems will us OS2 table data <dael> chris: Probably not. Was the case that they all used different tables <dael> astearns: So even if we do spec that you have to get data out of font file we'd still end up with bad interop due to different text rendering <dael> koji: Could be differences of rounding. Most of difference in font metrics comes from open type fonts having 3 different metrics and each platform uses different of 3. If browsers use same metrics should be interop <dael> astearns: I'm not sure browsers are using same metrics <dael> koji: Blink we use same metric as one platofrm uses. Even if same web fonts blink uses different metrics depending on platform <dael> koji: We rely on platform API to read metrics <fantasai> And this drives authors crazy <dael> myles: meta question- if we resolve on this to have interop do you expect to apply this to other css properties. Like we'd have to implement new type system to get interop or is this one-off <dael> koji: At least for new things I'd like itneroperable ones. Some reasons we may need existing ones, legacy reasons or future platofrm behavior. in those cases I'm fine to provide options. <fantasai> +1 <dael> astearns: Should we continue later since we're at time? <dael> myles: Good idea <dael> astearns: Let's continue in GH and we'll come back |
|
I wonder if having interoperable values for
|
|
Thank you for the feedback. I was originally thinking about big differences in the 3 ascent/descent metrics, which often gives a largely (>10 pixels) different positions on large font size. But if we can also make rounding behavior interoperable, I think it's a great achievement. It is a bit larger topic, because this issue was talking only about values that derives from ascent/descent, but rounding applies to all values of When thinking about rounding behavior, I can think of multiple levels.
I guess you're talking about rounding at step 3, correct? Step 1 produces slightly different values depends on CPU/FPU, and step 2 is known to be different by each browser, I think these two are hard to standardize. Do you have any preferred way to do this? I don't have much experiences of what kind of rounding to physical pixels can render glyphs best. We would like to support sub-CSS pixel positioning of text but have not supported it yet. |
|
Thinking further, I think rounding deserves its own issue, opening a new one. |
|
Related: #2228 It would be great if the linked issue will get fixed by this ticket here 😀 |
|
The CSS Working Group just discussed
The full IRC log of that discussion<emilio> Topic: make text of leading-trim interoperable?<RossenF2F> github:https://github.com//issues/3978 <fantasai> https://drafts.csswg.org/css-inline-3/#leading-trim-property <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 <emilio> ... there's several values like cap-height x-height etc <emilio> ... and the normal one which is laying out the text and then add the half-leading <emilio> ... but there's also leading-trim which doesn't add the half-leading <emilio> ... koji pointed out that these metrics don't have interop <emilio> ... so if we did trim out the half-leading above and below the text we'd probably get no interop <emilio> florian: can you clarify what's not interoperable? I think unless you use line-height normal stuff should mostly match <emilio> fantasai: different browsers use different font-metrics <emilio> ... I don't have a solution and don't understand the full issue from koji, but I hope we can close it somehow <emilio> koji: in the current implementation stuff is not interoperable. I'd like to ask about jfkthame and myles' opinion if any <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 <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 <emilio> ... so that's probably not what you want as a designer <emilio> ... not clear there's a good answer <emilio> fantasai: there's vertical-align: text-{top,bottom}, we should probably be consistent with them <emilio> jfkthame: I'd bet that's not interoperable <RossenF2F> q? <emilio> koji: jfkthame is right, even with the same font Chrome peeks different ascent behavior in mac / windows to match platform behavior <myles> q+ <fantasai> s/even/but even/ <emilio> ... I'd like browsers to match at least given the same font binary <emilio> faceless: we've been trying to figure out what browsers do <emilio> ... we find different behavior between FF and Chrome when a font specifies a zero line-gap in OS/2 <emilio> ... not sure if this is about <emilio> fantasai: that's probably the answer for why line-height is not interoperable. But this feature should probably not use line-gap <RossenF2F> ack myles <fantasai> s/line-height/line-height: normal/ <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 <emilio> fantasai: this is opt-in <fantasai> initial value is auto, which just does the usual thing with half-leading and whatever <fantasai> s/auto/normal/ <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 <emilio> myles: there are three ascent/descend pairs in fonts, I don't think we want three options <emilio> koji: I agree... Any specific set you can accept? <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 <emilio> hober: in terms of a general principle I think there's a good thing that browser engines can rely on other platform frameworks <emilio> ... the job of parsing fonts is the job of the font library not the browsers <emilio> fantasai: can you pull out the cap height and such metrics? <emilio> myles: I think the best answer is we work very closely with coretext <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 <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? <emilio> myles: Not 100% sure about the question but I don't think we can change default text rendering <emilio> fantasai: we're not proposing that <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 <emilio> ... I think we have two options, either figure out an interoperable metric <emilio> ... or drop this value <fantasai> https://drafts.csswg.org/css-inline-3/#propdef-leading-trim-over <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 <emilio> fantasai: there's several places where the top and bottom edge of the text comes into play <emilio> ... one is vertical alignment <emilio> ... the other is when we're trying to draw backgrounds and borders <emilio> ... so the content box edges of the inline <emilio> ... I don't think that's well defined <emilio> koji: canvas exposes this but I don't think it's interoperable <dbaron> s/canvas/canvas TextMetrics/ <emilio> fantasai: the last one is vertical-align text-{top,bottom} <emilio> ... but I don't know what they do <emilio> ... so I don't know what to put in the spec <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 <emilio> fantasai: I think authors want a little bit more control / consistency about what's happening in the documents <RossenF2F> q? <RossenF2F> ack dbaron <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 <emilio> dbaron: myles has asked about the lack of interop. I think that causes real bugs for minority browsers <emilio> ... like cases where a minimal amount of space perturbs the whole layout <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 <emilio> RossenF2F: but that's not true for the long tail of the web <RossenF2F> +1 to dbaron <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 <RossenF2F> q? <emilio> ... sort of the same points fantasai mentions but even more complicated and less interoperable <emilio> ... so probably worth separating it <emilio> fantasai: we can also drop the feature of leading-trim that allows you to drop the half-leading <emilio> ... but I'd still have the issue of text-top/text-bottom <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)/ <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 <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)/ <emilio> fantasai: what do people do for text-top / text-bottom <emilio> ? <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? <emilio> RossenF2F: what's that? <emilio> myles: that's using the ascent / descent that you already have during text layout <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 <emilio> myles: I agree that interoperability is good <emilio> ... but I think there are constraints that make that difficult <emilio> ... I also think that this is worth a warning on the spec given this is a new feature <emilio> florian: so this is about using text-top/text-bottom, whatever they're currently doing right? <emilio> ... but that's exactly about what this issue is about <myles> s/I also think that this is worth a warning on the spec given this is a new feature// <emilio> koji: I think we need at least one interoperable value <emilio> ... so that authors can have control <emilio> myles: in some other issue I proposed somewhere else is additional descriptors in @font-face <emilio> ... that the browser could use <emilio> faceless: for fonts that have incorrect info that'd be of huge help <emilio> myles: and that also allows avoiding to parse font files <emilio> hober: that is a good idea, I think <emilio> koji: I'm fine with that <emilio> florian: so you'd add descriptors for where the text-top / text-bottom are and the browser would use these values <emilio> ... everywhere <emilio> ... seems worth looking into <emilio> myles: it's in some comment of some issue a long time ago, can dig it up <fantasai> testcase for content-edge vs vertical-align: text-top http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7710 <emilio> florian: if we manage to characterize how these behaviors differ we could let authors choose <emilio> myles: that'd reintroduce the problem of parsing font files <emilio> fantasai: so we should open an issue about this against fonts-5, and that'd get rid of the interoperability <emilio> ... the other thing is how we define how to use these metrics <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 <emilio> fremy: they don't seem to match in Chrome <emilio> florian: It matches here <emilio> koji: I think it can change across OSes <emilio> fantasai: does it match on Safari? <emilio> florian: yeah, looks like <emilio> dbaron: they don't see to match by a pixel in Firefox here, but might be a pixel-snapping issue <emilio> fantasai: I'd like to resolve that text-top and the background-box of inlines use the same metrics <fremy> (I want to clarify, that neither Chrome nor Firefox do match on my Windows device) <dbaron> (I see a 1px mismatch for the serif example.) <emilio> ... can we resolve that they ought to match <emilio> florian: so the non-matching behavior is something we want to fix? <emilio> dbaron: we could try to understand why they don't match first <emilio> RossenF2F: but the intent is pretty good modulo bugs/rounding issues <emilio> RESOLVED: Spec that text-top/bottom and background boxes of inlines ought to match <emilio> RESOLVED: make leading-trim's text value match the same value for text-top/text-bottom/etc <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 <emilio> fantasai: we should try to request vendors to describe what's happening to have better spec text |
Will the issue described at #2228 get fixed by the above decisions? |
No. |
Because it's relevant to this issue as well, a note that I've written up the details of how each browser chooses font metrics at #2228 (comment) |
fantasai
added a commit
that referenced
this issue
May 26, 2020
…e content-edge metric as defined in CSS2. #3978
|
Follow-up for defining interoperable ascent/descent metrics via @font-face is #4792 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unfortunately all impls compute different positions for
text-top, and that theleading-trim: textvalue using it doesn't make this property interoperable. I would like the property to provide at least one value that is interoperable across platforms (browsers/OS).I discussed with @litherum on this before. IIUC we would like to have two text-top/bottom metrics; one which is interoperable, another which is compatible with the current layout engine of the platform.
How about something like:
sTypoAscender/sTypoDescenderfromos/2table in OpenType fonts, or the tightest metrics on other font systems that can provide multiple text metrics.typo-textmetrics to 1em. For example, the text-top em-height for OpenType is computed bysTypoAscender / (sTypoAscender + sTypoDescender) * font-size.The em-height is a metric invented by Gecko, @jfkthame explained here.
@fantasai
The text was updated successfully, but these errors were encountered: