- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Jul 2021 19:04:05 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Color 5
-----------
- RESOLVED: Update WD of css-color-5
Counter Styles
--------------
- RESOLVED: Publish updated CR of css-counter-styles-3
Cascade 5
---------
- RESOLVED: 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(Issue #6407: Do
conditional rules impact layer order?)
Values & Units 4
----------------
- RESOLVED: "dynamic" viewport does indeed use units, not env()
(Issue #4329: Add vhc value and issue #6113: Add lvh+lvw
values)
- RESOLVED: Add lvh as explicit "large viewport" unit (Issues #4329
and #6113)
- RESOLVED: vh/etc are deliberately UA-defined (Issues #4329 and
#6113)
- RESOLVED: New WD of Values 4, after viewport units edits have been
made
CSS Overflow
------------
- RESOLVED: Elements with a zero-area border-box do not directly
contribute to scrollable overflow area. (Issue #4791:
Scrollable Overflow contributions of zero height/width
elements)
CSS UI 4
--------
- RESOLVED: Close issue, one color accent-color for now (Issue #6159:
accent-color background colors and contrast)
CSS Scrollbar
-------------
- RESOLVED: Rename to 'both-edges' (Issue #6349: Rename
scrollbar-gutter:both)
- RESOLVED: Close WONTFIX; scrollbar-width remains non-inherited
(Issue #4799: scrollbar-width should be inherited)
- RESOLVED: Drop the light/dark keywords from scrollbar-color (Issue
#6438: Remove light and dark keywords of scrollbar-color
in favor of color-scheme)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jul/0006.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Christian Biesinger
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Mason Freed
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Chris Lilley
Peter Linss
Alison Maher
Ben Mathwig
Morgan Reschenberg
Florian Rivoal
Miriam Suzanne
Lea Verou
Scribe: fantasai
Scribe's scribe: TabAtkins
CSS Color 5
===========
astearns: Adding request for css-color-5 WD
astearns: any other changes to agenda?
astearns: We'd agreed to publish after changes in for color-adjust
astearns: Those changes now in
astearns: Any objections to publishing?
RESOLVED: Update WD of css-color-5
Future Meetings
===============
Rossen: ...
astearns: Two weeks from now we're having long-form vF2F meetings
instead 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?
leaverou: I don't have access, maybe ChrisL can do it?
Counter Styles
==============
<astearns> https://lists.w3.org/Archives/Public/www-style/2021Jul/0000.html
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
astearns: Any other comments on this?
<chris> looks good to me
astearns: Any objections?
RESOLVED: Publish updated CR of css-counter-styles-3
<chris> so is this a CRS or CRD?
<fantasai> CRS
Cascade 5
=========
Do conditional rules impact layer order?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6407
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
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 have to define it
emilio: Unfortunate to have to traverse everything
emilio: when building data structure, when finding media/supports
query that doesn't 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-globals?
miriam: Not yet
astearns: Adding that as the reason for this requirement would
probably help future spec development, so add editorially
RESOLVED: 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
===================
Scribe: TabAtkins
Add vhc value
-------------
github: https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668
fantasai: Tab and I committed the changes for our earlier resolution
on these joint issues (this and next)
<fantasai> https://github.com/w3c/csswg-drafts/issues/6113
fantasai: We resolved to add viewport units to represent the "small"
and "dynamic" viewport
fantasai: there are a couple open questions 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 though, 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 question 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 have a particularly well-defined guidance on how and
when to add value types vs env()? It would 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
emilio: Sure, though there's only two scrollbar widths. Could still
be done as two env()s
<bmathwig> width of scrollbars can't change depending on element,
it's fixed in most UA implementations
<florian> bmathwig, see
https://drafts.csswg.org/css-scrollbars/#scrollbar-width
<bmathwig> auto | thin | none only applies to classical scrollbars
and not overlay scrollbars that have zero-width in layout
computations
<bmathwig> Blink is moving towards overlay scrollbars on Windows in
the next few months
<fantasai> bmathwig, that doesn't change the matter of the width of
the scrollbar, only how much space it takes up in layout
<bmathwig> fantasai, very true
plinss: I don't feel too strongly, but I'm a little concerned about
proliferation of units.
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()
Rossen: But overall I don't object.
fantasai: Okay so it sounds like we should resolve on dvh being units
RESOLVED: "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 conversation 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
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
<lea> I'm all up for making vw/vh more useful, but how web compatible
is this change?
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 consider compat,
but...
emilio: I think we want a definition in the spec we can implement
interoperably
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"
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
<florian> +1 to s/d/l as the naming
RESOLVED: 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 something creative
astearns: Any objections?
RESOLVED: vh/etc are deliberately UA-defined
fantasai: That should be it for this issue, though 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://drafts.csswg.org/css-values-4/#changes
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 publishing?
RESOLVED: New WD of Values 4, after viewport units edits have been
made
CSS Overflow 3
==============
Scrollable Overflow contributions of zero height/width elements
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4791#issuecomment-862553085
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?
RESOLVED: Elements with a zero-area border-box do not directly
contribute to scrollable overflow area.
CSS UI 4
========
Scribe: fantasai
accent-color background colors and contrast
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6159#issuecomment-877023330
masonf: 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
florian: but reopening question of one vs two, would prefer to avoid
<lea> Totally agree that accent-color should be 1 color
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 platform
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 disagreement
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
RESOLVED: Close issue, one color accent-color for now
CSS Scrollbar
=============
Rename scrollbar-gutter:both
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/6349
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
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?
RESOLVED: Rename to 'both-edges'
scrollbar-width should be inherited
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4799#issuecomment-877482191
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. Disagree with making scrollbar-width to inherited
florian: but author might know about certain widths or whatever that
need a thinner scrollbar
florian: and that would be a reason for author control
florian: so I think should stay not inherited
<bmathwig> +1 on this Florian
<emilio> +1
<fantasai> +1
<tantek> also I disagree with the methodology of equating reasoning
of -color with -width
RESOLVED: Close WONTFIX; scrollbar-width remains non-inherited
Remove light and dark keywords of scrollbar-color in favor of
color-scheme
-------------------------------------------------------------
Scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/6438
fantasai: When we first added scrollbar-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 should automatically
change the scrollbar colors
fantasai: And nobody's implemented light/dark anyway
fantasai: So proposal is to just drop these values
<emilio> +1
<lea> +1
<bmathwig> +1
<florian> +1
<TabAtkins> +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
florian: default value of color-scheme is "auto" anyway, we can make
sure there's some flexibility there
astearns: Objections?
<tantek> this is a good point, there may be a compat need to keep
'dark'
<TabAtkins> tantek, there's zero implementation of 'dark', so by
definition no compat need
<tantek> TabAtkins: huh, ok then I misunderstood emilio
<emilio> tantek: firefox does darken scrollbars of scrollers with
dark backgrounds
<TabAtkins> 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
<tantek> great this seems like an ideal resolution of this
RESOLVED: Drop the light/dark keywords from scrollbar-color
Received on Wednesday, 14 July 2021 23:04:53 UTC