SyntaxError when selectors use special characters

[just-boris]

CSS selectors may include special characters and they will remain valid selectors

document.querySelector(":not(#\\9)") // this works

However nwsapi fails while trying to parse the same selector

NW.Dom.match(":not(#\\9)"); // Fails with SyntaxError: \8 and \9 are not allowed in strict mode.

Live codesandbox to reproduce: https://codesandbox.io/s/nwsapi-syntax-error-r6wqfd

[just-boris]

Usage scenario for additional context.

There is a technique to boost selector specificity without accidentally affecting more nodes: https://github.com/MadLittleMods/postcss-increase-specificity. It generates additional :not(#\\9) which do the job well, but sadly, this technique causes issues with testing in JSDOM (which uses NWSAPI internally)

[dperini]

@just-boris I think there is some misunderstanding here ... The error you indicated, "octal literals are not allowed in strict mode" is not an "nwsapi" error. Most probably the error is thrown by the browser which implemented this limitation, probably a W3C recommendation.

A simple Google search revealed to be a known limitation, see the problem described here: https://stackoverflow.com/questions/23609042/

They also suggest to use Octal format written as "#\0oXX" to bypass the validation error if this is your case. I hope I did understand your point correctly.

I will investigate further if there are inconsistencies with browsers behavior.

[just-boris]

The error happens when I am calling NW.Dom.match function, which comes from this package

In fact, the error comes from generated code on this line: https://github.com/dperini/nwsapi/blob/d8ac96549d5574f5a7f8eb479cd76be5a33b3925/src/nwsapi.js#L760

I am guessing, some additional escaping needed when generating the code

[Talor-A]

this selector appears to reproduce the same issue with the same root cause (the Function constructor linked above):

[data-anything="true"]:has(div)

this is the minimum i can distill my specific issue to

[vpanta]

Just wanted to raise a new case, when using something like lightningcss to generate using the cssModules setting, a hash can begin with a numeral making the CSS contain an escape character for said numeral. This ends up breaking in the same location mentioned here (the Function constructor) due to an "octal escape sequences are not allowed in strict mode", even though this is valid CSS.

I'd mistakenly filed a ticket for lightningcss, but they're doing the correct thing according to the CSS specification. So I agree with them that the real issue is how it's being managed by nwsapi.