[whatwg] The src-N proposal

[Tab Atkins Jr.]

On Mon, Nov 18, 2013 at 5:01 PM, Kornel Lesiński <kornel at geekhood.net> wrote:
> On Mon, 18 Nov 2013 16:47:08 -0000, James Graham <james at hoppipolla.co.uk>
> wrote:
>
>> On 18/11/13 16:36, matmarquis.com wrote:
>>>
>>> I recall that some of the more
>>> specific resistance was due to the complication involved in
>>> implementing and testing existing media elements, but I can’t claim
>>> to understand precisely what manner of browser-internal complications
>>> `source` elements brought to the table.
>>
>>
>> The fundamental issue is atomicity; setting one or N attributes is an
>> atomic operation from the point of view of script; creating N elements is
>> not. This creates complexity because the algorithm has to deal with the
>> possibility of DOM mutation changing the set of available sources before it
>> has selected the correct one. I believe there was a proposal that simplified
>> the semantics by ignoring mutations, but I hear it ran into problems with
>> animated images, which I haven't understood in detail.
>
>
> I agree that <source> as specified for <video> and initially for <picture>
> was a mess, but that doesn't have to be the case. The complexity was mainly
> caused by stateful algorithm exposed to JS, which is not necessary for
> <picture>.
>
>
> It's *is* possible to have use N elements atomically.
>
>
> I've specified a simplified <source> selection algorithm[1] that achieves
> this. It is atomic from JS perspective.
>
> Atomicity is achieved by always scheduling the selection algorithm to run on
> next tick (event loop spin) after mutation. This way JS can perform several
> mutations in a row without worrying about race conditions.
>
> The algorithm I've specified is also stateless and works correctly with
> incomplete data (e.g. if packet boundary happens to be inside <picture>).
>
> 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.

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.

~TJ