- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Dec 2022 19:29:50 -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.
=========================================
CSS Nesting
-----------
- The poll showed a clear preference for option 3 for the nesting
syntax (Issue #8248: Choose Nesting syntax — Option 3, 4 or 5?).
There were objections on the call that this solution's mixing of
selectors and properties will create future limitations on the
language.
- RESOLVED: Reject options 4 and 5, go with option 3 with continuing
refinement (Issue #8248: Choose Nesting syntax — Option
3, 4 or 5?)
Scroll Animations
-----------------
- RESOLVED: Accept flackr's fix [When setting the playback rate,
skip step 4 (setting the current time to previous time)
if has finite timeline (i.e. the timeline is scroll
linked)] (Issue #2075: Don't preserve current time for
scroll linked animations when changing playbackRate)
- RESOLVED: Newly-discovered timelines trigger a new layout at the
RO portion of the frame lifecycle. (Maybe other times,
tbd.) (Issue #5261: Behavior of scroll-linked animations
in the first frame)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Dec/0014.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Daniel Holbert
Brad Kemper
Jonathan Kew
Chris Lilley
Peter Linss
Nigel Megitt
Tim Nguyen
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: TabAtkins
Scribe's scribe: fantasai
CSS Nesting
===========
Choose Nesting syntax — Option 3, 4 or 5?
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8248
jensimmons: We ran this survey and wrote an article on webkit.org
jensimmons: Even though it was bumpy, I think the results are very
clear
jensimmons: There's a lot of comments on twitter/mastodon/HN
jensimmons: And a very clear pref for Option 3
TabAtkins: Sounds like strong consensus
plinss: I have concerns.
plinss: I don't think we should decide purely by the poll.
plinss: That'd be fair if we had 2 or 3 options that were equivalent
plinss: But I think this is more involved than that, there are
ramifications people weren't taking into account
plinss: Looks like a lot of people just want Sass, that's most votes
for Option 3.
plinss: And the more I think about it, the more concerns I have with
mixing selectors and properties.
plinss: Really not happy with the future constraints we're putting
on the language.
plinss: Fundamental problem is that anything that's not obviously a
property defaults to be a selector, and that constrains our
ability to ever extend property syntax again.
plinss: The default needs to be that it's a property and we need an
indicator that it's a selector
plinss: Like @nest. I know that was rejected for verbosity, but I'd
be okay with a bare @
plinss: A lot of people are also supportive of Option 3 with
mandatory &, and we could have @ do that.
plinss: So that's a compromise I can live with.
astearns: I think I agree with Peter to a certain extent, but I
would want to have an idea of the kinds of things we are
cutting ourselves off from
astearns: I don't know what it is that prioritizing selectors over
properties will make difficult to extend in the future
plinss: For example, I think we wouldn't have been able to do custom
props the way we did if we had this
plinss: Once upon a time idents started with a letter or a single
dash, and I'm not sure what else we'll want to do with
properties, but we'll have to invent some weird syntax.
astearns: I think I agree with the argument that if Sass nesting had
never existed, that when we were adding this feature we'd
do something more like option 5; we wouldn't consider
option 3 at all.
astearns: but the existence of Sass nesting is a design constraint
that we really do have to respond to, and option 3 does do
that
plinss: Another alternative is we say screw it and adopt the Sass
syntax
plinss: A lot of people are opposed, but I'm curious if we can't
afford it.
plinss: Back when we first started this, at Gecko, I had everyone
telling us we couldn't do CSS due to perf.
plinss: Maybe we can afford a recursive descent parser now and do
Sass syntax.
plinss: And that's something I'd be okay with too, because you're
fully resolving everything.
plinss: I think it still gives us some potential for conflict but
it's not as bad.
TabAtkins: What we are prevented from extending in the future
TabAtkins: 2 aspects: need to avoid selectors and ??
TabAtkins: On selector side, means we can never add a new bare
function syntax
TabAtkins: We have pseudo-classes that are functional, that's fine.
But we can't add a plain function to selectors
TabAtkins: That doesn't seem like it would be a problem, lots of
space for symbol-prefixed
TabAtkins: over on properties, need to start property with either
ident or function
TabAtkins: can put stuff after ident/function
TabAtkins: just can't put before the property
TabAtkins: That does mean if we had done this in the past, we'd have
had to do some compat analysis about allowing ident to
have --start
TabAtkins: that was a change, but technically also needed to care
about compat because previously invalid now valid
TabAtkins: Those sorts of changes are likely ... if we need to
change ident syntax in the future, we can navigate those,
and unlikely to look like selectors too much
TabAtkins: doubt problem, and we have compat tools to figure it out
TabAtkins: Beyond changing ident syntax, I don't think we're losing
any important syntax space
TabAtkins: Some ideas to put things before the properties, e.g.
early sketches of additive cascade used + before/after
property name to indicate prepend/append
TabAtkins: but we can choose an alternative syntax
TabAtkins: in practice not a large restriction
TabAtkins: large amount of syntax space we've left unexplored
TabAtkins: and rare places where might collide, can analyze so not
shooting in the dark
TabAtkins: More generally, we've been talking about nesting syntax
for a year, need to close the door at some point
TabAtkins: Can't keep having people propose new alternatives
TabAtkins: latest option 3 is good improvement, and people like it
TabAtkins: If we continue messing around, and ignoring things like
80%-90% poll results, is going to make people angry, and
won't accomplish anything
TabAtkins: more polls will result in similar result
Rossen: Want to close the discussion, lots of tension but I also
want to get to at least one more issue
Rossen: will close the queue, drain it, and if we can't have a path
for resolution, then we'll put to GitHub
plinss: I hear what you're saying about syntax, but just want to be
clear that we're blocking ourselves off from prepending to
an ident. I think it's a decision we'll regret
plinss: I think default to selectors was the wrong choice here
plinss: I'm sympathetic to "we've discussed forever"
plinss: But don't think we should take a decision that has problems
we haven't thought through
plinss: We have responsibility for the long term
plinss: Not just to respond, but to the long term
fantasai: I'm sympathetic to Peter's arguments but also agree with
Tab that we need to close on this
fantasai: In terms of forward compat, we should be setting things up
within these declaration blocks that the parse stops at
either a semicolon or a block
fantasai: and you throw out whatever as invalid
fantasai: Gives us some space to work with
fantasai: So we should design invalid in a way that gives us room to
extend
fantasai: think we can
fantasai: and if there's specific bits of syntax we want to leave
open for extensions, we can do that
fantasai: Like if it starts with @ without an at-rule treat as a
prop, etc
fantasai: But I think we should go with Option 3 as we have it now.
Maybe small tweaks to ensure max compatibility, but think
we should go with that for now
argyle: Happy to see this discussed
argyle: Wanted to mention we can't do exact Sass syntax. We can
match as much as we can, but "just do Sass" isn't on the
table. We've adopted as many tradeoffs we can.
argyle: So I think this has been in the tumbler enough to be a pearl
<bradk> +1 to possibly prepending ‘@‘ in the future to indicate it
is a selector that follows
argyle: I like where we are now with all the options
jensimmons: I think last time I expressed my opinion I was against
option 3 and liked 4, and liked 5 when it came up
jensimmons: But while writing the article I started really hating
Option 4 with a passion. There's still something about 5
that appeals, but I really think we should resolve on
option 3, hopefully today
jensimmons: I agree with Peter that a lot of people potentially
didn't understand the gotchas with 3
jensimmons: But there were so many comments from people who really
did understand the gotchas, including several asking for
mandatory ampersand as a way to compensate
jensimmons: So I think there is enough understanding from webdevs
jensimmons: Also convos internally in Apple - maybe we will find a
way to do lookahead that's fast enough.
jensimmons: so we would be able to relax the syntax restriction
<TabAtkins> (Option 3 is indeed extensible to Sass version later, if
we want)
jensimmons: I agree polls shouldn't dictate us, but given the fact
that Option 3's big gotcha is webdevs might get
confused, but watching their comments I got a lot of
confidence that option 3 is the way to go
Rossen: So I've closed the queue. There's some clear statement of
concern raised by Peter, and a clear voice of wanting to
adopt 3 and make it work.
<bradk> +1 to resolving on option 3 today
<bramus> +1 on moving forward with option 3
<lea> Many people got confused at my polls as well. I think the
article did a great job at explaining the options, and no
matter what we do, people will get confused anyway.
<lea> +1 on resolving on option 3 today
Rossen: So I'd like to try for a resolution, we'll see if we get a
strong objection.
plinss: I'm objecting to option 3 as it stands. Okay with trying to
refine it further, but don't think it's the right decision
as it stands.
<lea> Related to refining option 3 further:
https://github.com/w3c/csswg-drafts/issues/7961
Rossen: So to be clear - we want to narrow on Option 3 with options
to refine it.
Rossen: [doing a straw poll]
Rossen: Options are 3, 4, or 5 as stated in the poll.
<bradk> 3
<argyle> 3
<flackr> 3
<lea> 3
<TabAtkins> 3
<bramus> 3
<jensimmons> 3
<ntim> 3
<dholbert> 3
<matthieudubet> 3
<miriam> 3
<rachelandrew> 3
<fantasai> 3
<fantasai> Conditional on ; terminating the selector parse
<TabAtkins> It does already do that, yeah
<TabAtkins> (the details are in Syntax)
<TabAtkins> See
https://w3c.github.io/csswg-drafts/css-syntax/#consume-qualified-rule
for the ;-termination
fantasai: Note that my support is specifically if semicolon
terminates the selector parse, so we can extend in the
future more safely
TabAtkins: Algorithm already terminates on ; if you think you're
parsing a selector
<dbaron> how many valid selector beginnings are we accepting if we
take option 3?
<dbaron> (is it more than &, :, and combinator symbols?)
<fantasai> (no, I don't think it is)
<TabAtkins> dbaron, anything other than ident or function is a valid
selector beginning, so long as you don't encounter a ;
before the {
<chris> 3
<dbaron> abstain
<nigel> abstain
<astearns> abstain
<jfkthame> abstain
<ydaniv> abstain
<smfr> abstain
<florian> abstain
<Rossen> abstain
<dbaron> (abstaining because I think we could refine 3, I think)
<nigel> (Having read the comments around the poll, refining 3 seems
like the best option)
<bradk> or some people are on call but not paying attention
Rossen: Looks balanced between 3, abstain, and not saying anything,
don't think we can resolve on that
<astearns> I think we need an issue on the specific problem of 3
boxing in syntax, with examples and possible ameliorations
Rossen: Can we leave Option 3 as the only path forward to refine?
Rossen: Peter are you okay with that path forward?
plinss: I'm fine with improving our efforts on improving option 3,
I'm not okay with excluding any new ideas
Rossen: Right, just want to narrow down to option 3 from the options
we have now
Rossen: dbaron, you had an issue?
dbaron: Think we're better off working it out in an issue.
Rossen: So we're rejecting Options 4 and 5, and continuing to refine
Option 3. Is that a resolution?
<flackr> I think a parser switch would be fine if we had to do it.
Could be confusing but developers shouldn't switch back to
property syntax after nesting selectors.
<astearns> I disagree with that suggestion, flackr :)
<flackr> :)
lea: It looks like there's a strong sentiment behind option 3 "but
refine it", but it seems that refining means different things
to different people
lea: Peter seems to be saying something more - not mixing selectors
and decls in the same context.
lea: So it might be reasonable to have a list of things we're
looking to refine.
plinss: To clarify, I'm not fully opposed to mixing selectors and
properties at all, I just think we need a system that favors
a property unless it's explicitly indicated as a selector
<dbaron> I think plinss's "single mechanism" might be too strong,
but I think we could certainly find a different balance of
which future syntax goes down the property path versus the
selector path without changing any valid-today syntax in
option 3.
Rossen: I want to close down this discussion today. So proposed
resolution: narrowing down to Option 3, with continuing
improvement before it's accepted
fantasai: Just want some clarity - it seems Peter wants to separate
out property/selector syntax with some symbol that
indicates "you're now in selector mode" and he wont'
accept anything other than that. That's not option 3, it's
a previous option we've already considered.
fantasai: But Option 3 is interweaving mostly freely.
<argyle> option 1 as nesting-1, work out option 3 as nesting-2..
still think that's a valid plan forward
<chris> we can go back to that previously rejected option if there
is new information, yes
dbaron: I think one of peter's concerns was the % of stuff that goes
down selector vs property path, and where future things that
are invalid today will go
dbaron: I think we can work out something that puts less stuff down
the selector path and more down the property path.
fantasai: I think things that are invalid today, both go down the
same path - parse until you hit the semicolon then throw
it away as invalid.
plinss: I'm fine with David's refinement. Don't need a single way to
say it's a selector - I'd prefer it, but a few ways will
work too.
fantasai: Right now the final indicator is a semicolon or a {.
fantasai: if you're saying "I want specifically the three symbols"
not combinators, that's something else
fantasai: If that's the main objection we can go back and say you
*have* to start the selector with a simple selector
plinss: My problem with that is any random new combinator we add
will have to be treated as a selector. It's open-ended, and
I want it to not be open-ended. that's the crux of my
objection.
lea: We're already nearly full on combinators anyway, probably
future ones need to be /foo/ or something
plinss: We can maybe say "only today's combinators and a slash,
nothing else", but I think that's limiting
<fantasai> I agree with that being too limiting
Rossen: Ending the topic. I called for objections. Are there any?
Rossen: No objections.
<chris> \o/ progress!
RESOLVED: Reject options 4 and 5, go with option 3 with continuing
refinement
Scroll Animations
=================
Don't preserve current time for scroll linked animations when changing
playbackRate
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2075
flackr: We set up scroll-linked animations so the time of the
timeline in which you play them isn't used for the start
time, that would lead to skew with pages starting their
scroll-linked animations after the scroll started
flackr: We didn't account for some of the other APIs though. I did
an audit and playbackRate is the only one we haven't fixed
yet.
flackr: So this proposal is that scroll-linked animations doesn't
try to preserve their current time when you change playback
rate
flackr: I landed a simple fix, but Kevin brought up that when you
reverse the animation via negative playback rate, we should
fix it the same way as when you actually do a reversed
animations.
flackr: So I landed a fix to change the start time there.
flackr: This aligns the playbackRate change to the behavior when you
call .play()
<TabAtkins> I didn't look in detail but the explanation makes sense
to me
Rossen: Objections?
RESOLVED: Accept flackr's fix
Behavior of scroll-linked animations in the first frame
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5261
flackr: So scroll-linked animations are based on layout of elements
flackr: but they can be discovered during style parse
flackr: and scroll-linked animations can affect the style and layout
flackr: So we need to define the interaction during the initial
lifecycle update
flackr: I have a PR that updates similarly to ResizeObserver - after
doing style and layout, you can do one more loop to handle
scroll-linked animations you've found. Unlike ResizeObserver
it's bounded to a single loop, and it runs in parallel with
ResizeObserver so it's not an additional loop on top of that.
flackr: Anders prefers the approach where JS-constructed scroll
timelines, we also don't freshen their time until after
style and layout, so authors can observe they don't have a
time initially, but after the style/layout update we'd
repeat with times. I don't have a strong pref so I'm okay
with that unless people feel we should force a style/layout
immediately
<TabAtkins> +1
emilio: What are implications of not doing this second pass?
emilio: Is it just we don't start a timeline because there's no
scroller, so they see it next frame?
flackr: Yes, the first frame is incorrect because no SLA is done.
Often completely missing the animation style, which I think
is unacceptable due to likely flickering
smfr: Is this unique to scroll-linked animations because the scroll
position is input and you don't know it until layout?
flackr: No... sorta
smfr: Unsure why it's not a problem with normal animations
flackr: We update animations at the point they're discovered--
you're right, determining the timeline time requires a
layout update
emilio: And when are you proposing to run the second pass?
unconditionally, or only when you discover new timeline
animations?
flackr: Only when discovering new animations, and only once per
lifecycle update
flackr: We can define it to either be animations discovered during
the style/layout cycle - idea is we'd have a flag on these
timelines and check if it's a non-empty set
emilio: Do we want to do it with script-triggered updates, or more
like ResizeObserver where it's only [...] loop?
flackr: My proposal is to only do ResizeObserver
emilio: I think that's slightly better
emilio: We have some things that do similar, like focus fixup and
stuff
emilio: Just we have several things that can trigger multiple passes
and need to make sure they're properly defined
emilio: what happens if you do two script queries?
emilio: You have a pending style change, do gBCR(), and that
discovers new timelines
emilio: Would a second gBCR() return a different result?
flackr: By spec, no. Scroll timelines only update their time at the
start of the frame and during this discovery, at RO time.
emilio: Okay as long as this doesn't make us return something
inconsistent during a single frame I think that's fine
ydaniv: The point where times are incorrect is just when the page
loads and there's no scroll, right?
flackr: This can happen for any inserted content
flackr: So if you insert a scroller that's not laid out yet, it'll
happen too
emilio: Or if display property changes
ydaniv: So it might require devs to have something like "always poll
once on rAF" to make sure they have the correct time?
flackr: If you waited for rAF... yeah you'd have to poll it once
flackr: because the scroll timeline would not have determined its
correct time yet
flackr: It will be the time the frame is produced, but rAF happens
before that
ydaniv: Might be a good idea to prevent - sounds like a footgun to
me if any change might get us into a wrong current timeline
flackr: This goes back to emilio's comment about JS-forced updates
flackr: If we decided it did, it would give you the correct result
in these cases, but it also makes it a larger potential
performance footgun
flackr: My argument for why this is okay is that this is consistent
with RO - it'll be wrong at the same times.
flackr: So not inventing a new footgun, just following the path of
an existing one.
emilio: Main concern is that RO... you can't query RO arbitrarily,
only get your callback invoked
emilio: So if there are use-cases to get the right answer from
script, that might be slightly preferable
emilio: But my pref is also to have a well-defined time during the
frame that does the right thing
Rossen: Given we're over time, we can take this to the issue or do
you have a scoped part of this resolution to take up?
flackr: I think we can resolve that we will repeat the layout for
newly-discovered timelines in the lifecycle, but leave to
the side whether forced style updates will do this as well
Rossen: Objections to the scoped resolution?
emilio: Works for me
RESOLVED: Newly-discovered timelines trigger a new layout at the RO
portion of the frame lifecycle. (Maybe other times, tbd.)
<Rossen> Also, THANK YOU for all of the scribes who helped with
minutes over the course of this year!!
Received on Thursday, 22 December 2022 00:30:31 UTC