Force add CSS functions/types that do not have a proper dfn #1903
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a function or type was found in a production rule that does not have a `<dfn>`, it was added to the list of "missing definitions". In practice, the only cases where that happens are: - When a spec extends a construct defined elsewhere, see #1647. In such cases, we'd want the extended type definition to appear in the extract. - For `<boolean-expr-group>`, see #1878. In such cases, we'd rather not add the type since the underlying spec needs fixing, but that can be caught automatically, see below. This code forces the creation of a function/type. This is breaking change because, up until now, we guaranteed that all entries would have an `href` and that will no longer be the case. Ideally, we'd restrict this logic to extensions, but production rules are processed as raw text, meaning we don't have the link information that would tell us that we're looking at an extension. That is not such a big deal though: it is easy to tell when an entry without an `href` extends another, and it seems fine to use patching to curate the data (only one occurrence today). CSS consolidation is updated to deal with extended functions and types. As opposed to extensions of properties where new values are added to the syntax, function/type extensions re-define the entire syntax.
dontcallmedom
approved these changes
Jul 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is meant to address #1647. Given that this produces a breaking change in individual CSS extracts (a couple of entries without
href), I propose not to merge this until we switch to consolidated CSS releases in Webref.When a function or type was found in a production rule that does not have a
<dfn>, it was added to the list of "missing definitions". This update forces the creation of a function/type. This is breaking change because, up until now, we guaranteed that all entries would have anhrefand that will no longer be the case.In practice, the only cases where that happens are:
<boolean-expr-group>, see Extraction of the CSS<boolean-expr[]>type #1878. In such cases, we'd rather not add the type since the underlying spec needs fixing.Ideally, we'd restrict the logic to 1., but production rules are processed as raw text, meaning we don't have the link information that would tell us that we're looking at an extension. That is not such a big deal though: it is easy to tell when an entry without an
hrefextends another, and it seems fine to use patching to curate the data for 2. (only one occurrence today).CSS consolidation is updated to deal with extended functions and types. As opposed to extensions of properties where new values are added to the syntax, function/type extensions re-define the entire syntax.