Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS escaping breaks specific unicode-range values #2677

Closed
matthi4s opened this issue Nov 16, 2022 · 2 comments
Closed

CSS escaping breaks specific unicode-range values #2677

matthi4s opened this issue Nov 16, 2022 · 2 comments

Comments

@matthi4s
Copy link

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:

} else if c == 'e' || c == 'E' {
if len(text) >= 2 && text[1] >= '0' && text[1] <= '9' {
// Unit: "e2x"
escape = escapeBackslash
} else if len(text) >= 3 && text[1] == '-' && text[2] >= '0' && text[2] <= '9' {
// Unit: "e-2x"
escape = escapeBackslash
}
}

@evanw
Copy link
Owner

evanw commented Nov 17, 2022

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.

@evanw evanw closed this as completed in ecc9eeb Nov 17, 2022
@matthi4s
Copy link
Author

Thanks for the quick fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants