URL parsing differs from other native functions

[tomrav]

We're using the value-parser in our Stylable project, and I'm encountering a use-case that feels inconsistent with the rest of the native functions.

By parsing whatever value resides inside a url as a single parameter (and not a complex AST), I am unable to iterate over the nested children (in my case, custom functions that will resolve to a url).

Example:
Source

.some-class {
    background: url(print(some-static-url));
}

Resolved target

"[
    {
        "type": "function",
        "sourceIndex": 0,
        "value": "url",
        "before": "",
        "nodes": [
            {
                "type": "word",
                "sourceIndex": 4,
                "value": "print(some-static-url"
            }
        ],
        "after": ""
    },
    {
        "type": "word",
        "sourceIndex": 26,
        "value": ")"
    }
]"

[TrySound]

It's historical decision. value-parser was introduced to simplify mostly parsing for cssnano. It was always a pain to parse urls, so I added parsing for url. Single parentheses was one of real world use cases. Now I don't want to change this behavior since a lot of modules rely on it. Usually I advise to use different name for custom urls since it has different semantics for parser. Similar postcss has special case for it.

[tomrav]

If we're to suggest making a PR, that would allow this feature to be configurable (special-case formatting for URL's), where you can opt-out from the current behavior - is this something you might consider?

[TrySound]

@ben-eb @ai need your advice, guys

[ai]

@tomrav here we have a problem. According CSS spec url() is not a function. It is a very special token. It can have nothing inside :(.

What is your current problem? Maybe there is a better way to solve it?

[tomrav]

It's correct that in CSS url does not accept special characters (especially parenthesis), and will break if passed such values. However, that is only relevant to the final CSS output.

In our case, we have functions and references that will be resolved during build-time. These come in the form of nested functions inside the URL function and at the end we'll make sure to resolve them to a valid CSS URL value.
We're doing the exact same thing with all other CSS native functions, and it works great.

It would be nice to be able to opt-out of the current behavior for URLs and receive it just like any other function node.

For the mean time, we'll wrap all values inside of a URL function with strings, and re-parse that string separately for a second AST to work with.