[css-properties-values-api] Rule validity doesn't match implementations
emilio opened this issue · comments
Implementations and tests blatantly disagree with the spec even in simple cases.
https://drafts.css-houdini.org/css-properties-values-api-1/#the-syntax-descriptor says:
The syntax descriptor is required for the @property rule to be valid; if it’s missing, the @property rule is invalid.
https://drafts.css-houdini.org/css-properties-values-api-1/#inherits-descriptor:
The inherits descriptor is required for the @property rule to be valid; if it’s missing, the @property rule is invalid.
https://drafts.css-houdini.org/css-properties-values-api-1/#initial-value-descriptor:
If the value of the syntax descriptor is the universal syntax definition, then the initial-value descriptor is optional. If omitted, the initial value of the property is the guaranteed-invalid value.
Otherwise, if the value of the syntax descriptor is not the universal syntax definition, the following conditions must be met for the @property rule to be valid:
- The initial-value descriptor must be present.
- The initial-value descriptor’s value must parse successfully according to the grammar specified by the syntax definition.
- The initial-value must be computationally independent.
If the above conditions are not met, the @property rule is invalid.
Yet both Blink (and WebKit probably by copying whatever Blink implemented) disagree with it in trivial cases. E.g. this logs 0 per spec, but 1 in WebKit and Blink.
This is annoying because this affects a lot of interop 2023 tests. We have a implementation of this and as I was reviewing this to potentially enable it I found that all the tests are just broken.
Am I missing something? "rule is invalid" only has one meaning in my book, which is that the whole rule should be dropped, just like an @font-face and the
Unknown descriptors are invalid and ignored, but do not invalidate the @property rule.
Makes me think that the spec agrees with my interpretation on what "validity" means here.
I think this is ultimately a spec bug, as in w3c/csswg-drafts#1682 it was decided to be consistent for @counter-style and @font-face.
This was briefly discussed at some point. If I remember correctly, the behavior we intended was that "invalid" in most cases here means "does not lead to a property registration". But I can not find the discussion now. :(
Also noticed by @romainmenke in w3c/csswg-drafts#9175 because an "invalid" @property still makes a following @import invalid.
Basically, it seems that people do not want a rule to be removed because its block contents is "invalid", right?
I don't recall having that discussion either (but that doesn't mean it didn't occur - my memory is notoriously faulty). Happy to either fix the spec to match impls or leave it and let impls get fixed, tho. I don't think I care too much how it goes, but making the actual rule invalid in simple grammatical failures like this is the more common behavior, and is what is generally meant by "X is invalid" across our specs.
Per blame, this text does come directly from @andruud (a5cd596) and was early in their spec-writing career, so it was likely just some loose wording.
was early in their spec-writing career
Yeah, maybe I was just confused at the time.
"rule is invalid" only has one meaning in my book, which is that the whole rule should be dropped
OK, then let's change WPTs to reflect that and I'll adjust our implementation.
Hi people, I uploaded a patch to align Firefox's behavior with the spec and the WPTs are adjusted accordingly there. I also opened web-platform-tests/interop#575
It's possible that we also want to follow what @emilio mentioned and align the spec with @counter-style and @font-face, but I'm not sure what was the conclusion here.
One thing I forgot to mention is about the interpretation of invalid inherits values. It seems they should be dropped, so the descriptor would be missing and the full @property rule becomes invalid (similar to what the spec describes for the syntax descriptor). But the spec is not explicit about that and existing tests assume it would take value false.
align the spec with
@counter-styleand@font-face, but I'm not sure what was the conclusion here
It does not seem usefull to preserve the rule in the CSSOM if it is invalid and cannot become later valid, since its attributes are read-only, as I noted it in w3c/csswg-drafts#9417.
But if later people ask for updating these attributes via CSSOM, I think there would be a compat issue.
But the spec is not explicit about that and existing tests assume it would take value false.
And people seem to want true as the initial value (cf. #994), which would have to be defined in the descriptor definition table. Currently, it is n/a (see prose).
I think descriptors declarations with invalid value must be ignored would be better defined in CSS Syntax, and any explicit mention of this parsing rule in other specs should be removed.
FYI, I've filed web-platform-tests/interop#587 about the test changes affecting Interop 2023. We have no CI enforcement that Interop 2023 tests aren't changed, but we do review any changes. Filing test change proposals before the changes are made is appreciated.
As per the above, it was discussed on another interop issue. Let's change this since implementations should start matching the spec shortly.