Parser ignores strings at an unknown at-rule prelude (thus failing at `{` and `;` there)

[sylingd]

I used less to write some user styles for Stylish, it have some special syntaxs, for example, this extension support regexp("Regular expression"). So the following codes will work well on Stylish:

@-moz-document regexp("(\d{0,15})") {
	a {
		color: red;
	}
}

But it can not work with less.js:

The less.js says:

ParseError: Unrecognised input. Possibly missing opening '{' on line 1, column 32:

1 @-moz-document regexp("(\d{0,15})") {
2 	a {

Is there a way to ignore the characters between quotation marks? Or are there other ways to solve this problem?
Thank you

[rjgotten]

You can insert literal content using a string that is 'unquoted' via the ~ operator.
What might work for you is something like:

@-moz-document regexp(~'"(\d{0,15})"') {
  a {
    color : red;
  }
}

If that still messes with the parser, you may consider moving the expression contents into a variable first:

@regexp : ~'"(\d{0,15})"';
@-moz-document regexp(@regexp) {
  a {
    color : red;
  }
}

[seven-phases-max]

Apparently the problem is in "{}" part (i.e. @-moz-document regexp("{}") ... fails as well) - and that's a bug (we'd expect anything within quotes to be parsed fine).
Then yes, the workaround would be in moving it to a separate variable as in the second @rjgotten example. - Oh, no, it woud not - see below.

P.S. Recalling how custom at-rules are parsed, I guess the problem here is that the parser does not even triy to parse anything between @-moz-document and first { as something meaningful (i.e. quotes has no expected effect here at all), and this is sort of expected since the parser has absolutely no idea of what syntax this custom at-rule may have... Thus it may be quite tricky to fix.

For the same reason ("unknown grammar") the workaround with @regexp won't work simply because it won't mean a variable there (in general nothing after @unknown-at-rule and before the first { is considered to be a Less code).
I.e. this construction is essentially parsed as:

@-moz-document regexp("(\d {
    0,15})") {
        a {
            color: red;
        }
    }

And the only workarounds I can invent at quick glance in this case would be either a separate file injected with (inline) or something awful like:

@mzd: ~'-{} @-moz-document regexp("(\d{0,15})")';

@keyframes @mzd {
    a {
        color: red;
    }
}

or sort of.

[rjgotten]

@seven-phases-max
Crap; you're right. I forgot about the (by necessity) rather ignorant / non-existent parsing logic for at-rules.

In that case, I wonder if Less can do any better in the look-ahead code to match the opening brace of the at-rule's block. E.g. make some assumptions on sanity of the structure of the value(s) that follow the at-directive, and performing some rudimentary open/close-matching for brace/bracket/quote characters on them.

[seven-phases-max]

In that case, I wonder if Less can do any better in the look-ahead code to match the opening brace of the at-rule's block.

I think it can try to parse that at-rule-prelude thing as an array of tokens (at least of two types: "string" and "anything-else", parens pairs may probably be ignored) instead of just a single "whatever" token like it does now... That should do the trick, though it's hard to predict what other problems may arise when you dig into.

[matthew-dean]

@seven-phases-max (or anyone)
Hey, if you're looking at parsing and dealing with permissiveness, do you think you would have time to look at #2715 & #2986? I just added this comment.

[matthew-dean]

@rjgotten

In that case, I wonder if Less can do any better in the look-ahead code to match the opening brace of the at-rule's block. E.g. make some assumptions on sanity of the structure of the value(s) that follow the at-directive, and performing some rudimentary open/close-matching for brace/bracket/quote characters on them.

It sounds to me like the rules for at-rules and custom property syntax may be similar. That is, you can include almost anything for an unknown at-rule, but there are some pair-matching rules? It might make sense to see what the overlap is and normalize the parsing between them.

[rjgotten]

@matthew-dean

Yes; that's the conclusion I arrived at as well. ^_^
There's got to be some overlap of concerns there.

The Stylus extension (not to be confused with the Stylus language) (also used for applying userstyles, a fork of Stylish) recently added Less support, this bug however greatly limits its use - especially since the file workaround cannot be used.
It'd be awesome if a fix for this was to be developed soonish so we can make use of Less. :)

[tophf]

The spec says {-token, not {-character. The parser works by consuming/ignoring tokens. The parser should read and ignore tokens until it encounters {-token, in other words: ident-token regexp, (-token which starts a simple block i.e. it'll consume everything (even { or } and the doublequoted string inside) until the closing )-token. Only then it'll see {-token, and then it'll consume the {} block. Less seems to simply search for { character which is plain wrong.

[seven-phases-max]

The parser works by consuming/ignoring tokens.

Less parser does not. I.e. you are right about how it should be in a perfect world (above I wrote the same) but I'm afraid how Less parser works internally has nothing to do with CSS parsing specs.