Repository navigation
[css-anchor-position-1] Which writing-mode does position-try-tactics operate on? #12869
Description
https://drafts.csswg.org/css-anchor-position-1/#typedef-position-try-fallbacks-try-tactic isn't particularly clear about whether flip-block means "block axis in the box's writing mode", or in the containing blocks' writing-mode.
I think WebKit at least uses the box's writing-mode, but given position-area by default operates on the containing-block's WM, that might be more consistent?
Activity
jfkthame commentedon Sep 28, 2025
And if I may add a somewhat related question: is there any reason we don't have physical-axis tactics (
flip-x,flip-y) in addition to the logicalflip-inlineandflip-block? Given thatposition-areaaccepts either physical or logical values, it would seem natural forposition-try-tacticsto do the same.emilio commentedon Oct 8, 2025
Note that for the swapping of axes in properties like
leftforrightand so on, it might make sense to use the abspos' writing-mode which is what logical properties use...tabatkins commentedon Oct 13, 2025
Our usual rule for logical keywords (across several properties now) is that the unadorned logical word refers to the container's WM, and self-* refers to the element's own WM. Our few exceptions (which I can't recall off the top of my head) I think are just places where we figured that we'd never want to refer to a container, so using the plain logical keyword for the element's own WM was fine.
I suspect we want to lean on that, then - use the containing block's WM, and if we want the element's own directions, use self-*.
(Note that, in this case, I could see us also wanting the default anchor's WM, potentially, which would use a different set of prefixes, like
anchor-block. This would mesh well with usingblockandself-block.)tabatkins commentedon Oct 13, 2025
Oh, and @fantasai and I are both completely fine with adding
flip-x/yif desired. Just need a bit of grammar fiddling to make sure they can't be combined with the logicals.css-meeting-bot commentedon Oct 15, 2025
The CSS Working Group just discussed
[css-anchor-position-1] Which writing-mode does position-try-tactics operate on?, and agreed to the following:RESOLVED: use the containing block's writing mode, pending implementors finding it is too difficult to implementThe full IRC log of that discussion
<JoshT> emilio: not specced which element writing-mode property operates on<JoshT> ... for things like this, makes sense to use containing block
<JoshT> ... but for swapping of logical and physical properties, width, height, top for bottom, seems to be more useful if they operated on the element's writing mode
<JoshT> ... both are implementable
<JoshT> ... for containing blocks, may be more tricky because may be further apart in the DOM
<TabAtkins> q+
<JoshT> ... so that might be an argument for doing the element's writing mode
<astearns> ack TabAtkins
<JoshT> TabAtkins: fantasai said in the issue our usual rule is: logical directions tend to default to the container
<JoshT> ... if we refer to the element, we use a self- prefix
<JoshT> ... for that reason, I'd prefer the container element
<emilio> q+
<JoshT> ... but like emilio said, some refer to the container and we should match that
<JoshT> ... if you put flip-block in the position area and then give it flip-block and it didn't end up in the block area because the element had an orthogonal writing mode
<astearns> ack emilio
<futhark> q+
<JoshT> emilio: curious to hear from other implementers as well. nothing is impossible, but if you're computing style of abspos, you might not know it until until the ??? pass.
<JoshT> ... it is a bit odd. I don't think style computed values have dependencies on the containing block's writing mode
<JoshT> ... maybe from the inherited writing mode. but seems to be introiducing a weird dependency
<astearns> ack futhark
<JoshT> futhark: we know what the ??? is when we compute the style. but I wouldn't be surprised if we had invalidation bugs when ????
<TabAtkins> s/???/writing-mode/
<TabAtkins> s/????/it changes/
<JoshT> ... for the anchored element if the writing mode of the containing block changes
<JoshT> emilio: some might work because the containing block writing mode triggers layout
<JoshT> ... you compute the style of the anchored things
<JoshT> futhark: i don't think we've done anything actively to make that work
<JoshT> ... for position area, it does work because they have different keywords
<JoshT> ... I don't remember what we do for when an element is in a containing block
<JoshT> emilio: agree with TabAtkins that containing block is the most sensible
<JoshT> ... I wouldn't be too sad if we kept using the abspos writing mode
<JoshT> astearns: should we add something to the spec and then check implementability
<TabAtkins> I do think matching position-area makes *enough sense* that if it ended up being too problematic to do, we shoudl just drop the logicals and rely solely on flip-x/y
<JoshT> emilio: everything is implementable with enough effort
<JoshT> astearns: we can see if the effort is justified
<JoshT> PROPOSED: use the containing block's writing mode pending implementors finding it is too difficult to implement
<fantasai> +1
<JoshT> RESOLVED: use the containing block's writing mode, pending implementors finding it is too difficult to implement
css-meeting-bot commentedon Oct 15, 2025
The CSS Working Group just discussed
[css-anchor-position-1] Which writing-mode does position-try-tactics operate on?, and agreed to the following:RESOLVED: add flip-x and flip-yThe full IRC log of that discussion
<JoshT> TabAtkins: suggestion from Jonathan to introduce flip-x and flip-y with the physicals<JoshT> ... we just didn't expand out the full set to have physicals, but I have no problem adding them
<JoshT> astearns: any concerns?
<JoshT> fantasai: no concerns. TabAtkins mentioned shouldn't be combined with logical
<emilio> +1 fantasai, I think it's fine in this case
<JoshT> ... but each of these would be taken in order as transformations so the result would mean no conflict. i think it would be fine to allow it
<JoshT> TabAtkins: but if you do that, it results in nothing. we normally don't let people do that because we don't let people do nonsense like that
<JoshT> ... I don't think you would have a reason to mix them
<JoshT> fantasai: could you combine with flip-start
<JoshT> ... I think we should allow these combinations and allow people to write things nonsensical
<JoshT> emilio: and for the implementation, i don't think it will matter
<JoshT> fantasai: it will make the syntax easier
<JoshT> RESOLVED: add flip-x and flip-y
[css-anchor-position] Add flip-x/flip-y to position-try-fallback
15 remaining items
flip-block/inline/start relative to container writing-direction
flip-block/inline/start relative to container writing-direction
flip-block/inline/start relative to container writing-direction
Bug 1998481 [wpt PR 55863] - [anchor] Switch position-try-order to us…
Bug 1998811 [wpt PR 55927] - flip-block/inline/start relative to cont…
Bug 1998481 [wpt PR 55863] - [anchor] Switch position-try-order to us…
Bug 1998811 [wpt PR 55927] - flip-block/inline/start relative to cont…
Bug 1998481 [wpt PR 55863] - [anchor] Switch position-try-order to us…
Bug 1998811 [wpt PR 55927] - flip-block/inline/start relative to cont…
Bug 1998481 [wpt PR 55863] - [anchor] Switch position-try-order to us…
Bug 1998811 [wpt PR 55927] - flip-block/inline/start relative to cont…
Cherry-pick 335c624. rdar://163497870
[css-anchor-position-1] Interpret position-try-order logical axis usi…