- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Mar 2022 16:36:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `lh and rlh units and form control complications`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: lh and rlh units and form control complications<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3257<br> <fantasai> [emilio is fussing with webex problems]<br> <fantasai> emilio: Issue here is that some elements treat their line height at different times, some are computed value and some used value<br> <fantasai> emilio: and not interop<br> <fantasai> emilio: so line height units wouldn't be interop across browsers<br> <fantasai> emilio: can't quite change the adjustments<br> <fantasai> emilio: e.g. single-line input elements act as normal if line-height is less than ... some tricky things<br> <fantasai> emilio: roughly interoperable in terms of effect<br> <fantasai> emilio: but we should agree, but if we don't agree on when to do the adjustment, the units will behave differently depending on whether computed-value time or used value time<br> <fantasai> Rossen_: do we have any consensus on what should be done?<br> <fantasai> iank_: Remind me, emilio?<br> <fantasai> iank_: Can you remind me, these adjustments are all to do with 'appearance'?<br> <fantasai> emilio: not really<br> <fantasai> emilio: at least chrome applies regardless of appearance<br> <fantasai> iank_: interesting<br> <fantasai> emilio: I can check but pretty sure it's not tied to appearance, at least with input<br> <fantasai> emilio: unsure about <select><br> <smfr> q+<br> <fantasai> Rossen_: Do we already have experiments and consensus, or trying to establish now?<br> <fantasai> smfr: What if we just remove the units? is there sufficient demand for these units that we need to solve this problem?<br> <Rossen_> ack smfr<br> <Rossen_> ack fantasai<br> <fantasai> fantasai: Units were added to allow authors to spec margins and sizes in units of line height, to maintain vertical rhythm<br> <fantasai> fantasai: I don't think it makes sense to remove them because we can't figure out what to do with form controls, where they're unlikely to be used anyway<br> <fantasai> fantasai: It's better to resolve them to something random on form controls than it is to remove the units<br> <fantasai> Rossen_: What do you propose we do?<br> <fantasai> emilio: I think <select> does change computed line-height based on appearance, and input used line-height regardless of appearance, and [something something nested elements]<br> <iank_> our control elements are complicated wrt. to this as emilio suggests.<br> <fantasai> emilio: The resolution I want is that we have an interoperable definition, before we ship the units<br> <fantasai> Rossen_: Are you going to be the first ones shipping the units?<br> <fantasai> emilio: I think i filed this when WebKit added them behind a flag<br> <fantasai> emilio: I just noticed and looked into the weird edge cases<br> <fantasai> emilio: I think WebKit is the only one with an implementation right now<br> <fantasai> smfr: we turned it off because of this problem<br> <fantasai> Rossen_: so you would be OK to not ship them for awhile?<br> <fantasai> smfr: I think that's fine<br> <emilio> scribenick: emilio<br> <emilio> fantasai: I don't want to see these units get stuck on this edge case<br> <emilio> ... If we're hang up on this issue I'd be happy to define that on form control it resolves to 16px or something<br> <emilio> ... I don't think the value of these on a form control matters at all<br> <emilio> ... if that's what we're hang up on let's resolve<br> <miriam> +1 fantasai<br> <emilio> ... but I wouldn't like for this feature to get stuck on that, nobody is going to use it on form controls<br> <astearns> +1 to fantasai<br> <emilio> q+<br> <Rossen_> ack fantasai<br> <Rossen_> ack emilio<br> <fantasai> emilio: To be clear, I don't think this is a hard problem to solve. Just need to figure out what implementations are doing<br> <fantasai> emilio: and then decide whether we are fine with these units behaving oddly on <select>, because computed value would change after the fact<br> <fantasai> emilio: so like you would resolve the units based on the author-specified line-height, when might be overridden later<br> <fantasai> emilio: I don't think this is an unsolveable problem<br> <fantasai> emilio: first check if we're all doing the same, and then decide if the weird behavior is desirable, and document it<br> <emilio> fantasai: Happy to just make it undefined on the spec on form controls, I don't think it matters on form controls<br> <emilio> ... I don't think it's a high priority to make it work there<br> <fantasai> Rossen_: is that something we can start with? Make it undefined on form controls, and then define it later?<br> <astearns> would rather we pick a behavior<br> <fantasai> emilio: I would much rather prefer it was interoperable<br> <Rossen_> ack fantasai<br> <fantasai> emilio: Undefining it is going to backfire<br> <astearns> test one browser and pick that value :)<br> <fantasai> Rossen_: It would be undefined on form controls, and interoperable everywhere else<br> <fantasai> emilio: Someone will use it on form controls, and start depending on its behavior<br> <fantasai> iank_: agree with emilio<br> <vmpstr> +1<br> <fantasai> Rossen_: Either we leave it as undefined on form controls, or we use some agreed-upon value, or take this back to the issue and work with implementers to figure out how this should work<br> <fantasai> Rossen_: which option do we want to take?<br> <fantasai> emilio: I'm happy to document how I think implementations are going to work here<br> <fantasai> emilio: I know what Gecko does, but checking what blink/webkit is doing<br> <fantasai> emilio: and see if we agree on it<br> <fantasai> emilio: if we do then, fine, if we don't agree, then we can decide what is the least painful way to interop<br> <fantasai> Rossen_: Ok, let's do that. Let's have you go back and write that up in the issue, and once you have it we'll have something concrete to talk about<br> <fantasai> Rossen_: and see if rest of engines can agree<br> <fantasai> Rossen_: does that work?<br> <fantasai> emilio: Sure<br> <fantasai> Rossen_: OK, sounds like we're going with the third solution.<br> <fantasai> Rossen_: Emilio, once you have a proposal, let's go from there<br> <fantasai> Rossen_: anything else on this issue?<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-1083368313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 March 2022 16:36:44 UTC