10px10px incorrectly parsed as two tokens #12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
For example in
margin: 10px10px, the value is incorrectly parsed as two separate tokens, where the result should be a single token (and the declaration should be invalid).https://www.w3.org/TR/css-syntax-3/#consume-declaration
https://www.w3.org/TR/css-syntax-3/#consume-component-value
Hey @marijnh, do you have any suggestions for this? We're slowly migrating to use lezer parser for rendering property declarations in the Styles pane in DevTools (crrev.com/c/5046552) and this is causing a bug for us.
Could you explain the problem a bit better? It seems in the spec, units are simply identifiers. So I guess technically
px10pxcould be tokenized as a unit here. But I don't see how that helps.I concur, tokenizing px10px as a unit looks like a good solution. I now realize my original phrasing was a little ambiguous, I shouldn't have called it tokens. 10px10px is currently parsed as two NumberLiterals (each of which has a Unit child). Parsing as a single NumberLiteral with a Unit SGTM.
I'd still like to understand the motivation behind this issue. What problem are you having with the current behavior?
margin: 10px10pxis not a valid declaration, and per spec10px10pxisn't two number literals with unit. The current parsing behavior makes it impossible to determine the input isn't valid.Are you using parser output for some kind of linting? Or do you mean you want the highlighting to show there's something weird going on?
We're using the parser output to add decorations and UI controls to property values in DevTools (crrev.com/c/5046552).
Okay. But how, specifically, is the current parsing an issue with that?
We cannot tell from the AST that the input was an invalid property declaration. We cannot validate the property value because the token sequence doesn't accurately represent the input.
But does parsing this as a number with a weird unit help at all for that?
Yes, it allows us to determine that the property value's AST does not represent a valid , for example. Note that we can't outright parse this as a syntax error, since something like
--var: 10px10pxis a perfectly valid declaration.That makes sense. Attached patch implements this.
Thanks a lot!