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