Open just-boris opened 1 year ago
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)
@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.
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
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
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
.
CSS selectors may include special characters and they will remain valid selectors
However
nwsapi
fails while trying to parse the same selectorLive codesandbox to reproduce: https://codesandbox.io/s/nwsapi-syntax-error-r6wqfd