[CSSWG] Minutes Anchor Positioning Breakout 2024-03-06 [css-anchor-position]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

+++Anchor Positioning Breakout+++

Fixing the animation problem (Issue #9598)

  - RESOLVED: Specify how styles that are conditionally dependent on
              layout get recomputed
  - RESOLVED: We will use the same sort of recomputed values for
              animations on anchor & anchor-size functions
  - RESOLVED: Accept that inset area changes the containing block
  - RESOLVED: Defer magic position animations until level 2

Can we clarify the `inset-area` syntax? It can be confusing to read
    and reason about (Issue #9862)

  - RESOLVED: Switching center-* keywords to span-* and all to span-all

Should size/layout containment also contain anchor names? (Issue #9349)

  - RESOLVED: Layout containment contains anchor names and size
              containment/paint containment do not


Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0004.html

  Tab Atkins
  Kevin Babbitt
  David Baron
  Stephen Chenney
  Keith Cirkel
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Chris Harrelson
  Anders Hartvoll Ruud
  Daniel Holbert
  Vladimir Levin
  Rune Lillesveen
  Khushal Sagar
  Alan Stearns
  Miriam Suzanne
  Sebastian Zartner

Chair: astearns

Scribe: keithamus

Anchor Positioning

Fixing the animation problem
  github: https://github.com/w3c/csswg-drafts/issues/9598

  TabAtkins: This is two distinct issues. I had an issue in the works
             to post, but didn't get it finished before the end of the
  TabAtkins: Presently, when we define container queries we implied how
             anything effected by the query worked but it's not
  TabAtkins: At the least chrome and webkit act similarly - so there's
             a throughline.
  TabAtkins: The existence of container queries is that computed values
             depend on layout
  TabAtkins: They must be computed. If a container query matches,
             changes the value, and the child has a transition on the
             property it needs to fire the transition
  TabAtkins: This is a computed value change. We can't know this until
             layout is already happening and has reached the container.
  TabAtkins: So we need to somehow figure out what the values were and
             patch them in.
  TabAtkins: This needs to be specified.
  TabAtkins: The rough description is what I just described; part way
             through layout when we interleave style and layout, and
             some point (which we'll specify) you realize the computed
             values need to change as the result of layout, we compute
             them, teat them as computed values - figure out
             transitions, inheritance, etc - then continue along as if
             they were always those values
  TabAtkins: this is also how we make anchoring work well
  TabAtkins: With the interleaving - does that sound reasonable to
             everyone? Chrome already does this. WebKit is similar but
             its not as scoped, they do more work but the end result is
             the same
  TabAtkins: I do not know what Firefox does. How it handles these.

  emilio: We do something very similar to WebKit here.
  TabAtkins: Implementation details determine exactly what happens, but
             does this description work?
  emilio: For webkit and gecko (may have some issues with transitions).
          Is sort of what you describe but it's not... you update the
          page layout, then recompute the styles for things that
          change. I'm not sure specifying it that way... like the
          interleaving blink has...
  emilio: If you do the extra work of if something changes then
          recompute it... I mean it generally sounds the right
          direction but I'd like to have a read of it before.
  TabAtkins: Yes I'm interested in if this is the right direction
  emilio: The difference between blink and webkit/gecko, AFAIK, style
          the page as if no container queries match, then do layout,
          then for things where container queries change, recompute
          style, then loop until you get to a stable state. Blink does
          something more subtle.

  futhark: In optimal cases we can pause layout and style the subtree,
           then continue. In several cases we do also need to do
           multiple passes. Layout depends on auto widths for eg we may
           not correctly detect this then have something more similar
           to gecko/webkit
  iank: Not exactly the same...
  iank: webkit/gecko are failing tests for behavioral difference. Some
        subtle differences, because they're revisiting prior states.
  astearns: Are tests written down based on spec or impl?
  iank: Written in spec.
  <TabAtkins> (there is no spec to be followed right now)

  astearns: Observability... is this a design decision for how we visit
            this? Recomputation being observable?
  chrishtr: Right. Not observable.
  chrishtr: Difference in blink and other two engines, it's a bit more
            optimized to avoid recomputing.
  iank: It's quite a bit faster for degenerate cases, and bugs in other
        engines. Theoretically could be fixed.
  chrishtr: Just a matter of quality of impl difference?
  emilio: Main difference is how to prevent cycles, things depending on
          siblings, ancestors, scrollbars, and so on
  iank: Not cyclical but previous states.

  astearns: Do we want a resolution? Computed values getting recomputed?
  PROPOSED RESOLUTION: Specify how styles that are conditionally
      dependent on layout get recomputed

  RESOLVED: Specify how styles that are conditionally dependent on
            layout get recomputed

  TabAtkins: Next up. Anchor and anchor size functions should be
             dependent on this concept.
  TabAtkins: Right now... the anchor function needs to turn into a
             length, we're not sure exactly when, but at some point it
             needs to turn into a length to position your element. You
             need to layout your anchor first then figure out what the
             length is. It should be transitionable.
  TabAtkins: If your anchor moves, you should be able to smoothly
             transition things. If the element you're referring to,
             e.g. changing anchor name values, you should smoothly
             transition to them.
  TabAtkins: So this is dependent on that too.
  TabAtkins: Larger bit on animation too, but the interleaving is
  emilio: Other than animation why do we need it to turn into a length?
  TabAtkins: It is for animation
  TabAtkins: For all other purposes it's fine

  emilio: It feels unfortunate that for all other cases it needs to do
          the extra work to compute
  emilio: Making it a computed value requires some amount of extra
          work. Unfortunate to require this. If we need it to be
          computed, then it makes sense, but ordering & dependencies
          get very tricky.
  TabAtkins: It's a more complex relationship than container queries.
             At the moment it means we don't do as-smart trimming for
             interleaving because the relationship is more complex.
  astearns: If we want these things to animate then we have to do
            something? These things animate discretely... we don't want
            that. Stuffing these changes into computed values, because
            that's how animations work, but I suppose we could say
            computed values that depend on layout use used values
            instead? That seems worse
  TabAtkins: I don't know if that seems worse. We're doing all this for
             the purpose of animations. If there's a simpler solution
             I'm happy to explore it.

  iank: Can't use used values... they're at the wrong phase for
        animations. To do that would be a big and complicated lift.
  astearns: We're kind of doing that, not used but recomputed which are
            closer to computed.
  iank: I don't think it's comparable.
  chrishtr: Second what iank says. emilio is right in difficulty of
            interleaving but the coherence and overall complexity is
            less than creating a new way of doing animations. This is
            just scoped to doing the interleaving, already had to be
            done for container queries, animations just fall out of
            that. Confirmed in prototype in blink. Clean solution.
  dbaron: The other scary thing is used values - we don't fully
          formally defined them vs earlier stages

  PROPOSED RESOLUTION: We will use the same sort of recomputed values
      for animations on anchor & anchor-size functions

  emilio: Do we need to define what they resolve to when the anchor is
          not there?
  TabAtkins: Already in the spec. It's the fallback value, which is
             zero if not specified.
  emilio: If your anchor has been laid out... I guess I'm wary of the
          outcomes that happen when you incrementally do this. An
          anchor function...
  emilio: I think container queries have the same issues but this can
          be sorted in the spec.
  emilio: When you have a style change and the anchor has been laid out
          before. That can be dealt with the same way as container
          queries. Probably fine.
  TabAtkins: Curious about exactly the case. We can discuss in the
             issue if you'd like
  astearns: Is there a need to specify how animation from anchor size
            from initial to actual recomputed value? Or does that fall
  TabAtkins: Initial value?
  astearns: If anchor isn't there it falls back to initial value.
            Something changes such that there is an anchor - is it
            possible to animate from that to a place in layout?
  TabAtkins: That behavior should fall out

  RESOLVED: We will use the same sort of recomputed values for
            animations on anchor & anchor-size functions

  TabAtkins: One final bit. Do we want to defer fancy animation stuff?
             emilio proposed that there are enough holes in the idea of
             position animation animating the rectangle idea I
             discussed in the f2f. We want to spend more time thinking
             about it? I'm okay with this based on above resolutions.
             Most cases will animate reasonably.
  <chrishtr> +1 to deferring to level 2
  TabAtkins: Edge cases should be safe to upgrade to via some kind of
             opt in.
  TabAtkins: I propose we kick animation idea to level 2 and work on it

  <fantasai> https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1836854109
  fantasai: I don't mind if we want to push animatability questions to
            level 2, but there was a number of follow up changes we
            were planning to make to inset area, alignment, and other
            things listed, I don't want to defer. As long as making
            those changes depend on animation, I'd like us to figure
            out animation
  TabAtkins: What might we change on inset area?
  fantasai: Containing block vs only causing auto values to compute
  TabAtkins: Already in the spec
  fantasai: When? That was in this issue?
  TabAtkins: It's been in for a while
  TabAtkins: Previously we had inset area work by adjusting auto values
             of inset properties, causing inset properties to match up.
             This would allow you to animate between inset areas, to
             some extent. The Apple proposal instead proposed the inset
             area changed the containing block, which I pushed back on
             as it was less animatable.
  TabAtkins: It's a better behavior to do the container block change
             and solve animations some other way. If we're deferring
             the animations stuff to level 2 it means we're potentially
             regressing inset area animations. I'm okay with that... if
             we set inset area back to how... resolves, we don't have a
             good path to a better future world.
  TabAtkins: I'm okay with it being less animatable now since we have
             an idea of how we're going to fix in the future.

  PROPOSED RESOLUTION: Accept that inset area changes the containing

  RESOLVED: Accept that inset area changes the containing block

  fantasai: That was my main concern, if we need more time and nothing
            is blocking then that's fine
  flackr: We won't be able to automatically enable these animations
  TabAtkins: Current proposal is a position-animation property to
             trigger the good behavior.
  TabAtkins: Cannot do it by default as it'd be incompatible with
             today's behavior
  flackr: Can change it so certain position types are animatable and
          others aren't?
  TabAtkins: Yes, this is an argument to defer it so it isn't just
             focused on anchor
  flackr: I just want to make sure the upgrade path isn't too difficult
  astearns: What will be animatable in level 1 vs 2?
  TabAtkins: Level 1- properties animating as normal to the extent of
             positioning insets, e.g. top and left. but if you switch
             from top to using bottom that won't smoothly interpolate.
  TabAtkins: Or if you change inset area, or self alignment from align
             self to justify self. Properties will animate it won;t be
             discrete, but it wont be smooth
  flackr: Usually authors will rely on transitions so there'd be no
          animation, change from auto to non auto would be discrete

  astearns: Any concerns with level 1?
  PROPOSED RESOLUTION: Defer magic position animations until level 2

  RESOLVED: Defer magic position animations until level 2

  astearns: Next Clarifying inset area syntax.

Can we clarify the `inset-area` syntax? It can be confusing to read
    and reason about
  github: https://github.com/w3c/csswg-drafts/issues/9862

  TabAtkins: Changing inset area syntax was discussed at f2f. People
             didn't like keywords. fantasai and I are weakly in favor
             of switching to span-left or span-start to indicate center
             and the other direction
  <fantasai> used to be `bottom / center left`
  <TabAtkins> `bottom center-left`
  TabAtkins: Right now if you wanted to express <select>, it fills the
             center and right
  <emilio> Select element behavior is actually different across
           platforms :')
  TabAtkins: Proposal is more like a background syntax, we use center-*
             properties to indicate 2 column or 2 row.l
  <TabAtkins> `bottom center` vs `bottom-center`
  <fantasai> maybe we need keywords for platform behaviors...
  TabAtkins: These were two extremely different areas being selected
  <TabAtkins> `bottom span-left`
  TabAtkins: So all center-* words are now span-*
  TabAtkins: bottom row, span from center to left columns.
  TabAtkins: in terms of number-pad in a 3x3 grid, cells 1 and 2

  TabAtkins: Unless anyone has a great opinion, I suggest we go with
             these as a different suggestion. Center being unclear,
             space or dash when saying out loud, and still is
             reasonably readable
  astearns: I agree this is an improvement
  dbaron: It seems less clear to me in the syntax that it's occupying
          two grid spaces.
  TabAtkins: It's spanning, so by definition it covers multiple spaces
  <TabAtkins> also, for example, `span-bottom span-left` covers 4 cells
              (4512 on numpad), and can't be written with compasses

  keithamus: At Github we have an implementation that uses compass
  <fantasai> https://github.com/w3c/csswg-drafts/issues/9862#issuecomment-1924919417
  fantasai: For background position we have very analogous syntax. We
            can't use compass directions because we have several
            different coordinate systems to worry about. Start-x,
            start-y, x and y, and block-start, inline-start, etc. The
            syntax... there is a lot of keywords.
  fantasai: This is a bunch of stuff that can be expressed in
            background position

  dbaron: What's the current syntax for spanning all 3?
  TabAtkins: 'all'
  TabAtkins: I'd be comfortable switching to span-all.
  astearns: Are you uncomfortable with this dbaron?
  <miriam> +1 span-all and span-(direction)
  dbaron: I'm okay, I just would prefer something clearer
  fantasai: Can keep the issue open, but I'd like to resolve on
            something so we can put a stake in the ground and publish a
  PROPOSED RESOLUTION: switching center-* keywords to span-* and all to

  RESOLVED: switching center-* keywords to span-* and all to span-all

Should size/layout containment also contain anchor names?
  github: https://github.com/w3c/csswg-drafts/issues/9349

  TabAtkins: Already in spec that style containment triggers
             containment of anchor names
  TabAtkins: Should other containments have this? Layout containment
             should for the same reason that it censors baselines. If
             it didn't you'd have to do layout in the subtree.
  TabAtkins: Defeats point of containment
  TabAtkins: Size containment should depend on children size and layout
             children etc. No guarantees are made about being able to
             defer work on layout containment
  TabAtkins: Size containment should not scope anchor names
  TabAtkins: We use size containment as a cycle breaker a lot.
  TabAtkins: Scoping it means you wouldn't be able to use container
             queries and anchor names on the same page.
  TabAtkins: Paint containment doesn't for the same reason

  emilio: I guess scoping would work both inside and outside right?
  TabAtkins: No
  emilio: So some kind of named scoping? I don't see how they change
          the constraints?
  emilio: If a name bleeds inside a layout contained thing...
  emilio: Does layout containment also scope counter names and so on?
  TabAtkins: No and it shouldn't. You don't need to do layout for
             counter names, just box tree.
  emilio: I was just confused about what point and where in the
          dependency tree

  miriam: Container queries add layout containment as well. Even if we
          restrict on layout containment we still have problems on how
          these two interact.
  miriam: You cant use anchoring across different containers
  futhark: You can't anchor something inside the size container
           outside, or vice versa
  TabAtkins: Regardless if we allowed names to leak out of layout
             containment it defeats the point of layout containment.
  TabAtkins: I think it's still a requirement that layout containment
             scopes the values
  miriam: Should we open a new issue to resolve how these two interact?
  astearns: A developer need to use these across boundaries trumps the
            need for good optimizations
  chrishtr: Resolve this then raise new issue?
  astearns: Yes resolve this issue and then work out how it interacts,
            revisit it if it turns out there's a need to anchor across

  astearns: Did futhark's remarks change your position TabAtkins?
  TabAtkins: Same. It only matters for style queries
  futhark: No it's also generated compute from... layout on outside
  TabAtkins: That's not in the spec right now as far as I can tell
  futhark: Yes, container type size also applies layout, size,
  futhark: This is not a problem specific to layout containment, also
           style containment...
  TabAtkins: Okay. Let's discuss that in the new issue
  PROPOSED RESOLUTION: Layout containment contains anchor names
  PROPOSED RESOLUTION: Layout containment contains anchor names and
      size containment/paint containment do not

  RESOLVED: Layout containment contains anchor names and size
            containment/paint containment do not

  TabAtkins: I have an anchor breakout session in the w3 breakout
             sessions to resolve the remaining issues. Provisional time
             slot for now.
  astearns: We can use that session for a wider audience hopefully
  fantasai: Those breakouts are for across w3. So if we want to resolve
            issues on our own, we should schedule on our own, but
            discuss stuff with the broader community in the breakout
  TabAtkins: I thought it was the same as TPAC Wednesday.
  astearns: We'll figure out some extra meeting times.

Received on Friday, 8 March 2024 16:39:05 UTC