- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Aug 2023 00:07:08 +0000
- To: public-css-archive@w3.org
> PROPOSED: If both inset values in an axis are auto, and the abspos is associated with an anchor box, its automatic position is relative to its anchor box, not its static position. I don't understand what you could be meaning by this. The only way I can read it is that you want the "alignment container" to be the anchor element's box, but that's almost certainly not useful. What did you actually mean? ------ > * 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) In reverse order: * we're implementing B anyway (by which I mean, anchor positioning; whether we auto-compute the insets to 0 doesn't impact this). So A does not represent an alternative, but rather an addition, and it needs to justify itself. * for the most part, applying alignment properties to the static position doesn't work today. In the cases where it does (flex and maybe grid?) it's simplified to the point where the staticpos rectangle is just the flex/grid container, and aligning the abspos in that space instead is identical. * The original 2.1 notion of static position was more or less reasonable - "where it would have laid out if it weren't abspos". It was just a point. This newer notion of "static position rectangle" is something we defined a few years ago, and is quite different. It's a relatively arbitrary rectangle, constrained heavily by back compat in how it can be defined, relative to the nearest container element. It's no longer "where it would have laid out", and it's not clear that it maps to anything that authors are aware or or need. At the time we defined this we didn't have a lot of better options, but now we do, with anchor positioning. * A staticpos rectangle is only more options in the strict sense that the rectangle so defined is distinct from the containing block. Whether it's a *useful* rectangle is a completely separate question, and the "utility" of it depends heavily on that. > 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 quite tricky. It only achieves this in a *very strange way* that I don't think is at all useful now that we have better options. The details are described in <https://drafts.csswg.org/css-position/#staticpos-rect>. Most notably: for blocks, the "rectangle" is zero-height, and spans the width of the staticpos containing block. So `align-self: start` puts you *below* the rectangle, while `align-self: end` puts you *above* it. Similarly, for an inline the "rectangle" is zero-width, and the height of the line box, so `justify-self: start` puts you *after* the rectangle (on the end side) while `justify-self: end` puts you *before* it (on the start side). Being *capable* of this sort of positioning is useful, sure. But achieving them via alignment into degenerate rectangles is counter-intuitive and confusing! Instead, relying on anchor positioning makes a lot more sense: declare which nearby element you're aligning to, and then just say which of your edges goes where. This is straightforward and meaningful, *and* substantially more powerful, since you can do more complex alignments than just what the alignment keywords offer. (For flexbox and grid, the "staticpos rectangle" does not, in any meaningful way, correspond to "where the element would be if it weren't abspos". So we don't even have that justification there. It's just a weird box we defined in the hope that we could get *some* sort of useful behavior out of alignment, but it's not based on satisfying any particular use-case.) > 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. No, the main benefit is that the alignment properties do something reasonable and understandable (and still reasonably useful), instead of aligning into either a degenerate rectangle in counter-intuitive ways, or an arbitrary rectangle that doesn't appear anywhere else in CSS and isn't particularly useful. ----- Ultimately, the issue is that abspos, as defined by CSS2, is at least two (possibly three) different layout modes rolled into one. The "double auto" case, that we call static positioning, is precisely and exactly a weak, fragile form of anchor positioning. At the time of writing CSS2 we didn't have many of the concepts necessary for anchor positioning to work well, and it was a useful and frankly necessary ability, so it's fine that it was defined that way. But it was *always* a weak, hacky way of laying things out, that only barely worked; if you strayed even a little bit from what it offered you were SOL. You and I tried to retrofit the alignment properties onto this model to get some more power out of it, and it *technically* worked, but it was still fragile and weak. Anchor positioning solves the entire use-case much, much more robustly, powerfully, and intuitively, so we just don't *need* to use the alignment properties for this anymore. Instead we can repurpose them to the much more straightforward and understandable purpose of "aligning inside the containing block", exactly like how they work in all the other layout modes. And for an abspos, the containing block is the abspos containing block. If you're not specifying anything more specific, the most useful default is to use the entire containing block, which is achieved by computing auto insets to 0. We can't get rid of the "static position" concept; that's got two or three decades of compat supporting it. But we don't need to make it *more complicated* when we can spend those complexity resources in more effective ways. That's what this resolution is about. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9124#issuecomment-1679782465 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 August 2023 00:07:11 UTC