[whatwg] The src-N proposal

[Timothy Hatcher]

> On Nov 18, 2013, at 5:55 PM, Kornel Lesiński <kornel at geekhood.net> wrote:
> 
> On Tue, 19 Nov 2013 01:12:12 -0000, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
> 
>>> AFAIK it makes it as easy to implement and as safe to use as src-N.
>>> 
>>> Simon, who initially raised concerns about use of <source> in <picture>
>>> found that solution acceptable[2].
>>> 
>>> I'd love to hear feedback about simplified, atomic <source> from other
>>> vendors.
>> 
>> The cost there is that <picture><source> is now treated substantially
>> differently than <video><source>, despite sharing a name.
> 
> The substantial difference is that it lacks JS API exposing network/buffering state, but IHMO that's not a big loss, as those concepts are not as needed for pictures.
> 
> IMHO the important thing is that on the surface (syntactical level) they're the same - multiple <source> elements where the first one matches.
> 
>> Otherwise, though, I'm fine with this as well.  The only innovation
>> that src-N offers over <picture> is the variable-width images syntax,
>> and that can be baked into <source src> as well.
> 
> That was exactly my thought. Combination of src-N features with less contentious syntax would be ideal.
> 
> <source> can support number of attributes, so if there are objections to some features or parts of src-N syntax, it can be split into multiple attributes on <source> to be introduced gradually later/as needed (e.g. <source media>, <source sizes>, <source 3d-google-glass-hologram-set>, etc.) without risking explosive complexity of combined microsyntaxes.
> 
> -- 
> regards, Kornel

I agree. <picture> and <source> better match the spirit of HTML. Where multiple numbered attributes is just a kludge.

— Timothy Hatcher