[csswg-drafts] [css-anchor-position] could anchor()'s side argument be optional? (#10408)

kizu has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-position] could anchor()'s side argument be optional? ==
After thinking about https://github.com/w3c/csswg-drafts/issues/10318 (optional `anchor-size()` arguments) and https://github.com/w3c/csswg-drafts/issues/10317 (reorderable arguments of `anchor()`) for a bit, I wonder if we could make the `anchor()`'s [`<anchor-side>` argument](https://drafts.csswg.org/css-anchor-position-1/#typedef-anchor-side) optional as well?

In my experiments, one of the more common things I was doing was `inset: anchor(inside)`. Would be great to have a shortcut like `inset: anchor()` for cases like this, as well as allow `inset: anchor(--foo)` with the implied `inside` as well.

When comparing `inside` and `outside`, for any shorthand (`inset`, `inset-block`, `inset-inline`), only the `inside` makes sense, as `outside` results in a nonsensical values when applied to those. While separate single-side inset properties could use `outside` as the default, I do not think it is more useful than the `inside`, and is not worth the potential confusion and implementation complexity compared to just always using `inside`.

The only issue I can think of is related to the fallback value: while `anchor(--foo, 0px)` will make sense, I don't think it is ok to allow doing something like `anchor(,0px)` if we'd want to omit both the name and side?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10408 using your GitHub account


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

Received on Sunday, 9 June 2024 14:35:27 UTC