[whatwg] The src-N proposal

Mon Nov 18 15:18:37 PST 2013

On 11/18/13 5:38 AM, "Marcos Caceres" <w3c at marcosc.com> wrote:

>Agree. It would be ideal to try to find a way forward here with src-n.
>
>Mozilla is not really interested in restarting this whole effort again
>with <imgset> or new CSS-in-the-head proposals (though, of course,
>orthogonal improvements to the preload scanner are quite interesting and
>probably quite beneficial, but let¹s keep that as separate!).

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?

Given the complex use cases and requirements of RespImg, IMO, these
mindsets are non-starters, and as you know do not give a very friendly
pre-loader or polyfill solution.

And you have yet to write specs for custom media-vars to avoid the MQs
repeats, which Tab say will take of itself later... though I'd love to
src-N specs with it, and a reassurance that everybody agreed on custom
media-vars being implemented, ahead of time. With the existing objections
to 'any' css in the head, there are little pre-assurances of that
happening.

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.

And some of you may think I am a 'rando' who arrives late to the party
with nothing new. But I have actually followed all blogs quite closely for
the past two years and read most of the specs prior to jumping in here.

With the prospect of either srcset or src-N shipping across the board. As a
developer, I had already nearly decided, that I was simply not going to
use either, and probably do a javascript approach with '<img postpone'
instead. Should other developers think the same way, that's a bad outlook.

Hence my attempt at a participation, for a solution I would deem worth
using as developer, (especially after contemplating your impasse here),
Making the argument for something more concise, using a comprehensive and
dedicated css subset.

The idea of treating this problem with one basic attribute or attr-N,
seems like a slightly limited or restrictive mindset to approach this
problem. This is shared with similar suggestions made by Markus
Lanthaler with a meta 'naming convention' with src-template(s).

I really don't understand why RespIMGs shall not be deemed requiring a
comprehensive css subset along the lines of @font-face with
src-template(s) to handle such a complex matter. As I suggested, it does
not have to require classes or presentational css in the <head>, just a
syntax 
that the preloader can parse quickly without a full css parser, and a very
small inline css.

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...

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.