- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Jun 2021 19:02:15 -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 Pseudo
----------
- RESOLVED: Add custom properties support to pseudo elements (Issue
#6264: Highlight pseudos and custom props)
CSS Cascade
-----------
- RESOLVED: Layer rules respect conditionals, and are ignored in
non-global conditionals (Issue #6407: Do conditional
rules impact layer order?)
- RESOLVED: Name-defining at-rules follow layer order for collision
resolution, similar to specificity resolution (Issue
#6404: What happens to name-defining @-rules nested
inside @layer?)
CSS Values
----------
- Review is requested for the proposed text on issue #6113 (Add
lvh+lvw values) before a resolution is requested next week.
CSS Fonts
---------
- RESOLVED: The issue is resolved [now that we have size-adjust]
(Issue #5533: Reduce layout shift via @font-face
descriptor(s) overriding inline spacing)
CSS Color
---------
- RESOLVED: Drop color-adjust(), stick with relative color syntax for
color manipulation for now (Issue #6179: Is
color-adjust() needed, now that we have relative color
syntax?)
Selectors
---------
- Please add feedback to issue #6399 (Remove the :scope dependency
from the relative selectors definition) to help determine which
of the proposed solutions to take.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0020.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Oriol Brufau
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Jonathan Kew
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
Miriam Suzanne
Lea Verou
Regrets:
Alan Stearns
Scribe: TabAtkins
Scribe's scribe: bkardell
Rossen: Any extra agenda items?
TabAtkins: I'd like to bump the first item unless fantasai's ready to
talk about it
Rossen: Happy to if that will help
chris: I had an Agenda+ about dropping color-adjust that didn't make
it to the list
<chris> https://github.com/w3c/csswg-drafts/issues/6179
CSS Pseudo
==========
scribe: bkardell
Highlight pseudos and custom props
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6264
TabAtkins: A chromium implementer was asking if custom properties
should work on highlight pseudos and should have the same
details -- leaverou was asking if there were any pseudos
they shouldn't work on
TabAtkins: We should probably make a blanket statement that they are
valid on all pseudo elements
Rossen: Opinions?
leaverou: The only pseudos I could think of where they might not make
sense are non-standard ones. If we ever were to standardize
something like --webkit-scrollbar what would that mean?
TabAtkins: There are already inheritable properties there
sanketj: This sounds reasonable. The only question I had was is there
a use case that prompted this or is it just for correctness.
I would hate to update the spec and then it never gets used
TabAtkins: The use cases for custom properties are myriad, it's
reasonable to think they should work
<leaverou> Strong +1 for enabling custom properties on every
pseudo-element
sanketj: I guess I am still wondering what the use cases are - in my
mind the properties on pseudos are pretty specific. Mostly
curiosity
TabAtkins: Custom properties do nothing on their own, but they
empower a million things - so they're always going to be
hard to talk about like that
sanketj: Fair enough
<bkardell> +1
Rossen: Any objections?
RESOLVED: Add custom properties support to pseudo elements
CSS Cascade
===========
scribe: TabAtkins
Do conditional rules impact layer order?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6407
miriam: What happens when layers are defined inside of conditionals?
miriam: like @media ... { @layer ...; }
miriam: Do those layers contribute to layer order, and if so, how?
miriam: In the final thread comment I listed the options
miriam: First is parse error - don't think that works.
miriam: Like what happens when we apply a media to an entire
stylesheet? Doesn't seem right to have layers disappear.
miriam: Second is layers in conditionals don't contribute to the
order. This has similar issues - what if a layer *only*
appears inside a conditional? Still need some order for them.
miriam: So remaining is (3) layers always contribute in order they
appear, whether the conditional is matched or not
miriam: I think this is my favorite solution, because it doesn't
require special casing
miriam: Last solution is to make layer ordering dynamic based on
conditionals
miriam: In some ways this is true already via (3) with media=""
attribute, due to lazy-loading, so you'll get some dynamic
behavior anyway
miriam: This would just go all the way
miriam: It'll need special casing for container queries; they don't
have a global match state, they're matched per element.
They'd have to fall back to the first or second option there.
TabAtkins: I was originally for option 3, but lazy loading made me
reconsider, so now I'm strong for option 4 (with ignoring
layers in @container rules)
TabAtkins: And emilio was also for 4 on Twitter, and it looks like
Anders is for 4 from the issue thread
miriam: The Twitter thread also voted for 4 by far. (Not always
right, but it's useful info about what authors expect.)
miriam: I think 3 is simpler to understand and teach, but I see the
points for 4.
miriam: Fine with either way.
futhark: Not just lazy loading, also inserting stylesheets and rules.
You can insert layer rules dynamically, right?
miriam: Yeah
futhark: So I think that leans toward fully dynamic as well, since
other things cause similar dynamic results
Rossen: So I'm hearing pretty strong support for 4 among authors and
impls. Are you okay with that, Miriam?
<bkardell> +1
miriam: Sure
Rossen: Any objections?
RESOLVED: Layer rules respect conditionals, and are ignored in
non-global conditionals.
Do conditional rules impact layer order?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6407
miriam: So inside of @container, layers can't contribute to order.
miriam: Is that a parse error? (layer rules inside of @container is
always invalid)
miriam: Or is it only an error to *introduce* a layer inside of one,
and it's fine to use one that's already defined?
futhark: I'll need more time to think
TabAtkins: Assuming layered styles are okay inside of container
queries generally (I think so, but futhark can correct),
then I suggest if a @layer is *introduced* in a
@container, it's treated as always being introduced there,
regardless of the @container matching or not.
* bkardell doesn't understand tab's suggestion
futhark: Need some more time to think on the consequences of this
miriam: It's basically option 3, but applied only to container queries
Rossen: So doesn't sounds like we have resolution yet, we'll take the
rest of this topic to github
What happens to name-defining @-rules nested inside @layer?
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6404
miriam: Would something like @keyframes, a name-defining at-rule,
work in @layer and how?
miriam: If there are two @keyframes with the same name, the later one
wins.
miriam: Not common to do intentionally, but I did find some people
using this to test out new animations live in production.
miriam: So question is if the two are defined in separate layers,
does the layer order impact name collision resolution?
miriam: I'd like to say yes, I think that's author expectation.
TabAtkins: I agree with Mia - It would rule out a lot of use cases
and would be very confusing if pure source order applied
to these rules
TabAtkins: the whole point of layering is against that - I think name
defining rules should follow layer order just the same as
anything else
Rossen: Other opinions?
Rossen: Not hearing objections, so let's resolve.
RESOLVED: Name-defining at-rules follow layer order for collision
resolution, similar to specificity resolution.
CSS Values
==========
Add lvh+lvw values
------------------
github: https://github.com/w3c/csswg-drafts/issues/6113
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668
<TabAtkins> https://drafts.csswg.org/css-values-4/#viewport-relative-lengths
TabAtkins: Two weeks ago fantasai and I drafted new text for more
viewport relative sizes. There was discussion about
whether we should do some of these as env variables - we
are currently using units
TabAtkins: We introduced svw svh for small viewport, for example and
a dvh for dynamic viewport ... as discussed in previous
discussions dvh only needs to be accurate when it is stable
TabAtkins: when the UI is stable, it is the correct size of the
viewport
TabAtkins: We would love comments or discussion - it's all very
bikeshedable right now
TabAtkins: If you have strong opinions on units vs env, let us know -
we made an editors choice, but we can go either way
TabAtkins: It would be great to be able to resolve on these next week
(if we have the quorum)
CSS Fonts
=========
Reduce layout shift via @font-face descriptor(s) overriding inline
spacing
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5533
TabAtkins: Now that we have 'size-adjust', can we close this issue?
Chris Harrelson and Chris Lilley both say yes, close it.
<chris> Yes this one should be closed
<jfkthame> +1 to closing
<chrishtr> Xiaocheng is also happy to close it.
RESOLVED: The issue is resolved
CSS Color
=========
Is color-adjust() needed, now that we have relative color syntax?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6179
chris: A few years ago we resolved to add two conflicting proposals
for how to adjust colors
chris: We've continued to publish with both, and refine them
chris: At this point the relative color syntax seems like it's easier
and strictly more powerful
chris: it would be simpler if we could just decide to go with that one
leaverou: I see color-adjust() as being slightly higher level than RCS
leaverou: But for that, you don't actually get much more clarity
leaverou: like color-adjust(..., lightness(20%)) - does that mean set
it to 20%? Increase it to 20%?
leaverou: But RCS is very clear, the math is laid out
leaverou: So I support the RCS
leaverou: That said, we've done research on how color is used in Sass
since they have manipulation for years
leaverou: The Sass equivalent of color-adjust is barely used at all
leaverou: Instead they usually extract color components and do math
on that, or use even higher-level functions like lighten()
and darken()
leaverou: So I think we should prioritize a method that does math on
the components (RCS) and also pursue higher-level easy
manipulations like lighten()
leaverou: We might also want to in the future allow
channel-extraction functions that would let you combine
things from multiple colors; that's not possible at all
right now.
leaverou: I thought we might have wanted to just go with that, but
since WK implemented RCS and people seem to like it, I'm
fine with just going with that
argyle: I'm very pro the RCS
argyle: I recall some initial concerns about it confusing, but I'm
happy to hear those are resolved.
argyle: Agree there's no way to extract individual channels yet -
good to work on in the future.
<chris> I was also concerned that RCS was too complex, but I no
longer feel that.
argyle: So I support Lea's push here, to move forward with RCS and
pursue channel manipulation later.
argyle: And also doing higher-level simple manipulations like
lighten()
<chris> +1 to high-level color-lighten and color-darken
argyle: So yeah, think removing color-adjust() will simplify and let
us perhaps do a better version in the future
<TabAtkins> +1 as well
<bkardell> +1
<miriam> +1
Rossen: Any other opinions? See a bunch of +1s on the channel
<leaverou> basically what I was trying to say is that between RCS and
color-adjust() I'd support RCS, you get a lot more
flexibility for only slightly more complexity. But we do
need higher level functions and potentially something even
more lower level that will allow combining components of
multiple different colors (we even have internal CSS WG
use cases for those)
Rossen: Any objections?
<chris> smfr on the record?
<smfr> i want to see groove and ridge borders specified in terms of
RCS
<TabAtkins> smfr, I'm pretty sure it's doable without much
difficulty, but would have to play with it.
<leaverou> smfr: if it's not doable with RCS, it certainly isn't
doable with color-adjust(). RCS's power is a strict
superset.
chris: So resolution would be to drop color-adjust(), keep relative
color syntax.
RESOLVED: Drop color-adjust(), stick with relative color syntax for
color manipulation for now
Rossen: Do you need to republish Color 5, Chris? This would be a
pretty big change.
chris: Yes, once we've done this we should repub
Rossen: So let's resolve to repub once changes made
Selectors
=========
Remove the :scope dependency from the relative selectors definition
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6399
bkardell: Selectors spec has :has(); we introduced a :scope pseudo
alongside it. In querySelectorAll() it's very useful, but
it's basically equivalent to :root in normal stylesheets.
bkardell: Now :has() allows "relative selectors", starting with a
combinator.
bkardell: And :scope refers to that implicit starting element, and
can be used later in the selector.
bkardell: This causes a lot of issues; we'd prefer to drop the
relative selector, and make the implicit starting element
not be matched by :scope
bkardell: I think current prior impl for it is only Prince. They do
seem to support it.
bkardell: But this is just a lot more difficult in the live profile
bkardell: Issue goes into a lot more detail, looking for thoughts and
feedback.
oriol: In most cases, when there's a selector inside of :has() that
has :scope, you can refactor it to move that reference outside
of the :has() and not lose any functionality
<leaverou> +1 to whatever restrictions we need to place on :scope to
make :has() happen
Received on Wednesday, 30 June 2021 23:02:56 UTC