-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
Handling escape symbols #93
Comments
Thanks, I'll look into this as soon as possible. |
@nex3 I sat down to give this a look, but I'm going to need more context, some use cases, something real that I can write a test around. I can't look for |
This isn't really about matching specific use cases, it's about accurately parsing according to the CSS spec. |
I'd argue the opposite. We only want to build in features that present from use cases. That prevents bloat. Minimal Viable Product very much applies here.
That's really what we're interested in there. So we're going to need a comprehensive list of valid escapes before we can move forward. From that we can build tests. |
The point of a parser for a well-specified format is to parse all possible documents in that format, not the 80%-use-case subset of that format. Across a wide enough swath of code, all corners of the syntax are going to be touched eventually. If you're saying that
The uses of the "consume an escaped code point" algorithm describe how to verify this. They are: |
That's the second time you've tossed that out there. I wrote this package for a need that I had, and some folks picked it up to use. I OWE YOU ABSOLUTELY NOTHING Threatening me with "we'll go elsewhere" is meaningless - it hold absolutely no meaning and does not sway me in the slightest. Without a valid use case I won't be implementing this feature. |
I'm sorry, I didn't mean to level that as a threat. As an open-source maintainer, I understand how frustrating it can be for someone to say "well then I'll take my ball and go home", and I should have avoided doing that myself. The point I was trying to make was more that we've been trying to provide value back to this package, as I hope I've demonstrated from my work on pull requests. That work benefits you and all your users, and we'd like to continue doing it, but we have some inescapable requirements—one of which is that our tools at least have the intention of following the CSS spec. As you may imagine, the set of CSS files across all of Google is vast, and we very much want to avoid any unnecessary pitfalls for authors who (reasonably) expect any standard CSS to work. |
I recommend that you fork or choose another project. |
Hey, all! I looked into this, and the PostCSS Tokenizer splits a string like In my limited corner of web development, the most common use case that I’ve seen for escape characters are when they are used to produce Atomic CSS libraries. Take a look at the examples from https://acss.io/#pseudo-classes. In that section, the source for the We can validate this expectation @ https://rawgit.com/tabatkins/parse-css/master/example.html Here is the good news. This tool extends the parser (and tokenizer) directly from PostCSS. This means that fixing the issue in PostCSS also means fixing the issue here. We can continue the discussion and resolution in postcss/postcss#1349 |
Seems like we forget to add escape symbols support.
Here is an example:
fo\a o
should be parsed as a single token.Here is a good description of escape symbols in CSS.
Tell me if you need anything from PostCSS core for this issue.
How Do We Reproduce?
Here is an example:
fo\a o
should be parsed as a single token.Expected Behavior
Should be parsed as a single token.
Actual Behavior
Parses as multiple tokens.
The text was updated successfully, but these errors were encountered: