Extract CSS legacy name aliases defined in specs #1753
Conversation
This file contains 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
CSS specs sometimes define property names that are "legacy name aliases" of another property name. Reffy extracted the legacy property names (during post-processing) as they are defined in a `<dfn>` element but did not flag them in any way. The crawler now adds a `legacyAliasOf` key to the property in the CSS extract whose value is the name of the aliased property. Extraction is based on looking for links to the term "legacy name alias" (defined in CSS Cascade 4 and 5) and simple patterns around it. Either: 1. a dfn for a property followed by a reference to the aliased property; or 2. a table with two columns: dfns in the first column, references to the aliased properties in the second column. First case handles legacy definitions in `css-align-3`, `css-fonts-4`, and `css-ui-4`. Second case handles legacy definitions in `compat`. Legacy definitions in `css-text-3` and `css-text-4` are not extracted... and that is a good thing because they define `word-wrap` both as an actual property and as a legacy name alias of `overflow-wrap`, which seems wrong. Legacy definitions in `css-flexbox-1` are not extracted either... which also is a good thing given that `compat` handles them already! The `css-ui-4` spec also defines `-webkit-user-select` as an alias of `user-select`, but the spec does not use the "legacy name alias" mechanism, apparently on purpose: https://drafts.csswg.org/css-ui-4/#propdef--webkit-user-select That relationship will have to be added with a patch if we really want it. Fixes #538 (although note there will remain a few CSS properties in extracts that do not have a real "value") and w3c/webref#1427
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.
CSS specs sometimes define property names that are "legacy name aliases" of another property name. Reffy extracted the legacy property names (during post-processing) as they are defined in a
<dfn>element but did not flag them in any way.The crawler now adds a
legacyAliasOfkey to the property in the CSS extract whose value is the name of the aliased property.Extraction is based on looking for links to the term "legacy name alias" (defined in CSS Cascade 4 and 5) and simple patterns around it. Either:
First case handles legacy definitions in
css-align-3,css-fonts-4, andcss-ui-4. Second case handles legacy definitions incompat.Legacy definitions in
css-text-3andcss-text-4are not extracted... and that is a good thing because they defineword-wrapboth as an actual property and as a legacy name alias ofoverflow-wrap, which seems wrong.Legacy definitions in
css-flexbox-1are not extracted either... which also is a good thing given thatcompathandles them already!The
css-ui-4spec also defines-webkit-user-selectas an alias ofuser-select, but the spec does not use the "legacy name alias" mechanism, possibly on purpose. That relationship will have to be added with a patch if we really want it.Fixes #538 (although note there will remain a few CSS properties in extracts that do not have a real "value") and w3c/webref#1427