Re: [csswg-drafts] [css-align-3][css-position-3] Better interaction of auto insets and self-alignment properties? (#9124)

Wrt the double-`auto` case, there are two possible models:

- Option A: Currently-specced model, where we use an approximation of the “static position”, i.e. the position the abspos would have had if it were not absolutely positioned. In this model, the self-alignment properties influence the calculation of this “static position”.
- Option B: Proposed model, where any non-`normal` value for a self-alignment property obliterates the static position and lays out the box in its absolute-positioning containing block.

I don't think the CSSWG should resolve on this question without thoroughly understanding what each of them mean, and I don't think most people understood these options very well last time around. Relevant questions to explore are:

- Which has more utility for authors? (strictly speaking, A provides more functionality)
- Which is more understandable for authors?
- Which is more Web-compatible?
- Which easier to implement? (strictly speaking, B is simpler to implement)

**Wrt Web-compatibility:**
- Regardless of which option, the self-alignment properties will have an effect on non-auto-positioned abspos, where they currently have no effect. Hopefully authors aren't assigning these properties on absolutely positioned elements where implementing these would cause an undesired change in position.
- However, Option B (proposed behavior) _also_ changes cases where self-alignment properties _currently have an effect_, to have a _dramatically different_ effect: for flex and grid children, these properties currently affect the calculation of the static position, aligning the abspos within its parent. Under the proposal, however, they cause the abspos to position relative to its absolute-positioning containing block (which defaults to the ICB, not the parent).

To the extent that there are authors applying the self-alignment properties to children of flex or grid containers, where the flex or grid container is not the abspos containing block, Proposal B would be less Web-compatible. (It's unclear how common this case is, but iirc this behavior has been implemented for nearly a decade.)

The question of **utility** is largely this:
    
* Option A's main benefit is that you can align with regards to the static position, rather than only ever being start aligned. This same alignment can often be achieved using anchor positioning, but it requires setting up the relevant associations--and in the case of flow layout might be tricky or impossible.

* Option B's main benefit (afaict) is that if you want to center an absolutely positioned box in the absolute-positioning containing block, you no longer need to specify `inset: 0` in addition to `place-self: center`.

The question of **which is more understandable** is more complicated.

Having non-`normal` self-alignment break out of static positioning into the absolute-position containing block is a simple mental model.

But if we go back to what `position: absolute` by itself does: in the basic case of block or inline layout, it simply takes the element out of flow while leaving it in place. Currently that means its start-aligned, because everything is start-aligned in flow layout.

However if `justify-self` were implemented on blocks (which it should be), then authors might use `justify-self: center`, for example, to center a block while also providing margins. And then one might expect `position: absolute` to simply take it out of flow and leave it where it is. But if `justify-self: center` also disables the auto-positioning of abspos boxes, then adding `position: absolute` on such an element would both take it out of flow and center it in the abspos CB.

What's more expected? I'm not sure.

I think the CSSWG needs to think about the implications of each option, their utility, understandability, compatibility, and implementability, as well as considering their impact on CSS as a complete and integrated system

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1679487628 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 15 August 2023 19:44:31 UTC