[CSSWG] Minutes Telecon 2023-11-22 [css-2023][view-transitions][css-grid-3][masonry][css-values]

  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 Snapshot

  - RESOLVED: Add View Transitions 1 to "fairly stable" in Snapshot
              2023 (Issue #9577: Move CSS View Transitions to "fairly
              stable" in CSS 2023)
  - RESOLVED: Publish snapshot 2023 with css-view-transitions moving to
              fairly stable and css-scroll-snap moving to rough
              interoperability (Issue #9566: Finish up CSS Snapshot
  - RESOLVED: Republish snapshot 2022 as Group Note (not Draft Note)

View Transitions

  - RESOLVED: view-transition-name is discretely animatable (Issue
              #9619: Is view-transition-name discretely animatable?)
  - RESOLVED: :active-view-transition(*) has specificity of 1 class,
              :active-view-transition(list) has specificity of 2
              classes (Issue #9546: :active-view-transition()

CSS Grid 3 & Masonry

  - RESOLVED: Accept some form of masonry slack property; exact
              algorithm TBD; exact name TBD (Issue #9328: Reordering
  - Though it was clear how Masonry would handle <auto-repeat>
      accepting intrinsic sizes, it was more uncertain if it could work
      in Grid. Discussion will continue in issue #9321 (Allow
      <auto-repeat> (i.e. repeat(auto-fill|auto-fit, ...)) to accept
      intrinsic sizes) to understand further how it could be added to

CSS Values

  - RESOLVED: Restore text simplifying out single-argument min/max
              functions (Issue #9559: Simplification algorithm should
              possibly return single child for min/max)


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Nov/0005.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Oriol Brufau
  Keith Cirkel
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Paul Grenier
  Daniel Holbert
  Brian Kardell
  Jonathan Kew
  Peter Linss
  Noam Rosenthal
  Khushal Sagar
  Miriam Suzanne
  Bramus Van Damme
  Sebastian Zartner

  Chris Harrelson
  Chris Lilley
  Lea Verou

Chair: Rossen

Scribe: noamr

Agenda Setting

  rossen: Do we want to change topics?
  rossen: I added a topic at the zoom bottom
  though Chris Harrelson asked to delay by a week
  rossen: Both Alan and I received requests to discuss this week
  rossen: If we have enough people we can discuss this week
  rossen: if it can wait and we don't have enough people we can postpone
  emilio: Would like to discuss them but can also wait a week if Chris
          is interested
  rossen: Thank you, appreciate the flexibility
  rossen: will make sure they're first on agenda next week
  rossen: Other changes?
  rossen: Silence, take it as a no

F2F Scheduling

  rossen: About the f2f
  dbaron: There was an email thread on the wg list
  TabAtkins: Ideally it would be Feb 12,13,14, beginning of the week
  rossen: We didn't have a resolution. can we have one or can it wait?
  fantasai: Is there a possibility there wouldn't be space? should we
            worry about this?
  TabAtkins: Wait till I confirm the space, booking should be after.
             Waiting for admin for spaces soon. certain about
             confirmation next week
  <khush> What's the tentative location?
  <dbaron> I think tentative location was SF Bay Area
  TabAtkins: Let's get it on record next week
  rossen: ok, let's do this next week
  rossen: Let's continue with agenda
  <TabAtkins> oh yeah and locations has *not* been confirmed yet anyway
              so booking flights is impossible ^_^
  <TabAtkins> (aiming for mtv with seattle as secondary)

CSS Snapshot

  rossen: 1st topic is finishing the CSS snapshot
  rossen: Anything else we need to add?

Move CSS View Transitions to "fairly stable" in CSS 2023
  github: https://github.com/w3c/csswg-drafts/issues/9577

  rossen: Chris said he's in favor of this
  rossen: Anyone else that has opinions on this or objections
  fantasai: I agree with that, it's fairly stable, level of issues
            dropped to a low level, and we have an implementation so we
            worked out all kinds of kinks
  rossen: Objections to moving VT to fairly stable?
  rossen: With no objections, calling this resolved

  RESOLVED: Add View Transitions 1 to "fairly stable" in Snapshot 2023

Finish up CSS Snapshot 2023
  github: https://github.com/w3c/csswg-drafts/issues/9566

  rossen: SebastianZ, with the prev resolution to move
          css-view-transitions-1 to fairly stable, what else is
  SebastianZ: This was the most obvious 1 that was missing. anything
              else interoperable to add into the spec?
  SebastianZ: I myself went through the specs and didn't find something
              in the status, but perhaps missed one
  rossen: I was going to put the question back to all of the group. Are
          you working on any spec that can move to other state before
          we close the snapshot?
  rossen: Let's assume this is the only one. Chris Lilley was also
          didn't have opinions on this. Didn't hear anything else

  RESOLVED: Only change is the snapshot to record today is add
            css-view-transitions-1 to fairly stable

  rossen: Going back, css scroll snap? It was already in the spec,
          Chris Lilley fixed

  RESOLVED: Publish snapshot 2023 with css-view-transitions moving to
            fairly stable and css-scroll-snap moving to rough

  SebastianZ: Not sure if this needs a resolution, but css 2022 is
              still published as group draft note
  <dbaron> https://www.w3.org/TR/css-2022/

  RESOLVED: Republish snapshot 2022 as Group Note (not Draft Note)

  rossen: We have both resolution now, that's all on the issue
  SebastianZ: No other point
  rossen: Let's jump into the view transitions topic

View Transitions
  scribe: fantasai

Is view-transition-name discretely animatable?
  github: https://github.com/w3c/csswg-drafts/issues/9619

  khush: Question was about view-transition-name, currently discretely
  khush: but doesn't make much sense to be animatable
  khush: feeds into pseudo-element DOM
  khush: I would be OK making not animatable instead

  flackr: We've made this mistake on a few properties in the past,
          thought they shouldn't be animatable and then took compat
          risk to make it animatable later
  flackr: If no strong technical reason to make them discretely
          animatable, would prefer to err on that side
  khush: I don't have a strong opinion either way
  khush: maybe we should wait for ntim
  <astearns> +1 to discrete animation as a default to use unless we
             have a good reason not to
  noamr: There is a reason to make things discretely animatable for
         things not animatable, because people use animation-delay in
         various strange ways
  noamr: e.g. "in 10s this property would change"
  noamr: could be useful for view-transitions as well
  Rossen: We could resolve to keep discretely animatable, and if Tim
          has reasons to argue opposite, he can bring it back

  scribe: TabAtkins

  fantasai: What does it mean to change VT-name halfway thru an
  noamr: For regular keyframe animations, at 50% view-transition-name
  noamr: view-transition animation itself doesn't change it
  fantasai: So you're saying that view transition-name isn't animated
            during a VT, but can be during a regular animation
  fantasai: In which case the value of the property gets captured at
            its current animated state if you trigger a VT during the
  noamr: Yes. And that could be, like, an animation-delay just to
         timeout a change
  noamr: people use that for timeouts sometimes

  khush: It sounds like the reason we want it to be discrete animatable
         isn't a VT issue, just CSS in general.
  khush: Wanted to add was, keeping it discretely animatable has
         nothing to do with view transitions
  khush: but general CSS
  khush: We could add a note to [missed]
  <flackr> https://www.w3.org/TR/web-animations/#not-animatable
  khush: Could we add a note to Animation telling spec authors to make
         the property discrete unless there's a good reason?
  flackr: The first note there explains when props *should* be excluded
          from animation

  Rossen: So conversation leads me to ask for resolution, to keep as
          discretely animatable. Objections?
  fantasai: I think given it doesn't affect VT animation it's probably
  fantasai: We can go back to Tim and check with him
  Rossen: Right, there's agreement on the call and if Tim feels
          strongly we can bring it back up

  RESOLVED: view-transition-name is discretely animatable

:active-view-transition() specificity
  github: https://github.com/w3c/csswg-drafts/issues/9546

  vmpstr: With view-transition types we have a way to specify a type in
  vmpstr: It enables :active-view-transition() on the root
  vmpstr: Either takes an * or a list of comma-separated types
  vmpstr: * matches any type, including none, if there's a VT running
  vmpstr: list of names uses OR semantics
  vmpstr: So, specificity of pseudoclass
  vmpstr: Suggest we have (*) be 1 class specificity, (list) be 2
  <khush> +1
  <TabAtkins> Doesn't seem unreasonable since the list is class-like,
              and it's valuable to have *some* specificity from the
              * one
  miriam: I find it somewhat confusing but I think it works

  YehonatanDaniv: I was wondering why not use the same as :is()?
  YehonatanDaniv: Same as its contents, so * would function as 0
  vmpstr: The :active-view-transition(*) is still more specific than
          not specifying anything at all, since it only matches when a
          VT is active
  vmpstr: So that's why I'm proposing 1 and 2, rather than 0 and 1

  fantasai: I think this makes sense. If we end up with more complex
            logical within :active-view-transition() we probably want
            to expand the rule
  fantasai: Like if you later can say "a view-transition with both foo
            and bar" it should have 3 class specificity
  vmpstr: Agreed

  miriam: I wonder if a general way of stating that rule is that it's
          "is-like" + the pseudoclass
  TabAtkins: It's not really a selector - the class names aren't class
             selectors, so you'd have to map it anyway. Same complexity
             as just saying it.
  fantasai: Probably not quite true, but as simple as it is now it's
            fine to be manual
  bramus: Right now authors could write :active-view-transition(foo)
          :active-view-transition(bar) to match both with a higher

  emilio: Isn't this an or rather than an and?
  TabAtkins: Yes, the discussion was about possible future syntax.
             Today's syntax is just a flat 1-class specificity
  emilio: Can we just sort out that future stuff when we add it in the
          future then?
  TabAtkins: Yes

  vmpstr: So proposal: :active-view-transition() specificity is 1 class
          if it takes a *, 2 classes if it takes a list.
  fantasai: Can it be empty?
  vmpstr: Not valid syntax
  fantasai: Should it be valid?
  vmpstr: That's basically what * does, unsure what benefit it would
  fantasai: Just in general if there's a reasonable default behavior we
            allow omitting
  vmpstr: I think that might be a separate issue
  fantasai: yeah

  RESOLVED: :active-view-transition(*) has specificity of 1 class,
            :active-view-transition(list) has specificity of 2 classes

CSS Grid 3 & Masonry

Reordering threshold
  github: https://github.com/w3c/csswg-drafts/issues/9328

  fantasai: In an earlier issue Ian suggested there should be some
            control over high sensitive masonry is to exact height
  fantasai: Like if all your items are identical in size you'll lay out
            your content in perfect rows, straight across
  fantasai: But if it's different sizes, column 2 was a little bit
            taller, you might skip from column 1 to column 3
  fantasai: Ian suggested it might be useful to tweak the sensitivity
            so it's not just "is the difference 0", but to allow some
            amount of fudge factor
  fantasai: So if the column 2 is only 10 px taller than column 1 and
            3, you don't skip it, you place 1-2-3
  fantasai: So do we want to add a control? Presumably takes a length
            which is the fudge factor. And what do we call it?
  <TabAtkins> +1 to adding it
  <TabAtkins> unsure about name, don't like any of the suggestions :/

  khush: Have you seen use-cases where this is needed?
  fantasai: The case Ian pointed out is - when you jump, it's harder to
            follow what's next. If you jump less often it's better to
            navigate for the user
  <fantasai> One issue with masonry style layouts is that things can
             easily be visually out of order, e.g. if the current
             tracks are [100px, 99px] the next masonry item would be
             placed in the 2nd track, when the first would be more
             natural. A potentially solution to this is some user
             defined "threshold" to "place within the first track
             within Xpx of the smallest track"
  <fantasai> masonry-threshold: <length>
  <fantasai> -- iank

  TabAtkins: Use case is as described, when the mortar columns are
             fairly ragged, it's fine to track across columns
  TabAtkins: when there is some sort of order
  TabAtkins: but when differences are very small, looks very strange to
             skip over something
  TabAtkins: if your column height differences are minimal, it looks
             weird to have a gap
  TabAtkins: better to have gap at the end of the row instead
  TabAtkins: This is an ability that masonry libraries have; not sure
             how common, but definitely some

  <iank> One important note as well is the simple algorithm for this
         doesn't work - there is a staircase case where the simple
         algorithm doesn't work.
  iank: [restates irc comment]
  iank: where even if all the tracks are off by 1px it looks very
        strange to select the first one
  iank: So there needs to be a precise algorithm written that tests
        against the cases

  SebastianZ: So we're just talking about regarding the height of the
              already placed content?
  fantasai: Right
  TabAtkins: I think we can resolve to add this ability. Should discuss
             names, all the ones in the issue are more complex words
             than I like to use in properties
  <fantasai> masonry-slack?
  <astearns> we should look to see what the masonry libraries use
  TabAtkins: But I really like the masonry-slack fantasai just suggested
  proposed resolution: Accept some form of masonry slack property;
      exact algo TBD; exact name TBD

  RESOLVED: Accept some form of masonry slack property; exact algorithm
            TBD; exact name TBD

  <TabAtkins> Agree with astearns we should do a quick survey to see if
              libs have consistency in naming

Allow <auto-repeat> (i.e. repeat(auto-fill|auto-fit, ...)) to accept
    intrinsic sizes
  github: https://github.com/w3c/csswg-drafts/issues/9321

  fantasai: Ian suggested it might useful to be able to use auto-fill
            with the intrinsic sizing keywords, particularly in Masonry
  fantasai: Because, before you can stat placing items you need to know
            the size of the tracks
  fantasai: Currently the spec says that you resolve the sizes as if
            all items were in that track
  fantasai: So you can do an auto-repeat based on that size
  fantasai: Can give you odd results if you have wildly differing
            sizes, and all the thins happens to in one column
  fantasai: But mostly you'll want this where sizes are similar to even
  fantasai: Grid could maybe also benefit from this
  fantasai: There's cases where you want to have some number of items
            in your autoplaced grid, but not hardcode the size of the
            items into the track listing, you want the size to come
            from the items themselves
  fantasai: So doing something similar - take the size of the largest
            grid item - could work
  fantasai: So question is: is this something we're interested in
  fantasai: We can add various restrictions as necessary. Like, maybe
            only the intrinsic-auto-fill can be auto sized
  fantasai: So you can have one repeat, it can have one track in it,
            and it's the only intrinsic size in the axis
  fantasai: More possibilities gets increasingly confusing

  iank: I think this is one of the cases where it's potentially
        confusing for authors in Grid
  iank: But makes more sense in Masonry
  iank: I typed out an example in the issue
  iank: When you're determining the intrinsic size for your items, you
        need to give them some constraints in the opposite axis
  iank: Most noticeably, working out the intrinsic block size, you need
        some inline size
  iank: In Grid, since this is before placement, you don't know what
        tracks they'll end up in, what size those tracks are, so you
        have to give it *some* inline size
  iank: And this'll differ wildly from the item's actual inline size
  iank: So the intrinsic block size you're using for repetitions and
        what it'll actually look like can be very very different
  iank: This isn't a problem for Masonry, since the inline size between
        these steps is stable, it doesn't change. Only a problem for
        the Grid case
  iank: So you'll end up with items where repetitions have a bunch of
        free space where they shouldn't and we'll get bug reports about
        Grid looking bad

  oriol: Similar to what Ian is saying, I don't see a way to make this
         work in Grid
  oriol: Might make sense for Masonry but not seeing it for Grid
  Rossen: Suggestions?
  iank: The reason a separate display type might be useful is we make
        things work great for Masonry even if they don't work for Grid
  fantasai: If the track sizing in the other axis is all the same...
  fantasai: So like in Grid if the other axis is all auto because you
            haven't specified row heights
  fantasai: You're auto filling the columns - however many will fit -
            and the rows are auto height intrinsic grid tracks
  fantasai: So one thing we could do is handle this by saying if the
            track sizes in opposite axis are all the same size, then
            autofill with an intrinsic size will take that size and use
            it to calculate an intrinsic size for all items in the
            grid, and repeat that for all tracks
  fantasai: If there's more than one track size, like author is
            alternating 500px and auto row heights, then the repetition
            is just 1
  fantasai: Functionally disabling the auto repeat, but it's predictable
  iank: I don't think that works
  iank: If the columns are auto, you still might place something in a
        particular area that'll increase a particular column by a large
  iank: And the inline size you use for calculating the intrinsic block
        size is again very different
  fantasai: Elaborate?
  fantasai: Rows are auto-fill, columns are all auto
  iank: And you may place one item with a large minimum size in the
        first column, so all the column will end up different sizes
  iank: The inline size you use... you can't take that into account
        when determining intrinsic block.
  iank: So you'll end up with a bunch of free space
  Rossen: Think we should go back to issue

CSS Values
  scribe: fantasai

Simplification algorithm should possibly return single child for min/max
  github: https://github.com/w3c/csswg-drafts/issues/9559

  TabAtkins: Several years ago, we discussed simplifying calculation
  TabAtkins: we agreed to aggressively simplify, e.g. min() if same
             units simplifies out
  TabAtkins: as part of changes, I ended up removing the spec text
             about min() or max() with single argument
  TabAtkins: I'm not sure why I dropped that spec text, I suspect it
             was an accident
  TabAtkins: today all browsers do aggressively drop single-arg
  TabAtkins: e.g. min(5px) + 10px becomes 15px
  TabAtkins: Chrome recently also aligned on this behavior
  TabAtkins: so I suggest we resolve on browser behavior, that
             single-arg min/max functions can be dropped from calc tree
  TabAtkins: even if the unit cannot yet be resolved
  <dbaron> +1 to specifying what everyone does, seems like reasonable
  <dbaron> (I think sakhapov recently wrote some reasonably major
           changes to calc() simplification in Chrome, to align with
           the spec.)
  <fantasai> +1 from me

  RESOLVED: Restore text simplifying out single-arg min/max functions


  Rossen: astearns and I were discussing whether to add extra topic call
  Rossen: or just a general session, since we have 50+ issues agenda+
  <bkardell> sgtm to run a poll on the ml
  fantasai: should we schedule and then decide the topic? only a few
            weeks before holidays
  Rossen: we'll poll the WG

Received on Wednesday, 22 November 2023 23:20:33 UTC