- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 12 Jan 2023 06:01:43 -0500
- 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.
=========================================
Selectors 4
-----------
- Though the discussion on issue #8174 (Add pseudo-class to
establish before-change style for css-transitions on new
elements) had leaned toward adding a pseudo-element instead of a
pseudo-class, there were concerns this was new ground for
pseudo-elements. It was agreed that this should be a
pseudo-class behaving more like :visited. A new proposal will be
drafted and then this issue will be brought back to the group.
Animations & Transitions
-------------------------
- The group discussed the proposal for entry and exit animations for
top-layer elements (Issue #8189) and a few considerations were
raised.
- The proposal needs to ensure that it doesn't have the same
problems as z-index.
- There was some uncertainty as to if this should apply to
non-modal dialogs.
- Some concern was expressed that this only applied to
transitions where authors may try and use it for other
properties.
CSS Color
---------
- RESOLVED: Accept Chris's proposal [of text for resolving the RCS
value when currentColor is the origin] (Issue #7978: Is
relative color syntax ready to ship?)
- RESOLVED: Keywords with multiple specified types result in number
(Issue #7876: Clarification on how `channel keywords`
with multiple specified types work)
CSS Nesting
-----------
- RESOLVED: Adopt Option 3 (Issue #8249: Problem with mixing
properties and selectors)
- A Nesting breakout will be scheduled next week to cover the
outstanding objection to the above resolution as well as make
additional progress on other Nesting issues.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0002.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Daniel Holbert
Brad Kemper
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
Eric Meyer
Morgan Reschenberg
Khushal Sagar
Jen Simmons
Miriam Suzanne
Bramus Van Damme
Lea Verou
Sebastian Zartner
Regrets:
David Baron
Jonathan Davis
Jennifer Strickland
Chair: Rossen
Scribe: fantasai
Scribe's scribe: TabAtkins
Agenda Setting
==============
astearns: Most of the nesting issues are fine to take up and are
ready, but I'm just not seeing consensus on the blocking
issue 8249.
astearns: Not sure we need to spend call time on it until we get to
a better situation in the issue itself
TabAtkins: Safari and Chrome are both interested in shipping very
soon
TabAtkins: If we defer until the logjam resolves itself, it's going
to get resolved by somebody shipping
astearns: We try to address the objection
TabAtkins: That's why we didn't resolve last time
TabAtkins: but we need to discuss and resolve
* fantasai thinks further discussion in the issue isn't going to be
helpful, this needs live discussion
jensimmons: The two color issues are important for us to get to today
jensimmons: and also nesting
jensimmons: When Peter raised the objection, there were 3 parts and
we opened different issues to discuss
jensimmons: there were a lot of conversations that were had about
those objections
jensimmons: and I do think we can focus our objections on that
specific thing and not repeat ourselves
jensimmons: So maybe do the first two issues, then color, then the
rest of the call for nesting
Rossen: ok, we can try that
<fantasai> +1
<fantasai> good suggestion, jensimmons
<emeyer> +1
ntim: I would like to get to #3
ntim: don't know if it will fit in this call
Rossen: Let's see how quickly we get through the first six we have
right now
Rossen: the sooner we start, the sooner we might get to those
Selectors 4
===========
Add pseudo-class to establish before-change style for css-transitions
on new elements
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8174
flackr: When coming from display:none have no display style
flackr: so can't define a from state
flackr: can define in CSS animation, but less ergonomic
flackr: so proposing we add an :initial pseudo-class which
establishes the initial style
flackr: the before-change style for CSS transitions
flackr: In discussion, decided that if we made this a pseudo-element
flackr: we could optimize this by preventing e.g. sibling selectors
and only require occasional style calculation when it's used
flackr: so proposal is to have ::initial establish the initial style
emilio: This would be a pseudo-element that matches against an
element?
emilio: so matches element rules plus magic pseudo-element?
<fantasai> pseudo-element would be applied on top of element rules
emilio: that's pretty different from pseudo-element
emilio: I don't think we have a precedence for this, which is a bit
tricky
emilio: I'm also confused when you want it
emilio: This is for coming back from display:none?
emilio: Seems implementable, but seems tricky and weird to make it a
pseudo-element
emilio: because targetting two element styles on one
emilio: weird with regards to cascade
flackr: That's good feedback for pseudo-element approach
flackr: Could also take pseudo-class approach, but less easily
optimizable?
emilio: In what sense?
flackr: If you have combinator selectors, element showing up in the
DOM can cause recalculation
emilio: But that's the case for all pseudo-element
flackr: This is extra style recalc that doesn't normally exist
emilio: I'm a bit confused, you recalc more if you have :initial
along the combinators.... depending how well you optimize
flackr: I think given :initial is only establishing before-change
style and otherwise doesn't apply to the element, not that
weird that it conflicts with other styles
flackr: because those other styles can't initiate transitions from
display:none
emilio: We have a similar case with pseudo-classes for links
emilio: need to resolve :visited / :unvisitied, need to do
unconditionally, but don't understand why :initial would be
slower
flackr: If initial is a pseudo-class, can be used as part of
combinator selectors
flackr: so have to resolve all those combinators
flackr: but if pseudo-element, can't be used in those combinators
emilio: For :visited we have special case
emilio: basically :visited on left of sibling is ignored
flackr: Ah, we could do that
emilio: The way I think of implementing it is, we have this
element ...
emilio: otherwise :initial only matches rightmost compound
flackr: That sounds reasonable to me
emilio: That would be less weird
<fantasai> +1 to emilio
futhark: Ignoring the pseudo-class, when resolving selectors, would
have already computed style for previous one so would have
existing computed style
futhark: so :initial wouldn't match on those elements
emilio: Right. :initial can only match in this special case
emilio: "this element is now :initial", now compute
emilio: with :has() have similar dependency...
futhark: Similar if getComputedStyle() in display:none subtree
futhark: You need to ensure you have styles there to do inherit etc.
emilio: Not for siblings, but for ancestors
emilio: I'd rather say that it only matches on the rightmost
<flackr> +1
<chrishtr> +1
fantasai: How does this interact with page loading, partly loading?
flackr: Applies anytime the element first gets a layout box
flackr: This would apply any time you add element to a page
flackr: Separate issue for avoiding running things during load
flackr: but this is pre-existing problem for animations, which run
on page load
Rossen: So based on description, this would not fire on
display:contents ?
Rossen: since it doesn't have a box?
flackr: That sounds right
emilio: I think I'd rather special-case it to display:none since
that's the actual thing
<futhark> +1 to emilio.
emilio: At least, I don't think display:contents stops animations in
the subtree, whereas display:none does
PaulG: If we're leaning towards pseudo-element, how would that
affect AX tree?
PaulG: If not supposed to be animated at that time, just want to
make sure we consider that
flackr: Don't think we're leaning towards the pseudo-element approach
flackr: but not intended to establish a separate element, just style
the real element in the before-change state
fantasai: Suggest maybe flackr and emilio can come back with a
revised proposal, and we can move to other issues
flackr: fwiw, AX should be equivalent to animations
Rossen: ok, let's end here
Rossen: Come back when you're ready, thanks for introducing
CSS Animations & Transitions
============================
Entry and Exit Animations for top-layer elements
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8189
flackr: When certain elements go in/out of top layer
flackr: if devs want to have an animation on the, they need the
element to remain in the top layer for duration of the
animation
flackr: So proposal is that we allow specifying top layer in the
transition properties
flackr: but that it's otherwise not a developer-stylable property
flackr: Essentially, you can specify transition: top-layer
flackr: and give it a duration
flackr: and this is the duration during which the element stays in
the top layer
ntim: I've always been against the top-layer CSS property concept
ntim: The concept should really stay abstracted away from the
developer
ntim: even just introducing this property is a bad first step, I
think
lea: I wanted to ask ntim why he thinks this concept should be
abstracted away from the developer
lea: There's a lot of reasons it should controllable in CSS
lea: We keep seeing use cases that could be solved if could be
controlled in CSS
ntim: If you allow controlling top layer with CSS, you end up with
same issues as z-index
ntim: the appeal of top layer right now is that it's controlled by
order of JS API calls
ntim: but once you start allowing random elements to put top-layer,
then what order is actually used in the end?
lea: I think that depends on how we design the feature
lea: maybe it's a property that just the UA controls
lea: though I hope to avoid that
ntim: I think it needs a real design
ntim: just exposing this concept...
lea: Yes, absolutely, does need design work to do it properly to not
have problems of z-index
lea: Total +1 to that
<chrishtr> Note that the proposal is not incompatible with ntim's
concern. I agree with his concern.
emilio: I don't think I have a strong feeling wrt top layer property
emilio: but basically the use case seems to be transitioning modal
dialogs and so on when opening and closing
emilio: and I assume other elements in the top layer
emilio: to me that seems like a use case that non-modal dialogs also
need
emilio: there are dialogs that may not be in the top layer
emilio: so feels to me that this is a clever hack to avoid having
closing/closed state on the dialog and fullscreen things
emilio: not sure if that's been considered
emilio: so why is this property better
emilio: Why not say that it goes from open to non-open, have an
intermediate state, and define that intermediate state
transition as when all its transitions have finished
flackr: Wrt ntim's concern about exposing top-layer to the user, we
have these stacking questions
flackr: this proposal nicely avoids, because things remain in their
current stacking position
flackr: so we don't have to change any of that or figure out those
definitions yet
flackr: I don't understand what non-modal dialogs have a problem,
they can continue to apply their desired z-index
emilio: But you still have the issue of if you want a close
animation on a dialog, you need to do it manually
flackr: Dialog element, which is top-layer?
emilio: Dialog may or may not be top layer depending on show vs
showModal
<masonf> If the dialog isn't modal, it isn't in the top layer, and
you don't need this.
flackr: It would maintain its top layer state during transition, but
still have to define the animation
emilio: Idea is you can do opacity or transform or whatever to hide
the dialog, right?
emilio: Right now that's not easy to do with non-modal dialogs either
emilio: why not have ...
emilio: Firefox has all its panels as well, we have animations when
you use menus
emilio: and those are just web elements
emilio: Internally we have 5 states
emilio: open, opening, closing, closed
emilio: We have intermediate states so that the front end can
actually use transitions for this stuff
emilio: my question is, why is this specific to top-layer and not to
elements that pop in and out
flackr: You can't reasonably establish entry animations is resolved
by setting initial styles
flackr: with that, should be possible to do on non-modal dialogs
flackr: top-layer is the only thing they don't have access to
flackr: the model is consistent with other things that have a state
change trigger an animation
flackr: state changes immediately, even though animation continues
to run
<masonf> non-modal dialogs need the ability to animate to/from
display:none, but that's a separate issue.
emilio: When non-modal dialog closes, you want to ?? animation to
display:none
emilio: You transition display, which we resolved to do but don't
yet do
emilio: so your proposal would be to animation display directly and
also transition opacity
flackr: I have proof of concept for Chrome
emilio: So this proposal is to explicitly allow z-order to remain
while transitioning
emilio: like transitioning display
emilio: On one hand, I think it would be less weird to have these
intermediate states
emilio: when you open dialog, you transition to opening state
emilio: when you update style and don't have transitions running
you're open
emilio: etc.
emilio: When no pending transitions transition to closed
emilio: only targetted to dialogs/popovers/etc. but I think that's
the main use case
emilio: I think that would be slightly less weird for authors
emilio: rather than transitioning display ...
emilio: having magic property seems weird
emilio: I guess this proposal weird, but I think maybe having
intermediate pseudo-classes could be more elegant and usable
for authors
flackr: I think this is more consistent with other state changes for
the Web
fantasai: Why not have things just stay in the top layer until their
transitions are done automatically?
ntim: That seems to make sense
chrishtr: Having a transitioning state and this automatically detect
what they're happening and preserve top layer during UA
was thoroughly explored during popover design
chrishtr: and prototyped in Chromium
chrishtr: Was specific to popover and dialog, and why not have a
generic mechanism in animations
chrishtr: This is what lead to these proposals for display:none
animations and specifying top-layer duration
chrishtr: without specifying UA magic to detect length of animations
chrishtr: discussed at length in popover API proposal
lea: Firstly, it seems weird to have a property that only works in
transitions
lea: if devs want to put things in the top layer, what prevents them
from adding an animation that puts them in the top layer?
emilio: ....
lea: so only available in transitions?
lea: What prevents having a transition that lasts 999999s?
emilio: You'd need to call modal
lea: Trying to prevent devs by adding only to transitions, it's a
hack and can be worked around
emilio: I agree
emilio: Internally, how we implement top layer
emilio: I'm not sure how I feel about this
[missed]
Rossen: Let's end this topic right here
Rossen: we covered quite a bit, but this doesn't seem ready for
resolution
Rossen: Was well articulated and proposed, and good path forward for
addressing some of the TAG review comments
Rossen: Should take conversation back to GH, and should bring it
back when it's more developed
Agenda Setting
==============
Rossen: Two nesting and two color issues, top priority. Order?
chris: Would like to suggest the color issues, think there's
consensus
chris: if agreed, we can close rapidly
CSS Color
=========
Is relative color syntax ready to ship?
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7978
chris: Problem was specifying base color as currentcolor
chris: I added spec text similar to color-mix()
chris: if that's okay by everyone we have solved the issue
TabAtkins: Great for me
Rossen: Anyone else?
RESOLVED: Accept Chris's proposal
<lea> +1
Clarification on how `channel keywords` with multiple specified
types work
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7876
chris: Main issue raised was that the keywords could have two
possible types, doesn't work
chris: either number or percentage
chris: Went with number to be consistent with serialization
TabAtkins: nit pick comment, you accidentally did percentage for
wmb, but otherwise it's great
chris: It's because color-4 it only takes a percentage
TabAtkins: Ah, in that case it's completely fine
chris: Any other comments?
chris: Anyone need more time?
ntim: Didn't have a chance to look at it
lea: Does that mean for rgb they resolve to 0-255 range?
chris: Yes, but remember it's 0.0 to 255.0 so you don't lose
precision
lea: But inconsistent with rgb models
chris: Because it was invented poorly
lea: I agree but does that mean we don't need relative color syntax
for rgb?
chris: I have a lot of trouble coming up with use cases
chris: I haven't found a good example
lea: I think it's primarily for completeness, but we don't generally
do things just for completeness
lea: restrict to color()?
chris: I wouldn't go that far
chris: Let's resolve this and deal in other issues?
chris: Get consensus on going to number?
Rossen: So do we have enough consensus?
lea: Consensus is about every component that's "number or something
else" resolves to number?
lea: so hues resolve to numbers?
chris: Yeah, all examples treat hues as number
chris: so I think most ppl are treating as numbers
lea: Yes, that's what authors do
<argyle> +1 to number
[...]
chris: Proposal, keywords with multiple specified types result in
number
Rossen: Any additional feedback or objections?
jensimmons: This is fine with us from Apple
RESOLVED: Keywords with multiple specified types result in number
CSS Nesting
===========
Problem with mixing properties and selectors
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8249
TabAtkins: I'm willing to summarize what I believe plinss's position
is, he can correct
TabAtkins: Fear is that the direction the spec is specifying will
overly constrain future CSS
TabAtkins: certain new syntactical things in properties or selectors
TabAtkins: Proposal is instead to have a dedicated syntax to mark
things as a selector
TabAtkins: that way all future syntactical developments would still
be allowed
TabAtkins: and future developments for selectors, which might
currently conflict with properties, would also be allowed
TabAtkins: because you have a glyph to mark it as a selector
TabAtkins: Related is the 8251 issue, where dbaron discusses the
things that trigger selector processing and not currently
used by selectors
TabAtkins: this issue accepts mixing of properties and selectors in
grammar space
TabAtkins: Issue is, we've already discussed previously, what plinss
is suggesting
TabAtkins: This was Option 1, you had to start with & or @nest or
various variants thereof
TabAtkins: This was rejected by WG for verbosity and for copy-paste
limitations
TabAtkins: Core issue is, WG has looked over that syntax direction
and rejected it in the past
TabAtkins: so I would like to re-affirm that decision, that we're
not going to use a dedicated marker syntax of some kind
to denote selectors and separate them from properties
TabAtkins: but rather go with current approach of mixing the space
TabAtkins: make sure the Syntax spec creates a clear dividing line
fantasai: I think something Tab didn't emphasize is the core part of
Peter's concern for forward compat
fantasai: The real effect of forwards compat isn't as - we're not
limiting as much as it seems like we are
fantasai: What we're allowing for the future is anything that's
invalid, regardless of whether it's currently property or
selector
fantasai: The space of "what is invalid junk" is actually really
broad even with our current proposal
<fantasai> https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982
fantasai: The only thing we can't expand into is a super-limited
syntax space that I can't imagine us actually doing
<fantasai> #stuff starting with a symbol { anything in this block }
valid-property: value;
fantasai: We can't start with a symbol, *and* has a curly-brace
block *and* is followed by something that looks like a
property
fantasai: This is the only thing you can't define in the future is a
cool new feature
fantasai: If it doesn't look like that it's invalid - whether a
property or style rule, we throw it out
fantasai: And in the future we can call it valid either way
fantasai: So for concern about painting us into a corner, it's
actually a very small corner and the rest of the space is
open
plinss: Just want to clarify a couple points, most of what Tab said
is accurate
plinss: it's not necessarily required to have a solution that
prefixes every single rule
plinss: Also fine to create a new scope
plinss: just nested brackets or whatever, that also solves the
copy-paste problem
plinss: Just want something that delineates the syntax space
plinss: We did resolve not to do this in the past, but I'm not sure
that took everything into account
plinss: not locked by previous decision
<astearns> +1 to not taking older @nest decision as final
<fantasai> would have also wanted to delineate syntax space, but we
didn't get there
jensimmons: I did hear plinss's concerns, and we've discussed
exhaustively
jensimmons: but despite downsides, I see all the momentum going
towards Option 3 including from webdevs
jensimmons: There was a lot of conversations after final December
meeting, and I appreciate dbaron, fantasai, TabAtkins
investigating what we would limit ourselves
jensimmons: but it seems we're not really limiting ourselves, so I
think should move forward
jensimmons: Want a path that moves us forward and is realistic and
acceptable
lea: A lot of things I wanted to say were mentioned by fantasai,
still have a lot of space for expansion
lea: but we could expand that space even further by reserving some
characters
plinss: I'm not sure I buy fantasai's argument
plinss: it's not infinite, but there are cases where we wanted to do
something but couldn't because shows up in the wild as some
weird hack
plinss: I think it'll be limiting
plinss: Example is custom properties, couldn't have done that if we
had done this first
plinss: I don't want us to get into that situation
fantasai: Lets take the custom property example
fantasai: say initial hyphen switched us to selector parsing
fantasai: we could do it
fantasai: You'd throw it out as an invalid selector today
fantasai: And that means we can reinterpret it later
fantasai: Have you really looked at what the limiting case is?
fantasai: The conditions are really strict. anything that's
currently invalid and gets thrown out, we can reinterpret
fantasai: have to keep in mind that the parsing in the nested
context isn't the same as top-level, we truncate at
top-level semicolon even in selector parsing
fantasai: So there's very limited - can't think of anything you want
to do that'll cause a problem
<lea> *Nesting itself* is a case where past syntax limits us in what
we can do syntactically (going back, maybe we should have used
something other than a colon for pseudos), but it's not an
insurmountable problem, we are designing around it. We'll
design around these issues in the future too, if they come up.
plinss: We could solve this with lookahead
plinss: Also concerned that we have stuff that's valid for selectors
and can't re-use for properties
plinss: selectors can be really really really long, especially with
lists of selectors
plinss: Thing at the end that changes selector or property, could
get into situation that we cant solve without a lot of
lookahead
<lea> regarding exploring lookahead, I tried. Here's a summary:
https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362739063
Rossen: I've closed the queue, 2min past the hour
Rossen: Strong arguments in both directions
Rossen: Alan proposed we make nesting an additional call, can make
it as soon as next week e.g. 1hr before the main CSS call
Rossen: but right now we don't seem to have consensus
<lea> +1 to Nesting breakout
Rossen: or we can take a resolution and ask Peter to file a formal
objection
TabAtkins: I would prefer to get the formal objection filed now if
it's going to be filed, would rather not be in limbo
<lea> let's try to avoid a FO as much as we can, the TAG is already
overworked :(
<lea> we need a Nesting breakout even regardless of the FO, don't
we? So let's schedule that
TabAtkins: fantasai and I explored the syntax space carefully, we
don't think there's a real limitation there
TabAtkins: so I don't think further discussion will yield anything
useful
Rossen: ok, we'll try to have a call for nesting, whether this topic
is part of it or not is TBD
Rossen: I will call for objections, and then have a resolution that
seems supported by rest of group
Rossen: Any objections?
plinss: I clearly object. More than happen to have the long call or
breakout or sub-breakout or whatever
plinss: Happy to let Tab and fantasai convince me that I'm wrong
plinss: and to change my mind
<oriol> I'm more on Peter's side on this topic
plinss: but shy of that, or changing the processing rules, I sustain
my objection
Rossen: It does seem this has been discussed over and over, and I
hear support for this from many people
Rossen: so suggest we resolve this, or take up as additional changes
to the current resolution
plinss: We've resolved on Option 3 with this issue open
plinss: still saying we can discuss at the breakout call, so what's
point of resolving?
Rossen: We resolved to discount other options, not to adopt Option 3
[some discussion of what we resolved or didn't]
<lea> fwiw, I agree with plinss that lookahead should be explored
more. But not primarily for futureproofing (I think there's
enough syntax space that we're not painting ourselves into a
corner), but primarily for syntax ergonomics. I'm not
convinced it's an unsolvable problem.
jensimmons: Would be helpful to take the temperature of the room
fantasai: straw poll, and then close discussion until next week?
Rossen: A = support Option 3, and B = not support it
<argyle> A
<jensimmons> A
<ydaniv> A
<TabAtkins> A
<fantasai> A
<oriol> B
<bradk> A
<SebastianZ> A
<miriam> A
<plinss> B
<dholbert> A
<GameMaker> A
<flackr> A
<davidleininger> A
<futhark> A
<florian> A
<lea> I find the question unclear, so I'm not voting.
* fantasai also doesn't like not having a split syntax space, but we
haven't had any acceptable proposals to split it
<lea> A
<Rossen> A
Rossen: Pretty strong signal here, let's go ahead and record this as
a resolution. We will try to get the extra nesting
discussions, Peter I'm hoping you can proceed with next
steps if you want to pursue formal objection or wait until
next week
plinss: Happy to discuss on breakout call, but want to actually get
to it
Rossen: We've never had a rule that we can't re-open previous
resolutions :)
plinss: That's been the argument several times
florian: From the other angle, if you do file an FO and are
subsequently convinced, you can retract it
plinss: If discussing in a week, don't need to file an objection
today
Rossen: We'll schedule for next week then
jensimmons: Please schedule for next week, it's quite important to us
RESOLVED: Adopt Option 3
Rossen: I appreciate everyone staying longer than usual, we don't
almost ever, but this is an important topic to many
Rossen: We'll schedule an additional meeting next week
Received on Thursday, 12 January 2023 11:02:25 UTC