- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 15 Oct 2025 15:13:53 +0000
- To: public-css-archive@w3.org
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 implement` <details><summary>The full IRC log of that discussion</summary> <JoshT> emilio: not specced which element writing-mode property operates on<br> <JoshT> ... for things like this, makes sense to use containing block<br> <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<br> <JoshT> ... both are implementable<br> <JoshT> ... for containing blocks, may be more tricky because may be further apart in the DOM<br> <TabAtkins> q+<br> <JoshT> ... so that might be an argument for doing the element's writing mode<br> <astearns> ack TabAtkins<br> <JoshT> TabAtkins: fantasai said in the issue our usual rule is: logical directions tend to default to the container<br> <JoshT> ... if we refer to the element, we use a self- prefix<br> <JoshT> ... for that reason, I'd prefer the container element<br> <emilio> q+<br> <JoshT> ... but like emilio said, some refer to the container and we should match that<br> <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<br> <astearns> ack emilio<br> <futhark> q+<br> <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.<br> <JoshT> ... it is a bit odd. I don't think style computed values have dependencies on the containing block's writing mode<br> <JoshT> ... maybe from the inherited writing mode. but seems to be introiducing a weird dependency<br> <astearns> ack futhark<br> <JoshT> futhark: we know what the ??? is when we compute the style. but I wouldn't be surprised if we had invalidation bugs when ????<br> <TabAtkins> s/???/writing-mode/<br> <TabAtkins> s/????/it changes/<br> <JoshT> ... for the anchored element if the writing mode of the containing block changes<br> <JoshT> emilio: some might work because the containing block writing mode triggers layout<br> <JoshT> ... you compute the style of the anchored things<br> <JoshT> futhark: i don't think we've done anything actively to make that work<br> <JoshT> ... for position area, it does work because they have different keywords<br> <JoshT> ... I don't remember what we do for when an element is in a containing block<br> <JoshT> emilio: agree with TabAtkins that containing block is the most sensible<br> <JoshT> ... I wouldn't be too sad if we kept using the abspos writing mode<br> <JoshT> astearns: should we add something to the spec and then check implementability<br> <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<br> <JoshT> emilio: everything is implementable with enough effort<br> <JoshT> astearns: we can see if the effort is justified<br> <JoshT> PROPOSED: use the containing block's writing mode pending implementors finding it is too difficult to implement<br> <fantasai> +1<br> <JoshT> RESOLVED: use the containing block's writing mode, pending implementors finding it is too difficult to implement<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12869#issuecomment-3406959070 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 October 2025 15:13:54 UTC