[whatwg] The src-N proposal

Mon Nov 18 18:21:53 PST 2013

On Mon, 18 Nov 2013 23:18:37 -0000, Bruno Racineux <bruno at hexanet.net>  
wrote:

> All I hear from implementors as a whole, is that: you don't want to go  
> the css imgset or image-set road, you won't use src-templates, and you  
> don't
> want any new macro. Seriously, what it left?

Indeed, the discussions are difficult, but hopefully we're making progress.

> For all it's worth, my outside take on both of srcset and src-N has  
> always been that it's not DRY enough, and more unnecessary bloat to  
> pages, due
> the long unnecessary repetition of img-path(s) for each img of similar
> size, repeating the same pattern over and over for image galleries, and
> lack of src-template (or regex pattern) approach to this problem.

I agree that none of current proposals is perfect and all have degree of  
repetition and verbosity.

However, the most terse syntaxes are starting to look like Perl. It's not  
always the best idea to squeeze every byte out of a syntax.

Even if none of existing proposals is perfect in terms of DRY, I think  
overall they're good enough to be useful. I'm not concerned about  
verbosity, because gzip is excellent at removing cost of any repetition,  
so on the wire the most verbose and the most terse syntax cost the same.  
In terms of memory footprint we're talking about few attributes or  
elements that take bytes/1-digit kilobytes... while displaying megabytes  
of high-DPI RGBA bitmaps.

We should be able to add URL templates or another DRYing method later  
(especially to <source> which can take additional attributes easily  
without complicating syntax), and such layering/decoupling may actually be  
a more elegant architecture.

> I would consider src-N more friendly, with perhaps a new '<base src in  
> the <head> dedicated to src-N(s) and, proceed to includes custom MQs in  
> the
> head at the same time (which is inline css in the <head> anyway), to a
> least reduce some of its verbosity...

As you know there has been proposal for Media Query Variables, so it seems  
quite probable that a similar thing can be added for other properties of  
responsive images as well.

One way to convince browser vendors that such syntax is needed is to let  
them ship the basic version with full URLs, and then you'll have proof  
that URL patterns emerge and authors complain about verbosity (or not :)

> Either way, it's quite pathetic to watch implementors argue over two half
> baked quite verbose solutions, from a distance, after nearly 3 years
> thinking of this... Even worse, suggesting to go ahead with something  
> incomplete,
> not knowing what the future completion will actually consist of.

The issues and ideas discussed here look a lot like discussions in RICG  
years ago, so hopefully we'll eventually come to the same conclusions as  
RICG did ;)

-- 
regards, Kornel