W3C home > Mailing lists > Public > public-respimg@w3.org > October 2013

src-n viewport-url alternatives

From: David Newton <david@davidnewton.ca>
Date: Fri, 18 Oct 2013 07:56:04 -0400
Message-Id: <D38E3C25-6867-4A93-A1F2-F94F69643665@davidnewton.ca>
To: "public-respimg@w3.org" <public-respimg@w3.org>
For me, and I suspect others, the viewport-url microsyntax is one of the more confusing parts the src-n proposal. It's clever, for sure, but it took me a long time to understand it (and I'm still not 100% convinced I do). I thought it would be a good idea to discuss what we're getting with viewport-url and if there are any better possible alternatives.

So, what does viewport-url get us?

1) viewport switching
2) the browser can use it to automatically calculate DPR switching stuff (1x, 1.5x, 2x, etc.)
3) the browser can use it to decide if a viewport change requires a new download, or if a larger, previously-cached image can be used

(1) and (2) can be solved with media queries that are already part of src-n, though admittedly a bit more verbosely and with a bit more math. Despite those obstacles, it's a syntax that's familiar to devs, and one I suspect they'll use more often than viewport-url. If they do, though, they lose the caching advantage of (3).

In order to properly figure out if a cached image can be used, the browser must know whether a newly requested source has the same content/art direction as a cached version, and if the newly requested source is bigger or smaller than a newly requested version. Yesterday on IRC I came up with a syntax (https://gist.github.com/nwtn/7032904) that groups art direction styles to provide this info to browsers, so that (3) is still possible when doing viewport- and DPR-switching using media queries.

I don't yet know if I think this is a good idea, but my gut tells me it's more readable and writeable for devs, despite its verbosity. What do you think? Or, do you have any other good viewport-url alternatives?

Received on Friday, 18 October 2013 11:56:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:10 UTC