-
Notifications
You must be signed in to change notification settings - Fork 642
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-syntax-3] url(
followed by comment(s)
#10125
Comments
In CSS2, |
The change from the special url token to a standard function token was resolved on several years ago, if and only if the first substantive thing inside the parentheses is a string. Otherwise it continues to be parsed as the special-case url-token. (This allows us to handle additional arguments, which otherwise would require even more special parsing to keep in the url token syntax.) Refreshing myself on the actual text, it appears that impls are in fact following the spec. After you see the This means that, per spec, seeing the So yeah, impls match the spec. And I think the spec needs to stay as it is; comments are otherwise ambiguous syntax. In theory I could add more scan-ahead to see if the comment is closed and (after potentially more ws and comments) then I hit a quote character, but it would impose a little more parsing cost on impls to support a syntax that wasn't previous allowed anyway. I no longer have an old impl around to test, but I suspect that |
So in conclusion: yes, the spec handles both of these cases and impls are correctly implementing that behavior, and I think that behavior is probably the best overall, given the legacy weirdnesses of |
In Chrome and FF (at least),
url(/**/"bg.jpg")
is invalid, andurl(/**/bg.jpg)
serializes asurl("/**/bg.jpg")
.I could not find something equivalent to the following note from CSS2 in CSS Syntax 3:
Based on this note, I would expect
url(/**/"bg.jpg")
to be valid. However, according to this note (which may be usefull to reproduce in CSS Syntax 3, imo), also from CSS2,/**/bg.jpg
must be seen as an invalid URL<ident>
:So I guess the first note does not apply anymore, ie. comment tokens can usually appear anywhere except in some places that you do not want to explicitly list.
And I cannot find any corresponding case on WPT.
If everything I said above is true and you think there is no need to clarify anything in CSS Syntax, this issue can be closed.
The text was updated successfully, but these errors were encountered: