-
Notifications
You must be signed in to change notification settings - Fork 23
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
Support nested parentheses in url() functions #84
base: master
Are you sure you want to change the base?
Conversation
Although this isn't strictly speaking valid CSS, it's common for preprocessors and postprocessors to support function calls and similar constructs within `url()` delimiters, since they appear to be function calls themselves. Closes TrySound#34 Closes TrySound#46
It is breaking change, we should put it under the option |
IMO this isn't worth categorizing as a "breaking change"... the old behavior was so weird (creating a |
URL has different logic parsing according CSS spec (url token), nested functions are not allowed, https://www.w3.org/TR/css-syntax-3/#consume-url-token, so it is by design, some packages rely on this behavior, so we can't just change it without additional options |
Which packages rely on not being able to parse nested functions? |
css-loader in webpack, stylelint and more |
I am not against this change, I just say that it can lead to some unexpected problems |
I checked this change against the tests for stylelint, css-loader, and cssnano as well for good measure, and all of them passed (well, stylelint has a few failures against the current master, but this didn't produce any new failures). I really don't think this will cause any real problems in practice. |
I think it can break edge case - |
It still produces a totally reasonable parse there: {
type: 'function',
sourceIndex: 0,
value: 'url',
before: '',
nodes: [
{
type: 'word',
sourceIndex: 4,
sourceEndIndex: 14,
value: "url('foo')"
}
],
after: '',
sourceEndIndex: 15
} that should be handled more or less correctly by any of these tools, given that it's invalid CSS in the first place. In fact, it's a more reasonable parse than the old version: {
type: 'function',
sourceIndex: 0,
value: 'url',
before: '',
nodes: [
{
type: 'word',
sourceIndex: 4,
sourceEndIndex: 13,
value: "url('foo'"
}
],
after: '',
sourceEndIndex: 14
} |
Hm, old output is wrong too, because Regarding to css-loader, now we try to resolve |
I think there should be some flexibility to do something the user expects when dealing with text that's explicitly invalid according to the CSS specification. Remember that this package isn't just used to parse 100%-spec-compliant CSS, it's also used to implement CSS extensions. Sass for example does allow nested functions within |
Although this isn't strictly speaking valid CSS, it's common for
preprocessors and postprocessors to support function calls and similar
constructs within
url()
delimiters, since they appear to be functioncalls themselves.
Closes #34
Closes #46