[whatwg] The src-N proposal
kornel at geekhood.net
Mon Nov 18 17:01:36 PST 2013
On Mon, 18 Nov 2013 16:47:08 -0000, James Graham <james at hoppipolla.co.uk>
> 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
It's *is* possible to have use N elements atomically.
I've specified a simplified <source> selection algorithm 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.
I'd love to hear feedback about simplified, atomic <source> from other
More information about the whatwg