Gracefully Handle Unknown At-Rules

[amiller-gh]

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.

[aeschli]

http://www.w3.org/TR/css-syntax-3/#at-rule has the syntax of atrules

[aeschli]

https://www.w3.org/TR/CSS21/syndata.html#parsing-errors

[octref]

@aeschli How can this co-exist with validation against wrong at-rules, such as @charse (typo, without the t)?

[octref]

It seems the original issue is for being able to use https://github.com/css-modules/postcss-icss-values

css-modules is not a part of W3C CSS spec (not even a proposal). It just adds a bunch of custom syntaxes to standard CSS. I don't think we should support it in css-language-features. If we do, we open doors to supporting the hundreds of postcss plugins that add John Doe's favorite new syntaxes to CSS.

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:

[amiller-gh]

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 😢

[octref]

@amiller-gh From https://www.w3.org/TR/css-syntax-3/#consume-an-at-rule it seems possible to update the grammar to highlight @custom-at-rule as keyword.

@aeschli What's your opinion? Adding a new config that toggles semantic checking for all at-rules?

[aeschli]

Yes, let's add a new validation setting css.lint.unknownAtRules. If set, there should be only single problem reported on the at-keyword.
At any case, the css parser should read over the rest of the rule. If the rule has a body the whole body should be ignored (we shouldn't make any assumptions that it contains declarations or other rules).

For improving the TextMate grammar we can file an issue against https://github.com/atom/language-css