Less fails to parse values from web platform tests:

According to: https://github.com/web-platform-tests/wpt/blob/master/css/css-variables/test_variable_legal_values.html

...Less should be able to parse a block like this for custom properties:

legal css variable values {
  --percentage: 25%;
  --number: 37;
  --length: 12em;
  --time: 75ms;
  --function: foo();
  --nested-function: foo(bar());
  --parentheses: ( );
  --braces: { };
  --brackets: [ ];
  --at-keyword-unknown: @foobar;
  --at-keyword-known: @media;
  --at-keyword-unknown-block: @foobar {};
  --at-keyword-known-block: @media {};
  --cdo-at-top-level: <!--;
  --cdc-at-top-level: -->;
  --semicolon-not-top-level: (;);
  --cdo-not-top-level: (<!--);
  --cdc-not-top-level: (-->);
}

However, as expected, Less fails with the at-keywords in custom properties (variable @foobar is undefined). Since custom property parsing is already permissive with logic for failing over (accepting almost anything until a closing outer semi-colon), it makes sense to allow "variable-like" values in custom properties to pass-through.

Thoughts?

Start with the web-platform-tests reference, css/css-variables/test_variable_legal_values.html, and compare its custom-property cases with Less's parsing behavior. Trace the custom-property handling for at-keyword values and verify that the block parses without an undefined-variable error while preserving the listed values.