less.js: Less fails to parse valid Custom Property values (ex: @apply polyfill)

This code breaks:

paper-drawer-panel {
  --paper-drawer-panel-left-drawer: {
    background-color: red;
  };
}

The curly brackets in the property value break the parser.

I’d like LESS to support the @apply syntax, as used by Polymer. https://www.polymer-project.org/1.0/docs/devguide/styling.html#custom-css-mixins

Also tried:

paper-drawer-panel {
  @ruleset: {
    prop: value;
  };
  --paper-drawer-panel-left-drawer: %(~"%d", @ruleset);
}

It didn’t break the parser but delivered:

paper-drawer-panel {
  --paper-drawer-panel-left-drawer: ;
}

which is clearly not a desirable behavior.

About this issue

Original URL
State: closed
Created 9 years ago
Reactions: 2
Comments: 34 (23 by maintainers)

Commits related to this issue

Fixes #3147 #2715 (#3213) * Adds permissive parsing for at-rules and custom properties * Added error tests for permissive parsing * Change custom property value to quoted-like value * Allow interp... — committed to less/less.js by matthew-dean 6 years ago

Most upvoted comments

We have a spec for this; a polyfill exists; Chrome has implemented it; Polymer is already using it in a 1.0 release; and websites are already using Polymer.

I think it’s a perfectly reasonable expectation for Less to support the syntax at a bare minimum level.

Less already passes @apply, --foo: bar;, and var(--foo) through. The only thing missing is getting Less to pass through the { ... } in --foo: { property: value; } with the same basic processing given to other css blocks; instead of coming to a hard stop and throwing a parse error.

dantman on May 9, 2016

Just to revisit this, I think I unfortunately had a narrow view of the scope of the problem.

That is: yes, @apply is just a proposal, BUT REGARDLESS, this is not invalid CSS. Not anymore.

paper-drawer-panel {
  --paper-drawer-panel-left-drawer: {
    background-color: red;
  };
}

My mistake was thinking that @apply was proposing an extension to the Custom Property syntax, but it isn’t. The above IS a valid custom property value, and, as such, should be added to Less support. I wish I had taken the time to dig deeper into the spec. (Here: https://www.w3.org/TR/css-variables/#syntax.)

Less has a core goal to support valid CSS, and Custom Property syntax is implemented fully in every browser as of now. The spec is extremely permissive, and may require some big changes in the way property values are parsed. You can put almost anything into it. Just how crazy you can get with values and whether browsers will allow that, I’m not sure. But, the way I read the spec, mostly anything is valid if it’s well formed. Meaning, until you encounter a “top-level” semicolon token, you can go nuts, wrapping all sorts of stuff in curly braces or parentheses.

This means that JavaScript libraries like Polymer are increasingly likely to “hack” CSS to place declarative properties / values where they’re readable by JS, which was really not possible before this CSS feature.

So 👍 to implementing ASAP.

Sorry to those who tried to point out that this is valid custom property syntax.

matthew-dean on Oct 12, 2017

I think the full spec of CSS Variables should be supported by LESS. Would love for this to happen!

stramel on Aug 3, 2016