- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Jul 2021 16:34:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Values and Units L4`, and agreed to the following: * `RESOLVED: "dynamic" viewport does indeed use units, not env()` * `RESOLVED: Add lvh as explicit "large viewport" unit` * `RESOLVED: vh/etc are deliberately UA-defined` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Values and Units L4<br> <TabAtkins> ScribeNick: TabAtkins<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668<br> <TabAtkins> fantasai: Tab and I comitted the changes for our earlier resolution on these joint issues (this and next)<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/6113<br> <Rossen_> q<br> <TabAtkins> fantasai: we resolved to add viewport units to represent the "small" and "dynamic" viewport<br> <TabAtkins> fantasai: there are a couple open qustions still<br> <TabAtkins> fantasai: One was whether dynamic should be a unit or an env()<br> <TabAtkins> fantasai: We went for unit based on comments from Rachel Andrews that it would be easier to teach<br> <TabAtkins> fantasai: Main reason for env() was to deliberately make it more awkward to use.<br> <TabAtkins> fantasai: Right now tho, the draft is using units; we can reopen that discussion if people wish<br> <TabAtkins> fantasai: Other question is we have an unprefixed set of units (vw/etc) and two prefixed sets (svw/etc, dvw/etc)<br> <TabAtkins> fantasai: Do we want an explicit set of "larger" prefixed units for symmetry?<br> <TabAtkins> fantasai: And if we do that, should we allow the unprefixed values to do something smarter? Right now they're the larger viewport, but this causes some troubles and browsers might want to do something smarter.<br> <TabAtkins> fantasai: So do we want to give CSS some flexibility for the unprefixed units?<br> <TabAtkins> fantasai: So first quesiton to tackle: anyone want us to switch the dynamic units to being an env()?<br> <TabAtkins> jensimmons: I think it works well as a unit. Authors will need and use it, and having it be the same as the other units will make it much easier to use.<br> <florian> +1<br> <miriam> +1<br> <rachelandrew> +1<br> <TabAtkins> Rossen_: Do we ahve a particularly well-defined guidance on how and when to add value types vs env()? It woudl be unfortunate if we end up in a situation where scrollbar-width is in an env() but viewport-width is in a unit, etc<br> <TabAtkins> fantasai: We don't have this written down, but the basic principle is if you're likely to want multiples of this other than 1.<br> <TabAtkins> fantasai: Like for safe-area-inset, you don't want 30% of it, or 5x that.<br> <TabAtkins> fantasai: You might add some more length to it, some extra px or something, but very unlikely to want to multiply it by a number.<br> <TabAtkins> fantasai: But for viewport units it's very common to want 50vh/etc, so it makes more sense to be a unit where it's easier to do that<br> <TabAtkins> Rossen_: I can see how this could make sense from a usage pov<br> <TabAtkins> Rossen_: At the same time I could argue the inset should be a unit regardless of whether you'd want it to be x1 or not<br> <TabAtkins> florian: Other factor is if the value depends on where you are in the tree, it must be a unit. If it doesn't, either works.<br> <TabAtkins> florian: For example, width of scrollbars cannot be an env() because it changes based on the unit you're applying it to.<br> <TabAtkins> emilio: Having units depend on computed values of properties is kinda sketchy...<br> <TabAtkins> florian: Sure, but still like having font-size expressed in an env() doesn't make sense, so you need em<br> <bmathwig> width of scrollbars can't change depending on element, it's fixed in most UA implementations<br> <TabAtkins> emilio: Sure, tho there's only two scrollbar widths. Could still be done as two env()s<br> <TabAtkins> plinss: I don't feel too strongly, but I'm a little concerned about proliferation of units.<br> <florian> bmathwig, see https://drafts.csswg.org/css-scrollbars/#scrollbar-width<br> <TabAtkins> plinss: If the non-unit syntax ends up unwieldy, we can work on that.<br> <TabAtkins> Rossen_: Basically same for me. I'd also like us to formulate a more general reasoning for when to use units vs env()<br> <bmathwig> auto | thin | none only applies to classical scrollbars and not overlay scrollbars that have zero-width in layout computations<br> <TabAtkins> Rossen_: But overall I don't object.<br> <bmathwig> Blink is moving towards overlay scrollbars on Windows in the next few months<br> <TabAtkins> fantasai: Okay so it sounds like we should resolve on dvh being units<br> <fantasai> bmathwig, that doesn't change the matter of the width of the scrollbar, only how much space it takes up in layout<br> <TabAtkins> RESOLVED: "dynamic" viewport does indeed use units, not env()<br> <TabAtkins> fantasai: So next is about unprefixed units.<br> <TabAtkins> fantasai: Do we want an explicit large-prefixed set to go with the others?<br> <TabAtkins> jensimmons: been a lot of convo on WK team last week about how these work<br> <TabAtkins> jensimmons: We feel very strongly there should be an lvh unit<br> <TabAtkins> jensimmons: And the vh unit should no longer be defined as longest length; it should instead be something more flexible that the UA can decide on based on what they're doing with their particular browser<br> <bmathwig> fantasai, very true<br> <lea> I'm all up for making vw/vh more useful, but how web compatible is this change?<br> <TabAtkins> florian: I see why you'd want the flexibility for this, to provide best UX possible, I'm concerned about variance in behavior that would cause content to be off-screen in one browser, etc.<br> <TabAtkins> fantasai: tbf that's already happening today<br> <TabAtkins> jensimmons: Lea made a comment about webcompat, that's absolutely a concern<br> <lea> q?<br> <TabAtkins> jensimmons: I think having this be flexible so UA can make the best decision to present the fewest compat problems<br> <TabAtkins> jensimmons: And by giving authors the explicit lvh and others let them choose the right one for their website<br> <florian> I'm sold :)<br> <lea> +1 for this change from me<br> <TabAtkins> jensimmons: But browsers may need flexibility to redefine that vh itself based on individual pages<br> <fantasai> +1 from me also<br> <TabAtkins> emilio: I think any change to vh should probably be a [...? missed]<br> <TabAtkins> emilio: I think we want a definition in the spec we can implement interoperably<br> <emilio> s/be a ?/ consider compat, but...<br> <TabAtkins> fantasai: So I think we have agreement to add "large" viewport units, make vh/etc ambiguous at the moment (and gradually make it clear what this actually means)<br> <TabAtkins> fantasai: So for now we say it's UA-defined and it must fall in the range of svh and lvh<br> <TabAtkins> florian: Also a note that if any UA uses the flexibility to make it something other than the three explicit ones, come back to the group and spec it<br> <TabAtkins> emilio: Can we file an issue to explore the compat of vh/etc?<br> <TabAtkins> fantasai: We should also have an issue about what is the ICB in these cases, and that's probably the same<br> <florian> s/and spec it/so that we can see if it is something we could spec/<br> <fantasai> s/probably the same/probably should be the same as the unprefixed units/<br> <TabAtkins> jensimmons: I noticed in the discussion there was some discussion about the "l" standing for "layout viewport", but I like it better to be "longest"<br> <florian> +1 to s/d/l as the naming<br> <TabAtkins> fantasai: Earlier we were thinking we'd use an "l" prefix for the dynamic one. Now we're gonna do small/large for s/l, or short/long, whichever you prefer to talk about<br> <TabAtkins> RESOLVED: Add lvh as explicit "large viewport" unit<br> <TabAtkins> astearns: So second is about redefining vh<br> <TabAtkins> fantasai: Currently the spec is actually extremely vague<br> <TabAtkins> fantasai: it just says "it's the size of the viewport"<br> <TabAtkins> fantasai: So the resolution here would be to maintain the ambiguity<br> <TabAtkins> florian: Maintain ambiguity or explicitly say it's UA-defined?<br> <TabAtkins> fantasai: I'm fine with either<br> <TabAtkins> florian: I'd prefer UA-defined with the note i said earlier<br> <TabAtkins> florian: About UAs reporting to the WG if they do somethign creative<br> <TabAtkins> astearns: Any objections?<br> <fantasai> scribe+ TabAtkins<br> <TabAtkins> RESOLVED: vh/etc are deliberately UA-defined<br> <TabAtkins> fantasai: That should be it for this issue, tho we need to open that issue about the nuances of vh<br> <TabAtkins> astearns: I'd encourage people to file new issues for any further discussions, these issues got long and intertwined and it'll be easier with new issues<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-880040513 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 July 2021 16:34:24 UTC