On Mon, 18 Nov 2013 23:18:37 -0000, Bruno Racineux <br...@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
