compile font-family name with unicode is something wrong

[xinglie]

I have a css rule like this

textarea {
    font-family: 'helvetica neue','wenquanyi micro hei',\5FAE\8F6F\96C5\9ED1, \5B8B\4F53, sans-serif;
  }

if i save it to x.less and use less　to compile the file

less tell me

{ [Error: Unrecognised input]
  type: 'Parse',
  filename: 'input',
  index: 67,
  line: 2,
  callLine: NaN,
  callExtract: undefined,
  column: 56,
  extract: 
   [ 'textarea {',
     '    font-family: \'helvetica neue\',\'wenquanyi micro hei\',\\5FAE\\8F6F\\96C5\\9ED1, \\5B8B\\4F53, sans-serif;',
     '  }' ],
  message: 'Unrecognised input',
  stack: undefined }

is there i miss something?

[seven-phases-max]

It looks like it fails to parse \-escaped stuff after a value in quotes, i.e.:

foo: bar,   \5B8B\4F53; // ok
foo: 'bar', \5B8B\4F53; // error
foo: '' \5;             // error

A workaround is obviously to put unicode-symbols into quotes too (even if it's not required by the standard in this case), e.g.:

foo: 'bar', '\5B8B\4F53'; // ok

[xinglie]

very thanks for your response

my workflow is

less(x.less) => x.css
cssnano(x.css)=> x-min.css

if i add single quote like

foo: 'bar', '\5B8B\4F53'

less is ok, but if i pass

foo: 'bar', '\5B8B\4F53'

to cssnano, cssnano compress result is

foo: 'bar', \\5B8B\4F53

cssnano will remove quote and add a redundant slash

i tried only

foo: 'bar',   \5B8B\4F53

cssnano work ok

so , i have no idea how to solve this .   😂

[seven-phases-max]

If it's Less code only (i.e. you're not planning to pass it somewhere w/o compilation), the standard workaround for any kind of such problems is escaping (which is basically meant to make Less to pass an arbitrary code through w/o parsing). I.e.:

foo: 'bar', ~'\5B8B\4F5';

[matthew-dean]

By the way:

I looks like it fails to parse -escaped stuff after a value in quotes

In investigating, I found there actually is no support for escaping in keywords. It doesn't seem to have anything to do with quotes. There should be support though. I'm wondering if this should be tagged as a feature request? It could also stay a bug since escaping is valid CSS. In fiddling around, I was able to get this to pass just by allowing the backslash in keywords (plus alpha characters, - and _. Technically just adding backslash would allow incorrect escape sequences, but there's no requirement that Less be a CSS linter in this case.

[rjgotten]

This is definitely a bug.

CSS should allow escaped characters in anything that is classified as an identifier. That classification is much wider than the names of font families. It also includes things like the names used for counters; keyframes; etc.

[matthew-dean]

This is definitely a bug.

@rjgotten Not in the traditional sense. By saying it's a feature request, I don't mean it's not an obvious thing to include. I just mean that Less appears to have never had support for escaped characters in identifiers. Hence it can't be a bug, because nothing was ever there. It's just a missing feature. (To clarify: if Less HAD support for escaped characters in identifiers, but it was working incorrectly, you'd traditionally file that as a bug. Either way, it's important to do.)

[matthew-dean]

Btw, this parsing no longer occurs as of Less 3.7. Not because escaping is supported, per se, but because of permissive parsing. Meaning: unknown chars get interpreted as a permissive value until closing ;.