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