- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 8 Oct 2023 14:53:47 -0400
- 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.
=========================================
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
resolution.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/tpac2023-breakouts/issues/66
Present:
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:
https://github.com/w3c/csswg-drafts/issues/9117#issuecomment-1698431865
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
list
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/9332
emeyer: Multiple anchors is something I'm interested in, there is no
issue
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
alignments
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
positioning
TabAtkins: It wasn't great, but it did do the job
TabAtkins: but we don't need this anymore, since we have anchor
positioning
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
model,
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
alignment?
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
way
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
useful
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
position?
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
behavior
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
effect
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
achieved
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
gone
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
placeholder
<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