Re: [csswg-drafts] [css-anchor-position] `position-anchor` should be defined as a longhand of `position` (#10321)

Let's set aside the "can we even shorthandify `position` at this point" question. Assume we can, for the moment - I still think we shouldn't put `position-anchor` into it.

Looking at the wider design space, what things we'll want to put into `position` - at minimum, `position-container` will be included, which also has a dashed-ident value. So fixpos and abspos will want to be able to take two dashed-idents, and we need to tell them apart somehow. We've only got a few examples of that in shorthands so far, and they're generally not very good. For example, `font` separates the font-size from the line-height by requiring font-size to come first and using a `/` before the line-height (even if the font-size is omitted), like `font: / 1.2em` to set just the line-height to 1.2em.

And stickypos wants to be able to use `position-container`, but doesn't have a reasonable use for `position-anchor`; we'll want consistent syntaxes between the two keywords, so presumably `position-container` would be the first dashed-ident, and we'll need `position-anchor` to come second and hold the slash or whatever. This would make it `position: fixed / --foo;`, which feels weirder, since `position-anchor` is the *more commonly useful* value than `position-container` for abspos/fixpos; `position: fixed --bar;` would be easier to write but not used as much, most likely.

Beyond this smaller issue, the larger suite of anchor-pos-related properties that could potentially be folded into `position` *also* only make sense for abspos/fixpos, again meaning that we have divergent grammars for the shorthand between abspos/fixpos and relpos/stickypos. *Most* of our shorthands are very simple, just "any of the longhands, in any order" as a syntax; the few exceptions we have that have *more specific* grammars are, generally speaking, hard to use. (There's a few exceptions, like `grid-template` which benefits from having a specific grammar that mixes things in a 2d relationship. But `font` is definitely an examplar of this problem, despite being *close* to just being "all the longhands".)

If we were designing `position` today, this wouldn't be an issue, because we would never have packaged abspos/fixpos with relpos/stickypos in the first place; the two sets are completely different features. But we're stuck with the legacy mistakes we've made, and I think they constrain us sufficiently that `position` shouldn't become a shorthand, at least for the anchor pos properties (and generally anything that applies only to abspos/fixpos).

-------

If the shorthanding compat issues are resolvable such that we *could* shorthandify `position`, I think it's reasonable to set `position-container` in it. That applies to abspos/fixpos *and* stickypos; its lack of applicability to relpos weighs comparatively less, imo, since relpos basically doesn't do *anything* anyway.

I could even see us introducing a *new* shorthand, designed just for abspos/fixpos, which sets *`position`* and the anchor-pos properties all together. Since it wouldn't be able to set the relpos/stickypos values, it woudln't have to worry about designing for it, so we could optimize the syntax for our use-case well. No idea what we would call it, tho. ^_^

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


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

Received on Tuesday, 25 June 2024 21:46:24 UTC