[csswg-drafts] [css-logical] Handling ambiguous physical/logical shorthands with var() (#9690)

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

== [css-logical] Handling ambiguous physical/logical shorthands with var() ==
A few shorthands can potentially expand to *either* physical longhands *or* logical longhands, depending on the content of the property. For example, `margin: 5px 10px;` expands to `margin-top: 5px; margin-bottom: 5px; margin-left: 10px; margin-right: 10px;`, but `margin: logical 5px 10px;` instead expands to `margin-block: 5px; margin-inline: 10px;`.

The fact that they expand to *one* set of longhands is, currently, important for the model, since we track precisely whether you've used a physical or logical longhand for each axis/side.

However, if you write `margin: var(--foo);`, you can't tell whether the property will expand into physical or logical longhands until computed-value time, but we need to know that at parse time. Because of the above point about why they need to expand to *either* physical or logical but not both, they can't do the normal var()-in-shorthand trick of expanding into a magic unserializable form that'll become real at computed-value time.

We either need to add some more magic to the "did you set this side using physical or logical" that allows for a magic unobservable var() value that will decide its origin later, or we need to switch the syntax for "I'm gonna expand into logical values" to outside the value space, such as with a bang-syntax.

I think we should try for the first option first, since this also applies to our attempt to put logical keywords into the `background-position` property. The syntax isn't ambiguous in that case (unlike with `margin`), so it would be awkward to have to write `background-position: start start !logical;`.

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


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

Received on Saturday, 9 December 2023 00:00:51 UTC