-
Notifications
You must be signed in to change notification settings - Fork 47.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use valid CSS selectors in useId format #32001
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Comparing: 3314162...39fccb5 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
Can/should we just make them fully alphanumeric?Saying “it’s guaranteed to be a valid CSS identifier” in the docs feels kinda random. Why only CSS? What if I want to put it in a shell command or HTML attribute or whatever? Is that guaranteed to be safe? In principle someone should still be using CSS.escape anyway because you should always escape at the place where you are building up the string but I get that people won’t do that. I think the letters WXYZ might currently be unused? And that still leaves underscore if people want to use that as their own delimiter. |
It's not so much about the escaping as it's not allowed characters. CSS.escape isn't sufficient neither. I'm not sure what alphanumeric characters we could that aren't high risk of collision unless they're a very long sequence. Especially since now this is a breaking change regardless and breaking it into a frequent collision seems worse than always breaking some edge case. |
Hmm. I guess the angle quotes are valid identifier chars in CSS but I don't think they are in most languages. Maybe safer to do a non-ASCII letter character like ɹ (used to write the pronunciation of "react" in IPA) or something. Then we could guarantee that it's unicode alphanumeric and reasonably unlikely to collide with other idents? |
#26839 has some more use cases. Specifically, |
It's not in ASCII 7. The downside of using a unicode one is that it cannot be represented at all in a latin-1 encoding which seems even riskier. |
Not sure why latin1 chars are less risky than unicode in general… did you have something specific in mind? |
I mean you're not supposed to send it to the server or anything but if you sent it to a different document (like an unknown language then you'd lose it in the conversion to latin-1). It's kind of arbitrary though since the only languages that matter are on the client - which also means |
For the
useId
algorithm we used colon:
before and after. #23360This avoids collisions in general by using an unusual characters. It also avoids collisions when concatenated with some other ID. Unfortunately,
:
is not a valid character inview-transition-name
.This PR swaps the format from:
To the unicode:
Which is valid CSS selectors. This also allows them being used for
querySelector()
which we didn't really find a legit use for but seems ok-ish.That way you can get a view-transition-name that you can manually reference. E.g. to generate styles: