W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2016

Re: [csswg-drafts] [css-variables] Relative URL resolution in var() references

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Wed, 30 Nov 2016 18:28:21 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-263953764-1480530497-sysbot+gh@w3.org>
The spec is clear - it's parsed as a `<declaration-value>`, which is 
just any valid token (with a few restrictions). There's no further 
structure to parse them into, so you have to keep the parsed result 
around, raw and without any further meaning assigned to them (beyond 
the `var()` substitution defined by the spec).

One consequence of this, if you're following the Syntax spec, is that,
 yes, you can't have "half a function token" - the parsing algos never
 return function tokens, only function component values, which are 
whole functions that know what their arguments are.  You similarly 
can't have half a (), [], or {} block.

URL parsing is, unfortunately, fucked here.  `url("foo")` and 
`url('foo')` cause the `url(` part to parse as a function token, but 
anything else causes the whole shebang to parse as a url token, and 
the whole contents between the parens is a url.  As Fran├žois says, 
`url(var(--foo))` is identical in meaning to `url("var(--foo)")` as a 
result.  We need to add a new, non-stupid function for urls to make 
this work better, such as `image()`.


So, back to the issue.  Nothing's underspecified here.  The value in 
`a.css` isn't a URL, it's a `<string-token>`.  The value in `b.css` 
isn't a URL, it's a `<url-token>` (uninterpreted!).  (And, as Fran├žois
 notes, does *not* have the value you expect - it's not equivalent to 
`url("a.png")`.)  Only in `c.css` is the value finally in a context 
where it's given a meaning, and it finally becomes a URL, where it can
 be resolved into an absolute URL, and that's done relative to the 
location of `c.css`, like any other URL in the file would be.

I agree this isn't the friendliest behavior.  But it's the logical 
behavior of untyped custom properties, as they're meaningless by 
design.  The correct fix for this is to use a typed custom property, 
so we can actually parse the value in `b.css` and give it meaning.  
Let's finish up the Houdini custom properties stuff, so we can make 
sure we're doing things right and then produce a simple declarative 
version - that way you can write `@custom-property --b { type: 
"<url>"; }` and everything works as expected.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at 
using your GitHub account
Received on Wednesday, 30 November 2016 18:28:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:05 UTC