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:01:36 -0000
To: whatwg@lists.whatwg.org, "James Graham" <james@hoppipolla.co.uk>
Message-ID: <op.w6rugyygte2ec8@aimac.local>
On Mon, 18 Nov 2013 16:47:08 -0000, James Graham <james@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.


[1]  
https://github.com/ResponsiveImagesCG/picture-element/issues/62#issuecomment-24479164
[2] http://lists.w3.org/Archives/Public/public-html/2013Sep/0185.html

-- 
regards, Kornel
Received on Tuesday, 19 November 2013 01:02:11 UTC

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