[css-properties-values-api] Rule validity doesn't match implementations about css-houdini-drafts HOT 9 CLOSED

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. :(

from css-houdini-drafts.

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?

from css-houdini-drafts.

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.

from css-houdini-drafts.

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.

from css-houdini-drafts.

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.

from css-houdini-drafts.

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.

from css-houdini-drafts.

align the spec with @counter-style and @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.

from css-houdini-drafts.

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.

from css-houdini-drafts.

As per the above, it was discussed on another interop issue. Let's change this since implementations should start matching the spec shortly.

from css-houdini-drafts.