[CSSWG] Minutes TPAC 2023-09-13 Part I: Anchor Positioning Breakout [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

  - For those looking for an overview, there is one issue, #9117
      (Anchor positioning proposal comparison), compiling the
      differences between the anchor positioning proposals. Most
      of the differences have individual github issues for discussion.

  - The breakout discussion centered on issue #9124, which discusses
      'auto' insets when self-alignment is not 'normal'.
  - There was agreement that "If only one inset in an axis is auto,
      and self-alignment in that axis is not normal, then auto
      computes to zero".
  - However there was not agreement on how to resolve the double auto
      case. One proposal was to resolve both auto values to zero when
      alignment is not normal, and the other was to align within the
      static positioning rectangle.
  - Several group members didn't like having a difference between
      single axis auto and double axis auto. The counter-argument is
      that this difference exists today.
  - Two implementors were willing to take the compat risk that resolving
      double-auto cases to zero would cause, however there also weren't
      strong use cases for the double-auto case.
  - Ultimately, a conclusion couldn't be reached with just the breakout
      participants and discussion will continue to try and reach a


Agenda: https://github.com/w3c/tpac2023-breakouts/issues/66

  Tab Atkins
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Mason Freed
  Ian Kilpatrick
  Una Kravets
  Vladimir Levin
  Romain Menke
  Eric Meyer
  Tim Nguyen
  Martin Robinson
  Noam Rosenthal
  Khushal Sagar
  Alan Stearns
  Nicole Sullivan
  Miriam Suzanne
  Bramus Van Damme

Scribe: ntim

Anchor Positioning Breakout

Anchor positioning proposal comparison
  github: https://github.com/w3c/csswg-drafts/issues/9117
  <astearns> updated list:

  TabAtkins: Listed out all the use cases, and what proposals can do
             them well, not well, etc.
  flackr: I don't see transitions between anchors, which none of the
          proposals cover, but is very common
  una: I see "transitions between fallbacks"
  dbaron: Look at the second list that astearns linked to
  <dbaron> Is there an item in that list for the sidenotes / doc
           comments use case?
  TabAtkins: You can animate between 2 distinct anchors, the problem is
             animating when what an anchor name refers to changes
  fantasai: Transition between two anchor names is in the table
  <nicole> https://docs.google.com/document/d/185yzaofuMP2p1KK00e2J0cmL8vAxOY3LF7NxhpjveRo/edit
  <nicole> This is the document of examples
  dbaron: "anchor reference changes" is a confusing term because it can
          mean either "a change to which anchor is referenced" or "the
          anchor that is referenced changes (e.g., moves)"... and we
          care about both

  TabAtkins: Does anyone see something obviously missing in the table?
  fantasai: The ability to style based on fallbacks
  <astearns> add https://github.com/w3c/csswg-drafts/issues/9332 to the
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/9332

  emeyer: Multiple anchors is something I'm interested in, there is no
  fantasai: Not in the issue, because Tab's proposal already covers it

  fantasai: Not sure if it's covered, but cascading behavior on the
            @try blocks is terrible
  <TabAtkins> (it's on the list of topics to discuss)

Better interaction of auto insets and self-alignment properties?
  github: https://github.com/w3c/csswg-drafts/issues/9124

  <fantasai> My positions:
  <fantasai> https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1679487628
  <fantasai> https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1678174879

  TabAtkins: Before the spec existed there is no interaction between
             the two, we would use the CSS 2.1 behavior.
  TabAtkins: The remaining tension is what to do in the double auto case
  TabAtkins: My preference is to have double autos resolve the same way,
             so they resolve to zeros when you have non-default
  TabAtkins: Main reason for this, there is one alignment keyword where
             this is necessary, the anchor-center keyword needs the
             space to be able to align.
  TabAtkins: The larger thing behind my reasoning, static pos as
             defined in CSS 2.1 is just a poor version of anchor
  TabAtkins: It wasn't great, but it did do the job
  TabAtkins: but we don't need this anymore, since we have anchor
  TabAtkins: We don't need to do this anymore, unless we are
             constrained by compat

  fantasai: It would be useful to focus on the case where anchor
            positioning is happening, because we probably have
            agreement on that one
  <fantasai> PROPOSED: If only one inset in an axis is auto, and
             self-alignment in that axis is not normal, then auto
             computes to zero
  astearns: Lets try to resolve on it
  TENTATIVELY RESOLVED: If only one inset in an axis is auto, and
                        self-alignment in that axis is not normal,
                        then auto computes to zero.

  fantasai: My proposal is in the double auto case if there is a
            default anchor, set the alignment rect to be the anchor's
            element's bounds.
  iank: There are a few cases where this breaks down:
  iank: Let's say my left is based on one anchor, and my right on
        another based on another.
  [the proposal would apply to anchor-default; if there are multiple
   anchors, that means 'inset' isn't 'auto' anyway]

  TabAtkins: Having the behavior being significantly different between
             the single and double auto cases is confusing
  fantasai: We already have two different modes in abspos: static
            positioning or not
  fantasai: all this is doing is saying, instead of anchoring to your
            hypothetical box in the staticpos case, you anchor to the
            explicit anchor from anchor-default
  fantasai: I think it's more consistent with how CSS already works
  TabAtkins: I don't want it to be based on whether there's a default
             anchor or not, I want it to be based on the alignment value
  fantasai: We already have these 2 modes for 'position: absolute'.
  fantasai: Alignment doesn't change what you layout relative to
  TabAtkins: I think it would be nice to have a consistent alignment
  TabAtkins: we no longer need the static positioning, it would be nice
             to have alignment use a single consistent model
  fantasai: You're proposing to change existing behavior on web pages
  fantasai: Just because you dislike staticpos, because inferior to
            anchorpos, doesn't mean we should use the opportunity of
            any non-default property value to switch us out of it
  TabAtkins: No I'm not
  TabAtkins: My argument is not that we should change based on some
             arbitrary property, for the single auto case, we turn the
             auto into 0
  TabAtkins: we should be consistent in the double auto case and
             resolve both to 0
  <TabAtkins> and since the staticpos behavior is subsumed by anchor
              pos, we don't actually lose anything by dropping it in
              this case, so we can have a better, more consistent
              behavior by having autos always become 0 when alignment
              is happening

  TabAtkins: re: changing existing behavior, no one implements
             alignment properties on abspos
  fantasai: They do impl alignment properties for the static pos of
            the abspos
  iank: Not really
  iank: it's implemented in grid / flexbox
  iank: but flexbox only implements in one axis
  iank: We're willing to take that compat risk and take that back to
        the group

  iank: The proposed behavior is super useful
  iank: Today if you need to center something in the containing block
  iank: There's about 2-3 ways people use, they are very clunky
  iank: you need to set multiple props
  iank: one way is setting insets to 0
  iank: the other way is using calc
  iank: They're all super clunky
  iank: being able to set place-content: center and get centered
        alignment is very neat
  fantasai: I'm not arguing that being able to use alignment props in
            abspos is bad. I specced it out, obviously I think we
            should have it
  fantasai: The hacks iank mentions are indeed all terrible and should
            be replaced with alignment
  fantasai: that doesn't mean that alignment should change the behavior
            of the auto-auto case away from static positioning
  fantasai: just means you set 'inset: 0' to switch to using the abspos
            containing block
  fantasai: I don't think this is hard or confusing

  miriam: 'inset: 0' isn't a lot to add, but I as an author have never
          found static positioning of abspos particularly useful
  miriam: I'm wondering what we gain by maintaining it
  miriam: What is the use case where I want to maintain it while adding
  fantasai: Two things about adding alignment to static pos
  fantasai: Static pos is like if you have an element in the document
            and then flip on abspos, it more or less "doesn't move".
  fantasai: If you apply alignment properties in block mode (for
            example) to perform alignment, now abspos will cause it
            to jump to somewhere else.
  fantasai: What I'm arguing for is, when you define an anchor, then
            static positioning becomes relative to the anchor bow
  fantasai: That gets you the ability to be centered inside another box
            very easily
  fantasai: I think for the non-anchor case, it's about consistency
            with the way static positioning works
  miriam: I understood you were proposing that when you switch to
          abspos, that would change your alignment, but in a different
  fantasai: If you want to be anchored to an element, I think it makes
            sense your automatic position moves to that element
  fantasai: I think alignment causing your containing block to change
            is confusing
  fantasai: Right now, alignment shifts you within the container to
            which you're sizing
  fantasai: anchor-default does move you; that's its intention
  fantasai: Why not have it do something as soon as it's set?

  TabAtkins: I think your argument is that current behavior is useful,
             and I want to argue with that
  TabAtkins: We know that flexbox rules aren't very useful; we watered
             them down on purpose
  TabAtkins: In the one case that isn't well implemented yet, the
             inline/block case, aligning goes into degenerate rectangles
  TabAtkins: It would do something, but usually the opposite of what
             you expect it to do
  TabAtkins: align: start would put you more end-ward and align: end
             would put you more start-word, in certain cases
  TabAtkins: I think we were okay with that confusion when we defined
             the behavior because we didn't have anything better
  TabAtkins: Now that we have better, we don't have to offer authors
             this confusing behavior
  fantasai: I think it's great to offer a better way to do this; I'm
            not convinced this is the way to do it

  iank: I don't think there's been strong use cases presented for the
        double-auto case
  iank: The behavior being proposed does solve developer pain quite well
  iank: It does something very useful for center, stretch, a bunch of
        other things
  iank: This is outside of anchor positioning

  TabAtkins: I'm not sure how to resolve this, Elika
  TabAtkins: My argument is that the default behavior wasn't useful,
             perhaps when it was defined, but not now

  xiaochengh: For center, resolving double-auto to zero seems more
  xiaochengh: The inset modified containing block isn't just used for
              alignment, but also for position fallback
  xiaochengh: The only containing block to test is the original
              containing block
  xiaochengh: For alignment, we could use a different containing block
              than for fallback, but I'd like to avoid that

  miriam: Already we have a behavior where apply insets changes your
          reference, you're no longer using the static position box
  miriam: To me, changing the alignment is exactly the same concept, so
          in my mind it aligns better with current behavior
  miriam: Alignment is an auto-inset sort of thing, so if one changes,
          why not the other?

  vmpstr: Is there a web compatibility risk with this resolution?
  TabAtkins: For some layout modes, we do implement the double-auto case
             honoring alignment but not resolving auto to zero.
  TabAtkins: We're willing to take the compat risk
  iank: We're also willing to take the risk
  iank: We don't think there will be much

  astearns: Is there anyone who wants to show solidarity for Elika's
  emilio: Elika's position is safest
  iank: If we show it's web compatible, would that change your mind?
  emilio: I don't feel too strongly about preserving the current
  fantasai: Part of my point is you can get the behavior Tab and Ian
            want by setting inset to 0
  astearns: Having a property that does nothing until you set another
            property isn't good design
  <fantasai> astearns, that's a good argument for anchor-default having
             an effect without setting 'inset: anchor(..)'!
  <astearns> fantasai, I am OK with needing two properties when two
             things need to be connected
  <fantasai> astearns, they are connected already, why not have an
  emilio: That's already positioning, right?
  iank: I think our argument is that what we want is more useful and
        more what devs expect
  emilio: How is it more useful if the behavior Ian and Tab want can be
  emilio: The current behavior cannot
  TabAtkins: Current behavior can be achieved via anchor position
  iank: I think also, there hasn't been strong use cases for the
        existing behavior
  TabAtkins: Current staticpos behavior is in many cases un-intuitive
             and inconsistent between layout modes
  TabAtkins: Given it was mostly defined to give you certain powers
             that anchor positioning can give in better ways, we think
             authors are better served by having the old behavior be
  emilio: I still think Elika's position is safer but I wouldn't object
          to removing it if you can get away with it

  <fantasai> I'm not convinced you can do the same as staticpos for
             block and inline layout, at least not easily or without
             injecting additional things into the DOM
  noamr: If you want to achieve this non-useful behavior, you'd have to
         name everything
  TabAtkins: You'd have to write a name, but it could be a locally
             scoped name (according to another proposal)
  astearns: Does that meet your concern, Elika?
  fantasai: Replicating for grid and flexbox is not too hard
  fantasai: You have to assign a name to the container and then tell the
            item to anchor itself to that
  fantasai: For block and inline, though, you can't just slap a name on
            a containing block
  fantasai: You have to reference where the item would have been
  fantasai: You'd have to add an empty element to the DOM to act as a
  <TabAtkins> (not correct; you're always positioning relative to the
              prev/following element, and those can receive a name)

  astearns: We're out of time; not hearing consensus, but
  astearns: can we take a resolution?
  fantasai: I think I'd object unless everyone else in the WG disagrees
            with me.
  TabAtkins: Thank you all for coming!

  <fantasai> Tab, that doesn't work for "here's some text <span
             class=abspos></span> more text"
  <fantasai> We've also changed staticpos behavior before (for flexbox
             e.g.) and people were kinda annoyed about it when we made
             it less capable
  <fantasai> so at least some people do use it...
  <TabAtkins> Right, the non-aligned staticpos. Not proposing to change
              that, the compat is definitely bad.
  <TabAtkins> Oh and yes, for an abspos in raw text, indeed that would
              be the (sole?) case that would need *something* to get a
              wrapper to anchor to. (Either wrapping the text before/
              after, or an empty el where the abspos was.)

Received on Sunday, 8 October 2023 18:54:23 UTC