Add special cases for single-argument functions url() and calc()

[kitten]

We discovered that both url() and calc() are rather special as CSS functions.

• url() is special because it contains... well... urls with optional quotes. This means that no matter whether the user types quotes or not, it will only contain a single value, a url.
• calc() is special since it contains operators that don't occur in normal css, namely: /, - (normally a character that is part of a word like a class for example)...

[kof]

Regarding url(): we can remove that "optional" quotes mess and say that ISTF expects the quotes. This way it becomes just a string.

[kof]

Regarding calc(): the question is, do we need each argument separately? Do we need to be able to do any processing on it after ISTF?

[kitten]

@kof It's actually quite easy to resolve this on a tokenisation level. One constraint for parentheses is that they must follow a word, e.g. url(...) is WORD, PAREN, ..., PAREN

In between we can just say that for url and calc everything is a string, even if the quotes are missing. This will make parsing it really easy

I think for calc btw it makes sense to just treat it like a string and not parse everything out. We don't need the differentiation, and most users won't. We can wait for someone to request this :P

[kof]

It's actually quite easy to resolve this on a tokenisation level.

Exactly, so we don't have to deal with it in ISTF. We can just expect always a quoted string if it is a url.

    [FUNCTION_START, 'url'],
      [VALUE, '"http://www.example.org/image"']
    [FUNCTION_END],

In between we can just say that for url and calc everything is a string

Nope, there are potentially other types as well. https://developer.mozilla.org/de/docs/Web/CSS/url See the difference between URL and URI and argument can be both. I didn't find though what names could be used. Clear is CSS 2 is cooking something there. Similar to what is possible as a value in "content" property

[kof]

calc(), lets research if it may contain any value that may require vendor prefixing.

[kitten]

Good point! http://caniuse.com/#feat=calc

• calc() is only partially supported by Android browsers (nothing we can do there)
• there seems to have been some prefixing (https://gist.github.com/jonkemp/2280688) however caniuse shows that most older browsers either supported its normal syntax or nothing at all (no prefixes)

Edit: Seems to be confirmed by stylis, which is not prefixing it: https://codesandbox.io/s/0V6xOOMyN

[kof]

By prefixing I ment arguments prefixing. Function name prefixing can be handled now already, because it is a separate value.

[kof]

Another question: if we want to allow using js variables as arguments we also need to destructure them.

[kof]

See for e.g. attr() function: https://www.w3.org/TR/css3-values/#attr-notation . It's 2nd argument is fallback which is a CSS value, which might potentially need processing.

[kof]

Ideally, if we want to be able to handle 100% of situations, we need to fully destructure values.

[kof]

If we would destructure the css function call arguments, we would need markers for math operators. Interestingly, the spec links "+" and "-" operators to selector combinators page. I understand from that that we can reuse our combinators for math.

[kitten]

It's 2nd argument is fallback which is a CSS value, which might potentially need processing.

But we don't really have any specific parsing for them, right? We don't really have to care about what they are, since we are not the ones processing them in the browser. We're just the ones assembling a CSS blob.

Ideally, if we want to be able to handle 100% of situations, we need to fully destructure values.

That is possibly true.

Why don't we go for the minimum right now, and don't think about this until v2 of the spec. We'll see whether people will actually need it. Because I'm pretty sure we don't.

[kof]

But we don't really have any specific parsing for them, right? We don't really have to care about what they are, since we are not the ones processing them in the browser. We're just the ones assembling a CSS blob.

Well, I think performance of parsing no matter where, server or browser, is one of the major points of the format. Think of runtime parsing for dynamic stuff.

Why don't we go for the minimum right now, and don't think about this until v2 of the spec. We'll see whether people will actually need it. Because I'm pretty sure we don't.

Maybe, though you just discovered one bad thing I had - no additional quotes for the url() function argument. This would lead to a breaking change in the future. So we should still at least try to look into this I think. Maybe it is not that hard and we also can ask for some help from CSS spec maintainers.

[kitten]

@kof Yea, for now I'm adding an argument token for functions inside the tokenizer to make this work. But on the spec layer having VALUE and COMPOUND_VALUE inside them is a potential problem.

Not for url() though, because it's not a problem parsing that as a single VALUE containing the URL as a value. calc is the big problem here.

However, if we'd like to parse separate arguments we'd need to be aware of all functions and their potential data types and we'd need to add all data types as well. That's a really deep rabbit hole: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Types

[kof]

Yeah, lets see if we can get a more generic DSL without maintaining the list of types.

[evan-scott-zocdoc]

How about attr()? https://developer.mozilla.org/en-US/docs/Web/CSS/attr

[kitten]

@evan-scott-zocdoc that one’s fine and covered by the ISTF spec.

The tokeniser in the reference parser I’m working on already handles calc and url using special logic too.

Since we are now supporting strings and can just use values for the rest, this issue can be closed, @kof