[css-values-5] Fix dfn of <input-position> and <output-value>
#12349
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
A `<dfn>` of type `type` should only enclose a basic data type (something between `<` and `>`). At least, that's been the case across specs until now. The spec was using the dfn to describe a more complex `value`. More likely, the spec was trying to combine the definition of the two types with the definition of the value pattern that uses them in one single dfn. This update changes the value pattern definition type to `value` and creates additional `type` dfns for the individual types so that they can be referenced from other constructs.
|
The current markup is only enclosing basic data types. It's doing two of them, but that's fine. The text content of the |
|
Ah, I was worried you might say that ;) I agree that this does not matter for referencing purpose. Extraction of grammar constructs is a bit more rigid for now (and, for example, cannot always rely on |
tidoust
added a commit
to w3c/reffy
that referenced
this pull request
Jul 21, 2025
The `css-values-5` spec uses new patterns that were not supported yet: - Definitions in headings, see #1890. Such definitions were correctly captured in the dfns extracts but CSS extraction missed them. - Definitions that define more than one type at once through `data-lt` attributes, as discussed in w3c/csswg-drafts#12349. More generally speaking, CSS extraction did not always take the `data-lt` attribute into account. - Definition of the `<boolean-expr[]>` notation, see #1878. The regular expression used to split production rules wasn't designed for spaces in the left-hand side. The update also simplifies the selectors used to find production rules in a document to make them more readable, and to avoid processing the production rules more than once, as discussed in #1878.
tidoust
added a commit
to w3c/reffy
that referenced
this pull request
Jul 21, 2025
The `css-values-5` spec uses new patterns that were not supported yet: - Definitions in headings, see #1890. Such definitions were correctly captured in the dfns extracts but CSS extraction missed them. - Definitions that define more than one type at once through `data-lt` attributes, as discussed in w3c/csswg-drafts#12349. More generally speaking, CSS extraction did not always take the `data-lt` attribute into account. - Definition of the `<boolean-expr[]>` notation, see #1878. The regular expression used to split production rules wasn't expecting spaces in the left-hand side. Note extraction drops `[ <test> ]` and ends up with `<boolean-expr>` as type name. That's not necessary ideal, but there's no good way to represent that type in the extracts. Consumers need dedicated logic to handle the notation. The update also simplifies the selectors used to find production rules in a document to make them more readable, and to avoid processing the production rules more than once, as discussed in #1878.
tidoust
added a commit
to w3c/reffy
that referenced
this pull request
Jul 21, 2025
…1891) The `css-values-5` spec uses new patterns that were not supported yet: - Definitions in headings, see #1890. Such definitions were correctly captured in the dfns extracts but CSS extraction missed them. - Definitions that define more than one type at once through `data-lt` attributes, as discussed in w3c/csswg-drafts#12349. More generally speaking, CSS extraction did not always take the `data-lt` attribute into account. - Definition of the `<boolean-expr[]>` notation, see #1878. The regular expression used to split production rules wasn't expecting spaces in the left-hand side. Note extraction drops `[ <test> ]` and ends up with `<boolean-expr>` as type name. That's not necessary ideal, but there's no good way to represent that type in the extracts. Consumers need dedicated logic to handle the notation. The update also simplifies the selectors used to find production rules in a document to make them more readable, and to avoid processing the production rules more than once, as discussed in #1878.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A
<dfn>of typetypeshould only enclose a basic data type (something between<and>). At least, that's been the case across specs until now. The spec was using the dfn to describe a more complexvalue. More likely, the spec was trying to combine the definition of the two types with the definition of the value pattern that uses them in one single dfn.This update changes the value pattern definition type to
valueand creates additionaltypedfns for the individual types so that they can be referenced from other constructs.