W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] The src-N proposal

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 19 Nov 2013 01:55:59 -0000
To: WHATWG <whatwg@lists.whatwg.org>
Message-ID: <op.w6rwzlvlte2ec8@aimac.local>
On Tue, 19 Nov 2013 01:12:12 -0000, Tab Atkins Jr. <jackalmage@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
Received on Tuesday, 19 November 2013 01:56:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC