[whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)
yoav at yoav.ws
Sat Nov 16 15:15:19 PST 2013
On Sat, Nov 16, 2013 at 9:25 PM, Bruno Racineux <bruno at hexanet.net> wrote:
> On 11/15/13 9:48 PM, "matmarquis.com" <mat at matmarquis.com> wrote:
> >I易d say the likelihood of a project not using a content image directory a
> >step or two from root is roughly the same as the likelihood that I易m
> >hot-linking to images on someone else易s website𢶤hich is to say 昆very
> >slim.昌 The 昆real world with clouds昌 case is a lot more apt to land
> >somewhere between two exaggerations, with a more common representation of
> >usage being something like:
> There is no exaggeration, I write here based on knowledge, research, and
Claims of research and facts are usually more credible when linked to an
actual research and/or facts.
> I'd say you are either misunderstanding the broad based usage of RespImg
> or not well aware of current practices. There are no imgurl <base> element
> here, and RespImg is not limited to your 2-5 local theme or ui images.
> 'Very-slim' would be speaking of small sites which serve images locally
> for a theme and have a well designed short path structure which very few
> people practice or even care for.
> And by: /img/path/pic100.png, for content images, you realistically mean:
> I just showed you a medium range 'flickr' case which is an image gallery
> website serving thousand of widgets. The cases applies to Facebook album
> images and everything else in that category.
> With Wordpress accounting for 20% of all websites,
> here is your wordpress default average theme path:
> Sitepoint (wordpress based):
> Local theme:
> Here are two random ones from a Drupal site:
> With just the Drupal default 'path' being:
> Mashable Rack CDN:
> NYTimes CDN:
> Techcrunch CDN:
> The chances of a path as short as '/img/path/pic100.png' in bytes size is
> the one that's very slim I am afraid. In fact, I dare you to find me a
> platform that stores its uploaded images with an average path that short
> by design.
> >src-1="100% (30em) 50% (50em) calc(33% - 100px);
> > /img/path/pic100.png 100,
> > /img/path/pic200.png 200,
> > /img/path/pic400.png 400,
> > /img/path/pic800.png 800,
> > /img/path/pic1600.png 1600,
> > /img/path/pic3200.png 3200"
> >I don易t find this terribly difficult to parse, as an author.
> Even with a path that short this the way it reads as a real world source:
> <img src="/img/path/pic100.png" src-1="100% (30em) 50% (50em) calc(33% -
> 100px); /img/path/pic100.png 100, /img/path/pic200.png 200,
> /img/path/pic400.png 400, /img/path/pic800.png 800,/img/path/pic1600.png
> 1600, /img/path/pic3200.png 3200"
> You can barely tell how many src(s) there are, right away.
As far as I understand your proposal, the problem you're trying to tackle
is a problem of DRYing out the URLs that comprise the various images. This
problem is tangent to the responsive images problem and can be tackled
later on, after the actual use-cases  are handled. Therefore, I would
prefer to focus on solving actual use-cases now, see usage in the wild, and
find a way to optimize URL repetition (if this is indeed a problem that
can't be handled by the good old <base> tag) later on.
Regarding your actual proposal, URI templates  is a current IETF RFC,
which AFAIK, no browser vendor has expressed any interest in implementing.
I may be wrong, but I doubt they'd be interested in implementing a regex
More information about the whatwg