New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URL interpolation? #272

Closed
tigt opened this Issue Oct 2, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@tigt

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"
     pattern="\.gif"
     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.

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Oct 2, 2015

Member

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.

Member

yoavweiss commented Oct 2, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tigt

tigt 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!

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!

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Oct 2, 2015

Member

Closing.

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>

Member

yoavweiss commented Oct 2, 2015

Closing.

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