[css-anchor-position] position-area specified vs. computed value is weird

[emilio]

https://drafts.csswg.org/css-anchor-position/#position-area-computed mentions that the computed value is just basically a simplification on the specified value.

It seems this simplification can be applied at parse-time, which doesn't depend on any computed-value-time information. If so, what's the reason not to do that at parse time instead?

cc @fantasai @tabatkins

[fantasai]

By "parse time" do you mean the specified value?

The reason we simplify at computed value time here is so that the author can work with the syntax they're most comfortable with, even if they're e.g. manipulating style attributes.

[tuankiet65]

Computed value of position-area is discussed here: #11828.

There's no spec for specified value, so WebKit follows the specified value test, which only swaps horizontal/x/block and vertical/y/inline keyword. I'm not opposed to simplifying position-area at parse time, so that the specified and computed value is the same simplified value.

[emilio]

By "parse time" do you mean the specified value?

Yes, effectively.

The reason we simplify at computed value time here is so that the author can work with the syntax they're most comfortable with, even if they're e.g. manipulating style attributes.

It's IMHO really confusing to get totally different syntax for specified and computed values without any strong reason for it, so I'd rather provide the same serialization / simplification on both ends.

There's no spec for specified value, so WebKit follows the specified value test, which only swaps horizontal/x/block and vertical/y/inline keyword. I'm not opposed to simplifying position-area at parse time, so that the specified and computed value is the same simplified value.

Right, Firefox implemented the specified value rules, and I was reviewing a patch implementing the computed value ones, and it's just weird to not perform this simplification earlier, IMHO.

[jwatt]

In WPT there are separate position-area-parsing.html and position-area-computed.html tests.

On the off chance that it helps in this conversation, below is my pseudo-code-ish description of what we have to do to make those WPT tests pass. (The terms "physical", "logical", "self-logical", "inferred" and "self-inferred" refer to each of the five top-level groups in the grammar, in order.)

parsing test passes with:

if physical, logical or self-logical
  if either is span-all
    remove one span-all
  else
    make canonical order

if keywords same
  remove second keyword

computed test then passes with:

if logical or self-logical
  if have two keywords
    convert to inferred pair (may result in repeated keyword)
else if inferred or self-inferred
  if either is span-all
    remove one span-all, AND convert the other to logical

if keywords same
  remove second keyword

[tabatkins]

I don't have a strong opinion here. I'm weakly supportive of @fantasai's position - we usually don't mess with the specified value much besides trivial canonicalization, but do more aggressive regularization in the computed value. But I'm fine with anything, ultimately.