Meeting minutes
<TabAtkins> getting ahead a bit: elika and I haven't had time to meet yet to discuss #2 (the aspect ratio issue) - we'll be doing so tomorrow. we should bump this to next week.
<astearns> OK, thanks
<dbaron[m]> Preent+
astearns: pushing item 2 to next week
<astearns> https://
astearns: adding request for css-color-5 WD
astearns: any other changes to agenda?
CSS Color 5
astearns: We'd agreed to publish after changes in for color-adjust
astearns: Those changes now in
astearns: Any objections to publishing?
Resolution: update WD of css-color-5
Agenda
Rossen_: ...
astearns: Two weeks from now we're having long-form vF2F meetings intead of the Wed call
astearns: People have started adding items to that agenda
astearns: Please look into what topics would be good to cover during those meetings and add to agenda
Rossen_: Also, there's a Color API meeting tomorrow. Seems everyone has agreed to move to 10am Pacific (except haven't heard from Pierre)
Rossen_: Lea, can you update the calendar?
lea: I don't have access, maybe ChrisL can do it?
Counter Styles
https://
<astearns> https://
astearns: Has changes list, Disposition of Comments, some HR responses, all described in link above
astearns: My only question is about tests, are there updated tests for the changes?
[silence]
astearns: It would be nice, and will be needed to progress any further
<chris> looks good to me
astearns: Any other comments on this?
astearns: Any objections?
Resolution: Publish updated CR of css-counter-styles-3
<chris> so is this a CRS or CRD?
CRS
Cascade 5
github: https://
miriam: Question was about defining layers defined inside global conditions like @media
miriam: but open issue about non-global condition like container queries
miriam: Thread concluded should always affect layer order
TabAtkins: Looks good
emilio: How do auto-conditionals behave inside container queries?
emilio: Is there a real use case for this?
miriam: If you want some of the things in the container query to be layered or not
<TabAtkins> fantasai: the clarification here is that there's no particular use-case for the layer existing or not conditionally, but there is a use-case for having layered styles in there, so we ahve to define it
emilio: Unfortunate to have to traverse everything
emilio: when building data structure, when finding media/supports query that doesnt' match
emilio: just skip all the rules
emilio: but here you are forced to read all the rules on the page
miriam: you have to do that anyway, because container queries aren't global, you have to read them to understand the page
TabAtkins: I think emilio misunderstood
TabAtkins: in global conditionals, they are conditional
emilio: Oh, I thought we were reverting on that. No, this makes sense.
astearns: Other comments on this?
astearns: If layer is introduced in a container query rule, it always affects layer order, whether or not that query matches anything
miriam: more broadly, any non-global condition
astearns: Any other non-globls?
miriam: Not yet
astearns: Adding that as the reason for this requirement would probably help future spec development, so add editorially
Resolution: If a layer is introduced in a non-global conditional rule (such as a container query), it always affects the layer order, whether or not that query matches
Values and Units L4
<fantasai> github: https://
fantasai: Tab and I comitted the changes for our earlier resolution on these joint issues (this and next)
<fantasai> https://
fantasai: we resolved to add viewport units to represent the "small" and "dynamic" viewport
fantasai: there are a couple open qustions still
fantasai: One was whether dynamic should be a unit or an env()
fantasai: We went for unit based on comments from Rachel Andrews that it would be easier to teach
fantasai: Main reason for env() was to deliberately make it more awkward to use.
fantasai: Right now tho, the draft is using units; we can reopen that discussion if people wish
fantasai: Other question is we have an unprefixed set of units (vw/etc) and two prefixed sets (svw/etc, dvw/etc)
fantasai: Do we want an explicit set of "larger" prefixed units for symmetry?
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.
fantasai: So do we want to give CSS some flexibility for the unprefixed units?
fantasai: So first quesiton to tackle: anyone want us to switch the dynamic units to being an env()?
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.
<florian> +1
<miriam> +1
<rachelandrew> +1
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
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.
fantasai: Like for safe-area-inset, you don't want 30% of it, or 5x that.
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.
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
Rossen_: I can see how this could make sense from a usage pov
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
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.
florian: For example, width of scrollbars cannot be an env() because it changes based on the unit you're applying it to.
emilio: Having units depend on computed values of properties is kinda sketchy...
florian: Sure, but still like having font-size expressed in an env() doesn't make sense, so you need em
<bmathwig> width of scrollbars can't change depending on element, it's fixed in most UA implementations
emilio: Sure, tho there's only two scrollbar widths. Could still be done as two env()s
plinss: I don't feel too strongly, but I'm a little concerned about proliferation of units.
<florian> bmathwig, see https://
plinss: If the non-unit syntax ends up unwieldy, we can work on that.
Rossen_: Basically same for me. I'd also like us to formulate a more general reasoning for when to use units vs env()
<bmathwig> auto | thin | none only applies to classical scrollbars and not overlay scrollbars that have zero-width in layout computations
Rossen_: But overall I don't object.
<bmathwig> Blink is moving towards overlay scrollbars on Windows in the next few months
fantasai: Okay so it sounds like we should resolve on dvh being units
<fantasai> bmathwig, that doesn't change the matter of the width of the scrollbar, only how much space it takes up in layout
Resolution: "dynamic" viewport does indeed use units, not env()
fantasai: So next is about unprefixed units.
fantasai: Do we want an explicit large-prefixed set to go with the others?
jensimmons: been a lot of convo on WK team last week about how these work
jensimmons: We feel very strongly there should be an lvh unit
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
<bmathwig> fantasai, very true
<lea> I'm all up for making vw/vh more useful, but how web compatible is this change?
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.
fantasai: tbf that's already happening today
jensimmons: Lea made a comment about webcompat, that's absolutely a concern
jensimmons: I think having this be flexible so UA can make the best decision to present the fewest compat problems
jensimmons: And by giving authors the explicit lvh and others let them choose the right one for their website
<florian> I'm sold :)
<lea> +1 for this change from me
jensimmons: But browsers may need flexibility to redefine that vh itself based on individual pages
<fantasai> +1 from me also
emilio: I think any change to vh should probably be a [...? missed]
emilio: I think we want a definition in the spec we can implement interoperably
<emilio> s/be a ?/ consider compat, but...
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)
fantasai: So for now we say it's UA-defined and it must fall in the range of svh and lvh
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 so that we can see if it is something we could spec
emilio: Can we file an issue to explore the compat of vh/etc?
fantasai: We should also have an issue about what is the ICB in these cases, and that's probably should be the same as the unprefixed units
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"
<florian> +1 to s/d/l as the naming
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
Resolution: Add lvh as explicit "large viewport" unit
astearns: So second is about redefining vh
fantasai: Currently the spec is actually extremely vague
fantasai: it just says "it's the size of the viewport"
fantasai: So the resolution here would be to maintain the ambiguity
florian: Maintain ambiguity or explicitly say it's UA-defined?
fantasai: I'm fine with either
florian: I'd prefer UA-defined with the note i said earlier
florian: About UAs reporting to the WG if they do somethign creative
astearns: Any objections?
Resolution: vh/etc are deliberately UA-defined
fantasai: That should be it for this issue, tho we need to open that issue about the nuances of vh
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
Publishing Values 4
<fantasai> https://
fantasai: I'll fold in these edits we just agreed to
fantasai: But besides that we have a handful of changes
fantasai: So we need a resolution to publish
astearns: This just a regular WD?
fantasai: yup
astearns: Objections to pub?
Resolution: New WD of Values 4, after viewport units edits have been made
css-overflow-3
<fantasai> github: https://
fantasai: If an element has zero area in its border box, it doesn't directly contribute to scrollable overflow
fantasai: It can have indirect effects, if it increases the height of its parent box or something
fantasai: But the element *itself* doesn't appear to do anything in impls. Should we add that to the spec?
astearns: Seems reasonable
florian: Yes, both because interop is good to spec, and because authors really hate when invisible boxes have side-effects
astearns: Would be great to have these tested properly too
astearns: So proposed resolution is to specify that zero-area border-box elements do not directly contribute to scrollable overflow area
astearns: Objections?
Resolution: Elements with a zero-area border-box do not directly contribute to scrollable overflow area.
accent-color background colors and contrast
<fantasai> github: https://
??: tldr of issue is, the spec, as written today, takes one color for accent-color
masonf: form controls drawn with that color need to make sure they have enough contrast with other parts
masonf: Opened issue to discuss
masonf: Depending on how implemented, if you change accent-color slightly, the contrasting pieces can change abruptly from light to dark color to maintain contrast
masonf: Where we are now is that we would prefer to just close the issue
masonf: The discussion has been, should we allow the developer to spec more than one color
masonf: and we went around about that last year, and don't want to open can of worms again
masonf: we think it'd be better for dev to be able to do that, but happy to just close issue and leave behavior up to UA
emilio: Idk where the disagreement is...
emilio: What Chrome implements is that the switch to dark foreground color based on ??
emilio: Firefox does something similar, but not sensitive to color-scheme
emilio: It's different in some places
emilio: So I think specifying foreground/background pair would make sense here
emilio: but ...
masonf: The way we're currently implementing this, we have a set colors for light mode and dark mode
masonf: we calculate contrast ratio, and choose the one with most contrast
masonf: It seems to work ok
masonf: does guarantee minimum level of contrast
masonf: I think allowing specifying foreground+background color would be better
masonf: but the consensus previously was to allow UA to innovate on form controls
masonf: and allowing author to spec 2 colors would hamper that
emilio: why doesn't specify one color create a problem. 2 colors is more flexible
florian: Agree I don't want to reopen the entire conversation
florian: would like to stick to 1 color
florian: Agree that UA should pick however it want
florian: We might want to add a note reminding UAs that they don't have to pick *the most* contrasting color
florian: They could take into account e.g. color-scheme
florian: as long as enough contrast, have a choice of colors
<lea> Totally agree that accent-color should be 1 color
florian: but reopening question of one vs two, would prefer to avoid
emilio: 1 color is going to be a mess compat wise
hober: To summarize, disagreement from what I remember, was not about having 1 or 2 colors in general
hober: was about how exact to specify how those two colors would be used
hober: which one should be foreground, which background, which pieces of which form elements should get which colors
hober: other side wanted to leave to UA, might be different plaform conventions or form styling that would lend themselves to using colors differently
emilio: I think it's silly to get stuck with one color
emilio: But then seems disagreement wasn't about one vs two colors
florian: multiple hours of disagrement
fantasai: There *are* two colors available to the UA. If 'color' is appropriate, you *can* use it.
emilio: I don't think that would work.
fantasai: We can't do this in general, because form controls have different conventions and some of them are a lot more complicated than checkboxes
florian: This discussion has happened already.
astearns: Any objection to moving forward with one color
emilio: no. I just think it's a bad decision
Resolution: Close issue, one color accent-color for now
Scrollbar Styling
github: https://
<Zakim> fantasai, you wanted to mention calendar widgets
florian: Some confusion over the name of 'both'
florian: Set of edits landed after a side-meeting, renamed it to 'mirror'
florian: Some people said maybe it should be 'both-sides' or 'both-edges'
florian: All of them are clearer than what we have now
florian: Current ED went with mirror because both clearer and short
florian: Anyone have any comments?
astearns: Minor preference for a longer one
florian: I prefer one I went with, but wouldn't object to switching either
<TabAtkins> I'm fine with "mirror" after some thought
<TabAtkins> it's grown on me
<bmathwig> +1 for both-edges
astearns: I think both-sides or both-edges is clearer, because "mirroring what?"
miriam: Any chance that we want 'inline' as part of the name? in case want block later?
florian: Would add it as a second value
florian: e.g. stable stable, or stable mirror
florian: So I wouldn't include in the keyword
<Zakim> fantasai, you wanted to ask if we're moving this to css-scrollbars-1?
fantasai: Weren't we planning to move to scrollbars spec?
florian: Had a resolution for it
florian: But had some issues to work out, wanted to work out prior to moving
florian: but I think we're getting there
smfr: I like both-sides or both-edges
<rachelandrew> +1 for both-
<Rossen_> prefer both-
<tantek> slight pref for both-*
??: -edge makes more sense because of the scrollbars
??: some people when thinking of sides think only of left and right
<tantek> agreed with that reasoning for "edge"
<jfkthame> +1 for both-edges
astearns: sounds like we're leaning towards 'both-edges'
astearns: Anyone object?
Resolution: Rename to 'both-edges'
scrollbar-width inheritance
github: https://
florian: Suggestion to switch scrollbar-width to inherited
florian: for consistency with scrollbar-color and to make easier to style the whole page
florian: and I think we should not do that or exactly that reason
<TabAtkins> florian's argument in the thread makes sense to me, i'm fine with WONTFIX'ing this
florian: Primary use case for global scrollbar width is author preference, not author preference
<tantek> +1. disagreewith making scrollbar-width to inherited
florian: but author might know about certain widgeths or whatever that need a thinner scrollbar
<bmathwig> +1 on this Florian
florian: and that would be a reason for author control
<emilio> +1
florian: so I think should stay not inherited
+1
<tantek> also I disagree with the methodology of equating reasoning of -color with -width
Resolution: Close WONTFIX; scrollbar-width remains non-inherited
scrollbar-color: light/dark
<fantasai> github: https://
fantasai: When we first added sc4rollbar-color we didn't have color-scheme
fantasai: So we had keywords for light/dark so authors could request those if they just wanted to match their theme
fantasai: Since then we've added color-scheme which does this on a broader scale, and in particular shoudl automatically change the scrollbar colors
<emilio> +1
fantasai: And nobody's implemented light/dark anyway
<lea> +1
<bmathwig> +1
<florian> +1
fantasai: So proposal is to just drop these values
+1
<tantek> +100
emilio: We don't implement color-scheme, but we do have darkening of scrollbars vs the background color
emilio: So perhaps shouldn't specify it should follow the color scheme
emilio: We currently get away with auto-darkening scrollbars on pages that don't use color-scheme
<tantek> this is a good point, there may be a compat need to keep 'dark'
florian: default value of color-scheme is "auto" anyway, we can make sure there's some flexibility there
tantek, there's zero implementation of 'dark', so by definition no compat need
astearns: Objections?
<tantek> TabAtkins: huh, ok then I misunderstood emilio
Resolution: drop the light/dark keywords from scrollbar-color
<emilio> tantek: firefox does darken scrollbars of scrollers with dark backgrounds
emilio was concerned about the auto value *requiring* the scrollbar to go light/dark depending on 'color-scheme'
<tantek> emilio, got it. so this is allowing that flexibility in 'auto'
<emilio> tantek: (assuming scrollbar-color: auto ofc)
<emilio> tantek: right
end
<tantek> great this seems like an ideal resolution of this