[whatwg] The src-N proposal

[James Graham]

On 19/11/13 01:55, Kornel Lesiński 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.

So the remaining objections I am aware of to atomic-source are:

* Something related to animations. I don't actually understand this, so 
it would be nice if someone who does would explain. Alternatively this 
might not actually be an issue.

* Verbosity. This proposal is clearly verbose, but it is also the one 
that authors seem to prefer, largely because it uses the underlying 
markup syntax in a natural way. It seems that people will likely deal 
with the verbosity by copy and paste, templates or libraries to provide 
a convenient shorthand. If the latter occurs we can look at 
standardising it later.

* More testing is needed. Specifically it seems that tests will be 
needed to use <source> elements (or <picture> elements?) where you can 
currently use <img> elements. This is a real concern of course, but 
seems lower on the priority of constituencies than authoring concerns, 
unless we think that poor interop will poison the feature. With an 
atomic proposal this seems much less likely, Hopefully implementations 
will be able to reuse the existing <img> code so that the actual amount 
of new *code* to test is less than you might think by looking at the 
extra API surface.