URL interpolation? #272

tigt opened this Issue Oct 2, 2015 · 3 comments


None yet

2 participants

tigt commented Oct 2, 2015

This is a pretty odd idea, but with enough examples in the wild by now, it's starting to seem more plausible.

Basically, when people use <picture> and srcset to point at various image URLs, they very often do so in a regular way, which aids with debugging and developer mental overhead. So you see a lot of URLs constructed like filename.{width}.{file-format-suffix}.

When invoking the full, ugly power of <picture>, this results in a lot of repeated information. Ilya Grigorik's articles explaining the need for Client-Hints often present the horrifying visage of doing art-direction, resolution-switching, and format selection at the same time. And he's right, it's not pleasant.

Just as a crude sketch to get the ball rolling, what if we could do something like this:

<img src-pattern="filename.{sizes}.{types}"
     sizes="(min-width: 50em) 500px, 300px" 
     types="image/jpeg jpg, image/png png, image/webp webp" />

OpenSearchDescription.xml and schema.org both use URL templates with {}, so might as well use that. Another possibility would be reusing <input>'s pattern attribute, but regexes might be a bit much here.

The most obvious problem is when your sizes don't all map to discrete pixel values, which is basically every website with img {max-width: 100%}. While browsers could put in computed pixel values (and there is value in that, I think), that kind of defeats the point of a markup-only solution that works with a static file server. The solution is probably some sort of list of allowed values to clamp to.

Which is all well and good so far, but mostly just semantic sugar. The smallest but most attractive improvement would be something like bolting onto existing srcsets to allow for media types:

<img srcset="image.200.gif 200w, ... image.1000.gif 1000w"
     sizes="(min-width: 50em) 500px, 95vw"
     replacement-types="image/vnd.mozilla.apng .apng, image/webp .webp, video/x-mng .mng">

I dunno. Possibly not worth designing for. But pushing the limits of how granular the matrix of srcset × media × type can get by declaring every single URL in full seems like a waste.


We've already been down this path multiple times, and got back beaten each time :)

I don't think this resolves any real problem that server-side/build-time templating and gzip can't already resolve.

If one were to tackle URL templating (or templating in general) as part of HTML, it shouldn't be something that's respimg specific.

tigt commented Oct 2, 2015

Makes sense. An HTML-wide URL template mechanism does sound like a better idea. <form template> or something.

Thanks for the info!



Also, if one were to try and tackle HTML-wide URL templating, the WICG is probably the right place to try and get some traction for it </shameless-plug>

@yoavweiss yoavweiss closed this Oct 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment