- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 14:29:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `inline layout`. <details><summary>The full IRC log of that discussion</summary> <jet> Topic: inline layout<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/938<br> <jet> Florian: from weaknesses of vertcal rythm<br> <jet> Florian: found lineheight issues from that investigation<br> <Florian> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-314690847<br> <jet> Florian: I did a bunch of testing ^<br> <jet> Florian: shows how browsers differ<br> <jet> Florian: more interop than expected<br> <jet> Florian: Safari & Edge are the same<br> <jet> Florian: Chrome differs<br> <jet> Florian: Firefox differs<br> <jet> Florian: when lineheight is a number or length vs. normal<br> <jet> Florian: refers to diagram from Tokyo discussions<br> <jet> Florian: (see github issue for diagram)<br> <jet> Florian: can't figure out Chromium baseline alignment<br> <jet> Florian: why does chrome behave this way?<br> <jet> Florian: we should fork the issue for general lineheight<br> <jet> Florian: we need to define base behavior of lineheight<br> <jet> fantasai: because rhythm depends on lineheight<br> <fantasai> fantasai: because the trigger to round up for rhythm depends on the computation of line height<br> <fantasai> myles_: and you can double spacing in some UAs not others if those computations differ<br> <fantasai> fantasai: right<br> <jet> Florian: goal is general interop on lineheight<br> <jet> astearns: discuss divergence on lineheight:normal<br> <jet> Florian: can isolate individual bugs<br> <jet> ACTION: Florian to file bugs with each case<br> <trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.<br> <jet> fantasai: we don't have a spec for these issues<br> <fantasai> astearns: but we have interop except for chrome<br> <fantasai> astearns: so Chrome should figure out whether there's a reason to diverge, or whether they will fix it<br> <fantasai> astearns: and then we can spec the result of that discussion<br> <jet> Florian: for lineheight:normal Chrome differs by using the top of the tallest used fonts<br> <jet> Florian: will file a bug on that one<br> <jet> koji: we need to see the test<br> <jet> Florian: we'll debug later<br> <jet> Florian: I had to find fonts with tall ascenders and long descenders<br> <jet> Florian: Firefox font metrics differ<br> <jet> Florian: not sure why<br> <fantasai> myles_: If a browser changes the metrics they read from a font, every web page will look different. At least for us, that would be almost certainly unlikely to happen.<br> <jet> myles: if a browser changes metrics per font, every web page will render differently<br> <jet> Florian: in some cases Firefox is the same<br> <jet> dbaron: platform API's differ for metrics<br> <jet> koji: everyone has 3 font metrics<br> <jet> Florian: Chrome & Safari same on Mac<br> <jet> Florian: Chome & Edge same on WIndows<br> <jet> myles: some fonts are just weird<br> <fantasai> myles_: For at least font on at leats one platform, at least one of the metrics of the font returned by the system API doesn't appear anywhere in the font<br> <jet> Florian: the tests aren't clear re: metrics, but does show the divergence<br> <jet> Florian: I checked the content box for inlines--also no interop<br> <jet> Florian: on Chrome, doesnt depend on font metrics or lineheight<br> <jet> fantasai: spec says content box can't depend on lineheight<br> <jet> Florian: Firefox depends on font metrics and not lineheight<br> <jet> Florian: notes Chrome bugs<br> <jet> fantasai: is it 1 em?<br> <jet> fantasai: 1 em is at least predictable<br> <jet> Florian: not 1 em<br> <dbaron> FWIW, Gecko has 4 platform-specific font backends: (1) FreeType (used on Linux and Android), (2) Mac (3) GDI (Windows) and (4) DirectWrite (also Windows)<br> <jet> Florian: more testing needed<br> <jet> Bert: CSS2 recommends 1em or height of the ascender to descender<br> <Bert> ". The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. "<br> <myles_> dbaron: macOS has CoreText and CoreGraphics and they may disagree<br> <Bert> (This is from CSS2)<br> <Bert> https://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced<br> <dbaron> myles_, I think we're using CoreText<br> <jet> astearns: it differs depending on the platform font subsystem<br> <myles_> dbaron: 💯<br> <dbaron> myles_, er, wait, there's a pointer to both objects :-P<br> <myles_> dbaron: 💯💯✅<br> <jet> Florian: Firefox differs with Outlines<br> <dbaron> myles_, InitMetrics seems to use mostly CG* APIs<br> <jet> Florian: outline allows a lot of leeway<br> <jet> Florian: and Firefox diverges most<br> <jet> Florian: please review the tests<br> <jet> astearns: file the bugs and have the browser engineers challenge<br> <jet> fantasai: we want interop and sane behavior so file spec bugs not browser bugs<br> <jet> fantasai: resolve on content box height?<br> <dbaron> myles_, I think we use Core Text only for fonts with color bitmap glyphs<br> <fantasai> Florian: we have 3 behaviors, Chrome I can't figure out at all. Doesn't seem to depend on line height or font metrics<br> <fantasai> Florian: Firefox ....<br> <jet> astearns: if we file a Chrome bug, we can get interop<br> <jet> astearns: despite no spec<br> <jet> fantasai: we should specify what the TTML folks can use<br> <dbaron> I think there are probably much larger audiences than the TTML folks who care about this.<br> <jet> Florian: using ascender/descender lengths is unpredictable<br> <fantasai> dbaron, not sure who that is, but pretty sure they'd agree on having something controllable and predictable<br> <jet> dbaron: may be concerns re: e.g., accent marks<br> <jet> dbaron: and script-specific issues<br> <dbaron> s/accent marks/accent marks not hanging out of the background/<br> <dbaron> s/script-specific issues/that might be more important for Vietnamese than for English/<br> <jet> Florian: content box depending on font metrics is very unpredictable<br> <jet> Florian: we can resolve on Safari/Edge behavior re: lineheight:normal being a bug<br> <jet> Florian: lineheight != normal returns different sizes<br> <jet> astearns: curently not a spec violation<br> <astearns> but we should probably make it one<br> <jet> fremy: we can't resolve if we don't know what to spec<br> <dbaron> I think it is a violation of https://drafts.csswg.org/css2/visudet.html#inline-non-replaced<br> <jet> fremy: please file more specific issues<br> <jet> Florian: we'll split the topic<br> <astearns> dbaron: fair - "The 'height' property does not apply <to the content area>" does seem to be relevant<br> <jet> fantasai: file issues against CSS inline and CSS2<br> <jet> Florian: I tested 2 ways: line stacking and with border. same results<br> <dbaron> I guess it's violating the "should" that it's based on the font<br> <jet> fremy: spec proposes 2 solutions<br> <jet> fremy: not sure how we choose either<br> <jet> fremy: I need to check Edge code<br> <fremy> fremy: but maybe we consider line-height to be intent from authors they want control<br> <jet> Florian: interop is fixable<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/938#issuecomment-320263822 using your GitHub account
Received on Friday, 4 August 2017 14:29:24 UTC