W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

Re: [csswg-drafts] [css-values] Add url() alias that does not accept unquoted URLs (#541)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 27 Feb 2019 18:47:32 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-467982850-1551293251-sysbot+gh@w3.org>
The CSS Working Group just discussed `URL Stuff`, and agreed to the following:

* `RESOLVED: Add a new url function that accepts only <string>, name tbd`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: URL Stuff<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/541<br>
&lt;fantasai> leaverou: Right now ppl cannot ? in url()<br>
&lt;fantasai> leaverou: reason being 1, we didn't have string concatenation<br>
&lt;fantasai> leaverou: but even if we did, you cannot put any function inside url() because of its weird parsing rules<br>
&lt;TabAtkins> s/?/use var()/<br>
&lt;fantasai> leaverou: It has a lot of weird parsing, because of unquoted URLs<br>
&lt;AmeliaBR> Examples for Twitter poll: `content: NAME(var(--percentage)); background: url(NAME("/assets/img", var(--icon-name), ".svg"))`<br>
&lt;fantasai> leaverou: We were thinking we should have another url function that only accepts &lt;string><br>
&lt;leaverou> Right url(var(--foo)) doesn't work<br>
&lt;fantasai> TabAtkins: Right now if you write url(var()) it'll be invalid<br>
&lt;fantasai> TabAtkins: Interpreted as a URL<br>
&lt;bkardell_> +1<br>
&lt;TabAtkins> fetch("http://example.com")<br>
&lt;fantasai> chris: We need a function that does stuff, I propose calling it fetch()<br>
&lt;fantasai> emilio: It doesn't fetch anything though, only if it's loaded<br>
&lt;florian> uri()<br>
&lt;heycam> q+<br>
&lt;fantasai> AmeliaBR: It's also a very JSy name and not very familiar to designers<br>
&lt;fantasai> AmeliaBR: I would go with href()<br>
&lt;chris> href() is nice actually<br>
&lt;fantasai> astearns: fetch() should have all of fetch()'s semantics which it won't so let's stay away from that<br>
&lt;xfq> ack heycam<br>
&lt;fantasai> chris: iri()!<br>
&lt;florian> +1 to href()<br>
&lt;fantasai> TabAtkins: leave<br>
&lt;fantasai> heycam: It might be nice to have a url function that uses relative URL rules rather than string concatenation<br>
&lt;Rossen> uniform-resource-locator( )<br>
&lt;chris> web-address()<br>
&lt;fantasai> leaverou: I think it would be useful to have a base argument, but not a name like resolve-url(), shoudl be named something...<br>
&lt;fantasai> leaverou: change the base URL<br>
&lt;AmeliaBR> Would it work as a modifier? `url("base.png", relative("assets/images/")`?<br>
&lt;fantasai> heycam: Similar but slightly different use csae<br>
&lt;leaverou> s/but not a name like resolve-url(), shoudl be named something.../but it shouldn't be named after that feature, since there are many use cases where the default resolution is fine/<br>
&lt;fantasai> heycam: But if that did overlap, might indicate a name<br>
&lt;fantasai> myles__: Would such an addition make us not want to do this stringify concat thing also?<br>
&lt;fantasai> chris: no, you need that generally. Just makes designing this easier<br>
&lt;fantasai> leaverou: also consider SVG data URLs with parameters in the SVG<br>
&lt;Rossen> pointer()<br>
&lt;AmeliaBR> q?<br>
&lt;fantasai> fremy: I like address()<br>
&lt;leaverou> s/also consider SVG data URLs with parameters in the SVG/URL resolution is not the only reason you want concat in URLs, e.g. think of SVG data URLs with parameters in the SVG/<br>
&lt;fantasai> heycam: I don't like that it's synonymous with url()<br>
&lt;chris> not-broken-url()<br>
&lt;chris> url++()<br>
&lt;fantasai> astearns: We actually want something that is basically better-URL, exact same semantics except working for all strings<br>
&lt;fantasai> heycam: Are you expecting ppl to use it for non-string-interpolation cases?<br>
&lt;fantasai> [yeah]<br>
&lt;dbaron> either address() or location() is kinda synonymous with url()<br>
&lt;leaverou> url(var(--foo)) is not string interpolation :)<br>
&lt;Rossen> chris, and then we can make it really good by url#()<br>
&lt;fantasai> AmeliaBR: We also talked a few days ago about url() modifiers, I'm assuming we'll create modifiers on the better function?<br>
&lt;chris> amela, yes I expect so<br>
&lt;chris> we are very constrained in how we can evolve url()<br>
&lt;fantasai> AmeliaBR: Any existing support for url modifiers?<br>
&lt;fantasai> No<br>
&lt;fantasai> AmeliaBR: So if we do modifiers, we can do it in the new function<br>
&lt;fantasai> AmeliaBR: No progressive enhancement reason to add new features to a legacy function<br>
&lt;astearns> q?<br>
&lt;fantasai> TabAtkins: No reason not to either<br>
&lt;Rossen> the-url()<br>
&lt;fantasai> chris: Incentive to move to the new one<br>
&lt;chris> u()<br>
&lt;tantek> you could give it inexplicable new capabilities and call it uri()<br>
&lt;jensimmons_> u2()<br>
&lt;fantasai> florian: If we want ppl to use it, then it needs to be a short name like url()<br>
&lt;fantasai> florian: For familiar names we could re-use HTML attribute names like href() or src()<br>
&lt;Rossen> get()<br>
&lt;chris> u2(href, echo-params, looping-params, reverb-level)<br>
&lt;fantasai> dbaron: hypertext-reference?<br>
&lt;tantek> another survey!<br>
&lt;chris> src is nice and short<br>
&lt;fantasai> astearns: From my reading of IRC, ppl like href() and src(), didn't see any other contenders that aren't silly<br>
&lt;bkardell_> fetch potentially wasn't silly imo<br>
&lt;fantasai> dbaron: address() and location() seem OK too<br>
&lt;leaverou> I'd vote for href() over src() because src: src(...) looks a bit weird (or maybe it doesn't?)<br>
&lt;Rossen> clear-winner()<br>
&lt;bkardell_> agree with lea actually<br>
&lt;fantasai> TabAtkins: I suggest polling later<br>
&lt;bkardell_> href() > src()<br>
&lt;leaverou> fantasai: descriptor<br>
&lt;fantasai> RESOLVED: Add a new url function that accepts only &lt;string>, name tbd<br>
&lt;chris> right, we have a src descriptor, which takes a url() currently<br>
&lt;tantek> urls<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/541#issuecomment-467982850 using your GitHub account
Received on Wednesday, 27 February 2019 18:47:34 UTC

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