Function variables are changed when using numbers and underscores together

[bradcornford]

When placing numbers before underscores in function variables, these seem to be changed to include a space character between the two.

Take the following less snippet:

@type: 5_large;

.icon-@{type} {
    background-image: ~"url(/img/icon/@{type}.svg)";
}

The output is as follows, notice the space between 5 and the underscore:

.icon-5 _large {
  background-image: url(../img/icon/5 _large.svg);
}

[seven-phases-max]

Confirmed.
A minimal example:

@type: 5_large;
foo {
    bar: @type; // -> 5 _large
}

[lukeapage]

I think it is a difficult one - if keywords began with numbers then we cannot read 5px as a dimension. I'm not a fan of trying to work out if a variable is

• a string (as in this case - the correct fix is @type: "5_large";
• a selector
• something meaningfull in css (e.g. dimension, keyword, expression and a million other things)

I think @type: 5_large; should give a syntax error - but we don't check we have whitespace after interpretting a node - and it would probably cause issues if we did - but I think we should do that.

What do you think @seven-phases-max

[seven-phases-max]

@lukeapage

I think it's #2485, i.e. just missing _ in the regexp. I.e. since 5foobar is parsed as a dimension (with foobar as unit) I guess it's OK to parse 5_foobar as a dimension too, so it's just missing _ in the re.

---

Though now I can see the same issue applies to values like 5-foo-bar (which technically could also be parsed as a single dimension value), but that's more difficult case since then it needs to distinguish between 5-foo-bar and 5-foo-6 thus requiring more complex regexp there (so I did nothing for it in the patch).

P.S. Doh! And then obviously the same applies to values like 5foo7bar (which also technically possible to be a single dimension with foo7bar as a unit but changes for that start to be even more disturbing requiring too many new tests).

[lukeapage]

I'm in favour of saying its not a bug and adding a check whitespace function to the parser so it throws an error (perhaps mentioning, should this be a string?)

[rjgotten]

You could always just have the parser accept only those strings that are defined as actual unit identifiers in the official CSS3 Values and Units Module, as literal dimensions.

Those are the only units that have sane defined behavior in CSS anyway. And if a user really, really wants a 'custom unit' ... well; there's the unit(scalar, unit) function to make that happen. Dimensions with custom units is really not something that the actual parser itself should have any concerns over.

Make this part of strictUnits if people need the fix and you're afraid of breaking back-compat.

[seven-phases-max]

I still can't see why 5whatever and 5_whatever should behave differently. Yes, I realize that formally both are more like of Anonymous type rather than of Dimension (not counting though that the CSS spec. probably never mentions that some new units they hypothetically invent may not start with _). But since Dimension can handle it just fine, why especially forbid it? (not counting those additional 5-foo-bar examples though).

[seven-phases-max]

(not counting though that the CSS spec. probably never mentions that some new units they hypothetically invent may not start with _ ).

Hmm, curiously they actually directly allow this (not counting there's no such units currently):
dimension-token is number-token->ident-token and ident-token may begin with _.

So purely nominally 5_large is valid CSS dimension value :)

[rjgotten]

Hmm, curiously they actually directly allow this

Not that curious, actually.

An ident-token is, iirc, also used for property declaration names. The leading underscore on property names was a browser hack for targeting old IE versions. Establishing it as valid syntax that browsers should process is a form of paving the cowpath. ;)

[seven-phases-max]

An ident-token is, iirc, also used for property declaration names.

Underscores in property, class, keyword etc. etc. names are expected since those are identifiers... Units (e.g. px or %) contrary are never mentioned in the spec. as kind of an ident token hence it was quite surprising to see this in the grammar.

[matthew-dean]

The spec is actually surprisingly permissive for the purpose of consistency. So yes, a unit can be pretty much any identifier, for the reason that the parsing does not change as units are added. I don't think it's so much about being permissive to IE. CSS gives specific instructions on how things are to be parsed, so I think they considered that in forming the grammar.

[seven-phases-max]

So just formally, despite of the original example, the following minimal example:

@type: 5_large;
foo {
    bar: @type; // -> now `5 _large` but should be `5_large`
}

is about to be fixed even if we know for sure there's no such unit... is it?

[SomMeri]

Fixed by #2485

[bradcornford]

Thanks for this! Seems to fix the issue!