Re: [whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)

On Sat, Nov 16, 2013 at 9:25 PM, Bruno Racineux <bruno@hexanet.net> wrote:

>
>
> On 11/15/13 9:48 PM, "matmarquis.com" <mat@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
> facts.
>

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:
> /images/2013/11/15/my-seo-optimized-name-web-400x300.jpg
>
> 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:
> //s.ma.tt/blog-content/themes/twentythirteen/images/headers/circle.png
>
> Sitepoint (wordpress based):
> Local theme:
> //www.sitepoint.com/wp-content/themes/sitepoint/assets/svg/sitepoint.svg
> Content:
> //dab1nmslvvntp.cloudfront.net/wp-content/uploads/2013/11/azurefig1.png
> Cloud:
> //
> dab1nmslvvntp.cloudfront.net/wp-content/uploads/2013/09/jump-start-php_35
> 5.png
>
> Here are two random ones from a Drupal site:
>
> //
> www.eurocentres.com/sites/default/files/styles/ec_header_image/public/cou
> rse_ss_panorama.jpg?itok=czf1epUh
>
> //
> www.eurocentres.com/sites/default/files/styles/ec_teaser_image_side_wide/
> public/brochure.jpg?itok=-SndaYVk"
>
> With just the Drupal default 'path' being:
> "sites/all/mytemplate/files/category/etc"
>
> Mashable Rack CDN:
> //rack.3.mshcdn.com/media/ZgkyMDEzLzExLzE1LzhhL2JiMS5hN2I3Ny5qcGcKcAl0
> aHVtYgkxNzV4MTc1IwplCWpwZw/1303c958/d02/bb1.jpg
>
> NYTimes CDN:
> //i1.nyt.com/images/2013/11/16/us/SNAKES-1/SNAKES-1-hpMedium-v2.jpg
>
> Techcrunch CDN:
> //tctechcrunch2011.files.wordpress.com/2013/11/football-blank2.jpg
>
> 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.
>
>
> ><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"
> >alt="[">
> >
> >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 [1] 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 [2] 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
based equivalent.

[1] http://usecases.responsiveimages.org/
[2] http://tools.ietf.org/html/rfc6570

Received on Saturday, 16 November 2013 23:15:46 UTC