When declaring a @font-face with one or multiple unicode-range values, very specific ranges get escaped which breaks the value and the entire unicode-range declaration.
test.css
@font-face {
unicode-range: U+0e2e-0e2f;
}
build
esbuild test.css --outfile=output.css
output.css
@font-face {
unicode-range: U+0e2\65-0e2f;
}
The e was escaped to \65, which is invalid CSS.
This was tested on esbuild 0.15.14.
Playing around with this, it seems like this is triggered by the sequence [0-9]e[0-9]e-[0-9]. I've also looked around the source code and my guess is that this is caused by this part:
CSS values are parsed into tokens by following https://www.w3.org/TR/css-syntax-3/. It looks like esbuild is parsing U+0e2e-0e2f into an <ident-token> with a value U and a <dimension-token> with a value of +0e2 and a unit of e-0e2f. As far as I can tell, this is the correct way to parse this input.
The problem you describe is happening because esbuild is taking steps to prevent a dimension unit that looks like an exponent from being "absorbed" into the dimension value. But in this case this can't happen because there is already an e exponent indicator present in the dimension value, so the parser won't try to consume the unit as an exponent. I think perhaps the correct fix here could be to have esbuild avoid escaping the e if there's already an e present like this.
When declaring a
@font-face
with one or multipleunicode-range
values, very specific ranges get escaped which breaks the value and the entireunicode-range
declaration.test.css
build
output.css
The
e
was escaped to\65
, which is invalid CSS.This was tested on esbuild 0.15.14.
Playing around with this, it seems like this is triggered by the sequence
[0-9]e[0-9]e-[0-9]
. I've also looked around the source code and my guess is that this is caused by this part:esbuild/internal/css_printer/css_printer.go
Lines 632 to 640 in c9b24d8
The text was updated successfully, but these errors were encountered: