Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Gracefully Handle Unknown At-Rules #51
Comments
|
http://www.w3.org/TR/css-syntax-3/#at-rule has the syntax of atrules |
|
@aeschli How can this co-exist with validation against wrong at-rules, such as |
|
It seems the original issue is for being able to use https://github.com/css-modules/postcss-icss-values
The original issue is about syntax highlighting. @amiller-gh We don't use parser but a TextMate grammar to support syntax highlighting, see: https://code.visualstudio.com/docs/extensions/themes-snippets-colorizers TextMate grammars are static and cannot highlight incorrect at values, since each at value has its own syntax. IMO the current support is good enough:
|
|
Current implementation works well enough for single line at-rules (although the prelude highlighting could be a little more fallback-friendly), but it starts getting even little less ideal when you begin using block custom-at-rules:
It fails to highlight the prelude, and some of the contents of the block. As far as the CSS grammar parser spec is concerned, it doesn't look like it defines specific keyword identification for at-rules parsing, the CSSOM is what determines what is and isn't a valid at-rule. So I would expect that the grammar to have a nicer fallback for unknown keywords... Either way – its not the best user experience for those of us using (or writing!) pre-processors that define custom at-rules |
|
@amiller-gh From https://www.w3.org/TR/css-syntax-3/#consume-an-at-rule it seems possible to update the grammar to highlight @aeschli What's your opinion? Adding a new config that toggles semantic checking for all at-rules? |
|
Yes, let's add a new validation setting For improving the TextMate grammar we can file an issue against https://github.com/atom/language-css |
Handle syntax highlighting of custom at-rules for microsoft/vscode-css-languageservice#51
Currently, the parser just gives up when it encounters an at-rule it does not understand. This puts the parser into "recovery mode" and can cause some very wonky syntax highlighting until it successfully recovers.
It should be possible to build a generic unknown at-rule parser that will mark the error and gracefully handle any valid at-rule syntax if all other at-rule parsers fail.