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

Re: [whatwg] The src-N proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 18 Nov 2013 17:12:12 -0800
Message-ID: <CAAWBYDAyO+3_veAT33iAwrRV6vvMNuQN=c+eHv=r1bGik6vcLA@mail.gmail.com>
To: Kornel Lesiński <kornel@geekhood.net>
Cc: WHATWG <whatwg@lists.whatwg.org>, James Graham <james@hoppipolla.co.uk>
On Mon, Nov 18, 2013 at 5:01 PM, Kornel Lesiński <kornel@geekhood.net> wrote:
> 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.

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.

Received on Tuesday, 19 November 2013 01:12:59 UTC

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