Skip to content
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

Handle escaped EOF #128

Closed
facelessuser opened this issue Mar 17, 2019 · 0 comments
Closed

Handle escaped EOF #128

facelessuser opened this issue Mar 17, 2019 · 0 comments
Labels
S: confirmed Confirmed bug report or approved feature request. T: bug Bug.
Milestone

Comments

@facelessuser
Copy link
Owner

When parsing selectors, we don't really handle EOF like the spec says. Does this really matter? 🤷‍♂️

When dealing with CSS parsing, the parser is supposed to translate an escaped EOF to (U+FFFD). If the escaped EOF is in a string, it is supposed to be ignored.

So, according to spec, we are supposed to translate something like this div\ (when the escape is containing the EOF) to something like this div�. When dealing with a string, something like this "value\ would translate to "value".

As far as strings go, none of our selectors can ever be valid if the string contains an escaped EOF. This is because strings are either in [attr="value"] or something like :lang("en-*"). If the string contained an escape EOF, the selector would be incomplete and throw an error anyways, so we really don't care about this edge case.

As far as identifiers are concerned, we could run into the case of div\. If this occurs, we should handle it in a sane manner. And according to the spec, this would translate to (U+FFFD).

@facelessuser facelessuser added T: bug Bug. selectors S: confirmed Confirmed bug report or approved feature request. labels Mar 17, 2019
facelessuser added a commit that referenced this issue Mar 17, 2019
facelessuser added a commit that referenced this issue Mar 17, 2019
facelessuser added a commit that referenced this issue Mar 17, 2019
@facelessuser facelessuser added this to the 1.9.0 milestone Mar 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S: confirmed Confirmed bug report or approved feature request. T: bug Bug.
Projects
None yet
Development

No branches or pull requests

1 participant