[whatwg] The src-N proposal

Tue Nov 19 21:24:21 PST 2013

On 11/19/13 12:12 PM, "Ian Hickson" <ian at hixie.ch> wrote:

>On Tue, 19 Nov 2013, Markus Ernst wrote:
>> 
>> I can't recall the reasons why Florian's proposal of combining
>><picture> 
>> and @srcset fell out of the discussion. To me it still looks like the
>> most useable draft so far.
>
>I responsed to proposals along those lines last year:
>
>   
>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.htm
>l
>
>Search for "multi-element" for the specific response to proposals that
>involve multiple elements.

There are other concerns against any non-centralized approaches like
<picture>.

If your sources and breakpoints are hard-coded in your articles (stored
DB), and you suddenly have to change your site's theme, or add a new image
at the platform level or a new resolution? What if one breakpoint is no
longer relevant? Or what if you change designs with a complete new
responsive approach? How does an inline syntax help me with that case?

You can be stuck. That forces you to regenerate all the img src(s) of
your articles with your new layout and new inline breakpoints.

If the HTML is generated by a WYSIWYG editor. How do you deal with it?
Have to write a new plugin at the platform level to replace the <img> or
<picture> element with the new variations on all your articles and pages?

Either that, or the author has to predetermine traditional css classes for
both MQs and img src list(s), and translate them along into a RespIMG
syntax while generating every page. But then what about the WYSIWYG
editor? 
That seems hardly workable together.

Which brings the questions for that particular context:

Is the solution supposed to be always generated on the fly? Or by a
WYSIWYG editor? And how does an author is supposed to make
changes across their whole content for lack of css approach?

Any author used to the flexibility of css shouldn't have the burden to
deal with hard-coded unalterable stuff like that. It's as bad as an inline
css-style to deal with. And could also result in broken links, or
unexpected results if the image sizes are changed along the way,
loosing sync with the previously embedded srcsets or MQs in each page or
article.

A centralized css-subset approach do not have such difficult problems.
Verbose aside, to me this all screams: RespIMGs has to be a CSS related
feature with centralization of custom MQs and srcset(s) at the <head>.