- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 15:56:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `lh and rlh are complicated`, and agreed to the following: * `RESOLVED: browser "fixups" of line height on form controls do *not* affect lh/rlh on the element itself. Effect of fixups on lh/rlh of descendants is explicitly undefined.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: lh and rlh are complicated<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/3257<br> <TabAtkins> emilio: I don't think this is too controversial<br> <TabAtkins> emilio: fantasai added it to agenda<br> <TabAtkins> emilio: main issue is browsers have different line-height fixups<br> <TabAtkins> emilio: sometimes at used, sometimes at computed time<br> <TabAtkins> emilio: the ones at computed time should change the lh unit<br> <TabAtkins> emilio: but that's not possible, you've computed everything at that point<br> <TabAtkins> emilio: at very least, would like to either agree...<br> <TabAtkins> emilio: get interop on these adjustments<br> <TabAtkins> emilio: so they don't cause weird interop issues<br> <TabAtkins> emilio: the gecko adjustments are in the issue comment<br> <TabAtkins> emilio: we force a minimum line-height on inputs at used value time<br> <TabAtkins> emilio: for select we force line-height normal at computed-value time<br> <TabAtkins> emilio: i believe these adjustments are done in other browsers, maybe in subtly different ways<br> <iank_> we do them differently.<br> <TabAtkins> emilio: forgot to look into details<br> <TabAtkins> emilio: just don't know how differently<br> <TabAtkins> iank_: for some form controls we will look at the computed style and apply a bunch of fixups right at the end of computed style<br> <TabAtkins> iank_: so the two you're referring to will force it to line-height:initial<br> <iank_> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_theme_default.cc;l=201-205<br> <fantasai> TabAtkins: I agree with fantasai, whatever we do here doesn't make any difference for real uses cases of lh/rlh. We will put anything you want in the spec, don't care.<br> <TabAtkins> emilio: agree, it would just be great ot ahve those fixups documented<br> <TabAtkins> fantasai: further than taht - i think having them documented is a nice-to-have. don't really think they need to be interop<br> <TabAtkins> fantasai: if people ship without interop, that's fine.<br> <TabAtkins> emilio: given they're already for webcompat...<br> <TabAtkins> fantasai: right, they're to make sure the line height doesn't shrink below usable for a form control<br> <TabAtkins> fantasai: nobody's gonna depend on that for a form control<br> <TabAtkins> emilio: this is the sort of thing that always bites us<br> <fantasai> s/for a form contro/for using lh or rlh on a form control/<br> <TabAtkins> emilio: I think this shoudln't be hard to get right<br> <astearns> ack dbaron<br> <TabAtkins> fantasai: I'm totally happy to get it right. don't want to delay shipping for 5 years for this one small detail that doesn't matter<br> <TabAtkins> dbaron: I think if people have the lh unit they might sometimes use them for the height of a form control<br> <TabAtkins> astearns: people will use the unit everywhere<br> <TabAtkins> astearns: so ian is saying chrome's fixups are different...<br> <TabAtkins> iank_: yeah ours are different than what emilio described<br> <TabAtkins> iank_: we just force, at least for select, reset it to initial line-height<br> <TabAtkins> iank_: we've been slowly trying to remove these custom style fixups, but very gradually<br> <TabAtkins> iank_: you can imagine a lot of this depends on if the form element has auto appearance<br> <TabAtkins> iank_: so this is the difficulty<br> <TabAtkins> iank_: if we didn't have appearance, all of these could be UA stylesheets<br> <TabAtkins> iank_: but we explicitly allow things to be overwritten if they don't have the appearance<br> <emilio> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/text_control_inner_elements.cc;l=173-194;drc=7fe33e343d08dc8815b5ca48b96f76e98a3d67c7 is for text controls, https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/menu_list_inner_element.cc;l=37-45;drc=04861b524177edda323dc6c37ad58e9bf1e85c12 is for select<br> <TabAtkins> emilio: think i found the chromium bits<br> <TabAtkins> emilio: seems like in chromium you apply the fixups not on the element, but on the inner shadow dom of the control<br> <TabAtkins> iank_: not 100% sure on that<br> <TabAtkins> iank_: thought we did some on the actual element<br> <TabAtkins> astearns: so emilio, are you discussing putting these into the spec based on gecko?<br> <TabAtkins> emilio: not necessarily, just making sure lh/rlh dont' change across browsers<br> <TabAtkins> emilio: it seems to me that implementing lh/rlh do end up with the wrong value, but wrong consistently<br> <TabAtkins> emilio: so if you did a line-height less than 1, you'd get that value for lh unit even if the final line-height is 'normal'<br> <astearns> q?<br> <TabAtkins> dbaron: i think the key question is whether the fixup changes what the lh does on itself, and on descendants<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10518<br> <TabAtkins> dbaron: and if it's easy for impls to come to agreement we can just spec that<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10519<br> <TabAtkins> emilio: right and even descendants might not be too important for input, bc replaced<br> <TabAtkins> florian: do any of these have descendants?<br> <TabAtkins> emilio: can set font-size on <option>, yeah<br> <TabAtkins> iank_: these two examples show what we do with <select><br> <TabAtkins> iank_: first has line-height on <select>, and we log 'normal' - it resets to initial<br> <TabAtkins> iank_: In second I set appearance:none and it logs 5px, so it shows fixup is dependent on appearance<br> <TabAtkins> iank_: we do all of this as a fixup step on the computed style at the very end<br> <TabAtkins> iank_: so an easy impl for us of lh unit would be these fixups apply at the end, and don't interfere with lh unit<br> <TabAtkins> emilio: I agree that's the most reasonable thing to do<br> <TabAtkins> iank_: and a lot of people do set appearance:none if they want more styling control, and it'll work then<br> <TabAtkins> astearns: so do we have enough?<br> <TabAtkins> emilio: yeah seems reasonable, as long as we agree that fixups dont' change the meaning of the lh/rlh units<br> <TabAtkins> emilio: firefox behaviro is similar<br> <TabAtkins> emilio: on <select> we do post-style fixup<br> <TabAtkins> emilio: On webkit maybe the same, they do weird stuff on form controls<br> <TabAtkins> iank_: yeah we've diverged a lot<br> <fantasai> TabAtkins: so proposed resolution is that these fixups don't affect these units on form controls or descendants<br> <TabAtkins> emilio: descendants might get affected, since we do computed fixup<br> <TabAtkins> emilio: but on the element itself it's clear<br> <TabAtkins> iank_: I think today fo rus if we apply this fixup, and some inner form control has line-height:inherit, it'll get the fixed up value, but don't think that's important<br> <TabAtkins> dbaron: so if it affects descendants but not itself is interoperable, maybe specify it even tho it's weird<br> <TabAtkins> emilio: eh, we've got some todos to shift some computation to layout time rather than compute time<br> <TabAtkins> emilio: don't think it matters too much since it only applies to a few form controls<br> <TabAtkins> fantasai: so we can spec it doesn't affect the form control itslef, but undefined whethe rit affects descendants<br> <TabAtkins> emilio: yeah<br> <TabAtkins> iank_: fine with that<br> <fantasai> s/we can/can we/<br> <emilio> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10520<br> <TabAtkins> RESOLVED: browser "fixups" of line height on form controls do *not* affect lh/rlh on the element itself. Effect of fixups on lh/rlh of descendants is explicitly undefined.<br> <emilio> ScribeNick: emilio<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3257#issuecomment-1204146452 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 15:56:58 UTC