Repository navigation
[css-values] The lh and rlh units are more complicated than what they seem. #3257
Description
https://drafts.csswg.org/css-values/#lh says:
Equal to the computed value of the line-height property of the element on which it is used, converting normal to an absolute length by using only the metrics of the first available font.
But the computed value of line-height depends on other properties at least in some browsers, so this suddenly becomes really tricky.
For example, <select>'s line-height computed value for comboboxes changes in WebKit and Blink to normal if the select is themed (based on the -webkit-appearance) property:
https://crisal.io/tmp/select.html
I'm considering doing the same in Firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=1501908.
In any case, the used value does definitely depend on theming of comboboxes, for example, across all browsers (see above).
How are these units supposed to work in this case? We definitely don't want values to depend on used values. We should probably specify how these adjustments work and make them work across browsers before anyone implements these units.
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
emilio commentedon Oct 27, 2018
https://bug1501908.bmoattachments.org/attachment.cgi?id=9020530 is probably a more permanent link that the one above.
fantasai commentedon Oct 27, 2018
@emilio Seems a bit odd that -webkit-appearance affects the computed value of
line-height, I recall implementers (particularly Mozilla) arguing for minimal interference among properties for computed values. Is-webkit-appearanceyour only example or are there more? Also, what happens if an author setsline-heighton the OPTION elements or OPTGROUP? Does it take effect or no?MatsPalmgren commentedon Oct 27, 2018
@fantasai We currently have
option,optgroup { line-height: normal !important; }in our UA sheet. I'm considering changing that, but I need to reverse-engineer what other UAs do first...We used to have the same on
<select>and when I removed the!importantpart there it broke Twitter since Gecko didn't have any "treat it asnormalfor themed comboboxes" code in place...emilio commentedon Oct 27, 2018
I'm all in to less interaction between properties.
Though sometimes (in particular in this case, where we need to implement this interaction because of compat), it may be easier to do at computed value time rather than at used value time.
Seems like blink's code for this is:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_theme_default.cc?l=303&rcl=a18d95d1f23d08476ebe0bae8ce198a4c1e93427
There's a bunch of other font controls that affect line height, looking at that file, and to:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_theme.cc?l=243&rcl=1d2414e576dce6b3d55550002fd8f04c72e469d9
emilio commentedon Oct 27, 2018
Note that differences between computed value time line-height and used-value-time line-height special-cases are indistinguishable as of now (in theory, see https://bugs.chromium.org/p/chromium/issues/detail?id=899489).
But it's something we need to have interop on before even considering implementing these units.
emilio commentedon May 3, 2020
Another interesting case is text autosizing, which in some browsers like WebKit affects the computed line-height, and in others like Gecko or Blink affects the used line-height.
emilio commentedon May 3, 2020
Though I guess that also affects font-size so there's a precedent on how they should behave there.
fantasai commentedon Oct 21, 2021
@emilio So what do you want us to do here?
emilio commentedon Oct 22, 2021
@fantasai either specifying and getting interop on when the computed value of line-height changes after-the-fact (as in the themed combobox case) and deal with it somehow in the spec, or specify that these are used value adjustments that don't affect these units (and get browsers to change that before implementing these units).
3 remaining items
css-meeting-bot commentedon Aug 3, 2022
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.The full IRC log of that discussion
<TabAtkins> Topic: lh and rlh are complicated<TabAtkins> github: https://github.com//issues/3257
<TabAtkins> emilio: I don't think this is too controversial
<TabAtkins> emilio: fantasai added it to agenda
<TabAtkins> emilio: main issue is browsers have different line-height fixups
<TabAtkins> emilio: sometimes at used, sometimes at computed time
<TabAtkins> emilio: the ones at computed time should change the lh unit
<TabAtkins> emilio: but that's not possible, you've computed everything at that point
<TabAtkins> emilio: at very least, would like to either agree...
<TabAtkins> emilio: get interop on these adjustments
<TabAtkins> emilio: so they don't cause weird interop issues
<TabAtkins> emilio: the gecko adjustments are in the issue comment
<TabAtkins> emilio: we force a minimum line-height on inputs at used value time
<TabAtkins> emilio: for select we force line-height normal at computed-value time
<TabAtkins> emilio: i believe these adjustments are done in other browsers, maybe in subtly different ways
<iank_> we do them differently.
<TabAtkins> emilio: forgot to look into details
<TabAtkins> emilio: just don't know how differently
<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
<TabAtkins> iank_: so the two you're referring to will force it to line-height:initial
<iank_> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_theme_default.cc;l=201-205
<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.
<TabAtkins> emilio: agree, it would just be great ot ahve those fixups documented
<TabAtkins> fantasai: further than taht - i think having them documented is a nice-to-have. don't really think they need to be interop
<TabAtkins> fantasai: if people ship without interop, that's fine.
<TabAtkins> emilio: given they're already for webcompat...
<TabAtkins> fantasai: right, they're to make sure the line height doesn't shrink below usable for a form control
<TabAtkins> fantasai: nobody's gonna depend on that for a form control
<TabAtkins> emilio: this is the sort of thing that always bites us
<fantasai> s/for a form contro/for using lh or rlh on a form control/
<TabAtkins> emilio: I think this shoudln't be hard to get right
<astearns> ack dbaron
<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
<TabAtkins> dbaron: I think if people have the lh unit they might sometimes use them for the height of a form control
<TabAtkins> astearns: people will use the unit everywhere
<TabAtkins> astearns: so ian is saying chrome's fixups are different...
<TabAtkins> iank_: yeah ours are different than what emilio described
<TabAtkins> iank_: we just force, at least for select, reset it to initial line-height
<TabAtkins> iank_: we've been slowly trying to remove these custom style fixups, but very gradually
<TabAtkins> iank_: you can imagine a lot of this depends on if the form element has auto appearance
<TabAtkins> iank_: so this is the difficulty
<TabAtkins> iank_: if we didn't have appearance, all of these could be UA stylesheets
<TabAtkins> iank_: but we explicitly allow things to be overwritten if they don't have the appearance
<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
<TabAtkins> emilio: think i found the chromium bits
<TabAtkins> emilio: seems like in chromium you apply the fixups not on the element, but on the inner shadow dom of the control
<TabAtkins> iank_: not 100% sure on that
<TabAtkins> iank_: thought we did some on the actual element
<TabAtkins> astearns: so emilio, are you discussing putting these into the spec based on gecko?
<TabAtkins> emilio: not necessarily, just making sure lh/rlh dont' change across browsers
<TabAtkins> emilio: it seems to me that implementing lh/rlh do end up with the wrong value, but wrong consistently
<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'
<astearns> q?
<TabAtkins> dbaron: i think the key question is whether the fixup changes what the lh does on itself, and on descendants
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10518
<TabAtkins> dbaron: and if it's easy for impls to come to agreement we can just spec that
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10519
<TabAtkins> emilio: right and even descendants might not be too important for input, bc replaced
<TabAtkins> florian: do any of these have descendants?
<TabAtkins> emilio: can set font-size on <option>, yeah
<TabAtkins> iank_: these two examples show what we do with <select>
<TabAtkins> iank_: first has line-height on <select>, and we log 'normal' - it resets to initial
<TabAtkins> iank_: In second I set appearance:none and it logs 5px, so it shows fixup is dependent on appearance
<TabAtkins> iank_: we do all of this as a fixup step on the computed style at the very end
<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
<TabAtkins> emilio: I agree that's the most reasonable thing to do
<TabAtkins> iank_: and a lot of people do set appearance:none if they want more styling control, and it'll work then
<TabAtkins> astearns: so do we have enough?
<TabAtkins> emilio: yeah seems reasonable, as long as we agree that fixups dont' change the meaning of the lh/rlh units
<TabAtkins> emilio: firefox behaviro is similar
<TabAtkins> emilio: on <select> we do post-style fixup
<TabAtkins> emilio: On webkit maybe the same, they do weird stuff on form controls
<TabAtkins> iank_: yeah we've diverged a lot
<fantasai> TabAtkins: so proposed resolution is that these fixups don't affect these units on form controls or descendants
<TabAtkins> emilio: descendants might get affected, since we do computed fixup
<TabAtkins> emilio: but on the element itself it's clear
<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
<TabAtkins> dbaron: so if it affects descendants but not itself is interoperable, maybe specify it even tho it's weird
<TabAtkins> emilio: eh, we've got some todos to shift some computation to layout time rather than compute time
<TabAtkins> emilio: don't think it matters too much since it only applies to a few form controls
<TabAtkins> fantasai: so we can spec it doesn't affect the form control itslef, but undefined whethe rit affects descendants
<TabAtkins> emilio: yeah
<TabAtkins> iank_: fine with that
<fantasai> s/we can/can we/
<emilio> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10520
<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.
<emilio> ScribeNick: emilio
[css-values-3] Form control restrictions to line-height don't affect …
Test that lh units are calculated before select fixup
Test that lh units are calculated before select fixup
Test that lh units are calculated before select fixup
Test that lh units are calculated before select fixup
Bug 1795284 [wpt PR 36457] - Test that lh units are calculated before…
Bug 1795284 [wpt PR 36457] - Test that lh units are calculated before…