[CSSWG] Minutes Telecon 2022-12-21 [css-nesting] [scroll-animations]

  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
  - 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)


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Dec/0014.html

  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
  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
  plinss: Another alternative is we say screw it and adopt the Sass
  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
  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:

  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
              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
  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

Scroll Animations

Don't preserve current time for scroll linked animations when changing
  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
  flackr: So this proposal is that scroll-linked animations doesn't
          try to preserve their current time when you change playback
  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
  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
  <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
  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
  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