Experimental: Language tag canonicalization #159
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
facelessuser
added
the
S: work-in-progress
facelessuser
force-pushed
the
lang-canonicalize
branch
2 times, most recently
from
adb96af
to
db36b41
Compare
facelessuser
force-pushed
the
lang-canonicalize
branch
from
cc131ff
to
225f3dd
Compare
This work may not be used depending on what is decided in the level 4 selector spec, but if it is potentially done, we should hopefully be ready. Tests are still needed to ensure we are doing things as expected. Also, I am not entirely certain how ranges are supposed to be handled vs tags, but I think I am handling them as expected.
Only include keys we actively care about.
Ignore in registry.py as while covered, the information is not helpful. Ignore coverage in Canonicalization as there are no real are no tests for this currently, and we simply want to make sure we are covering all the pre-canonicalization logic.
facelessuser
force-pushed
the
lang-canonicalize
branch
from
60b3e54
to
7ad7f64
Compare
github-actions
bot
added
C: css-matching
|
This still hasn't formally made it into the spec. It may never. We wanted to get the jump on this, but there seems to be very little interest from the CSS spec team to decide on what they want to do. We will continue to hold on this as it is still not clear if this is the direction they will take. |
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.
There is talk about potentially having the CSS level 4
:lang()pseudo-class canonicalizing tags and ranges to better help in situations such as::lang(yue, zh-yue, zh-HK). The idea is you could then just do something like::lang(yue). For best matches, it is recommended to canonicalize both the range used in the pseudo-class and the tag it is comparing. Canonicalization would also output in the extlang form.Generally
*are ignored in ranges except when at the start:*-yue. Things likeen-*-USresolve toen-US, though implicit matching between tags will still matchen-xxx-USwithen-US.Currently, in this pull, we have canonicalization implemented according to RFC5646, but there are still some questions:
Should we abandon canonicalization, like we are currently doing, when the tag is invalid? Or do we just canonicalize the valid parts and ignore the failing parts?
As mentioned above, ranges can use
*, so we strip out non-essential*s and them canonicalize the range. This seems like the only sane approach, but am I misunderstanding something?It is only suggested that we MAY order variants to improve matching. We decided to go ahead and do this. Should we though? We have also omitted any failures if the required prefixes for a given variant are not found in the tag. This is to help ensure that both the the tag variant order is the same as the range's variant order, as specified range may not explicitly define all required ranges and rely on implicit matching to grab those. This seems reasonable, but should we abort canonicalization if the prefixes are not found? It is not a MUST requirement in the spec, only a SHOULD.
Anyways, some things to think about. Technically we could merge this as is and simply disable the canonicalization and it should behave exactly how it did before. We could also enable this functionality under an experimental flag if we wanted. Right now, we are simply waiting to see what is decided for the official level 4 CSS spec.