W3C home > Mailing lists > Public > public-respimg@w3.org > October 2013

Re: What do we do with picture?

From: Kornel Lesiński <kornel@geekhood.net>
Date: Thu, 17 Oct 2013 17:45:06 +0100
To: Yoav Weiss <yoav@yoav.ws>, Marcos Caceres <w3c@marcosc.com>
CC: Anselm Hannemann <info@anselm-hannemann.com>, <public-respimg@w3.org>
Message-ID: <141c74e4328.2787.7ba2dab7ab189bf60d5422e61747bcec@geekhood.net>
Why is testing of an element require more tests than testing a set of 
attributes? Is that just due to a policy?

In my experience amount of tests is correlated to number of features and 
their edge cases and AFAIK srcN and picture have similar feature set. In 
both cases you'll need to test different combination of sources, media 
queries, mutations, browser states, etc.

On one hand you'll have bunch of DOM traversal tests, on the other bunch of 
parser edge cases. Overall seems to be the same league to me.

-- 
regards, Kornel



On 17 October 2013 16:48:51 Yoav Weiss <yoav@yoav.ws> wrote:
> On Thu, Oct 17, 2013 at 5:20 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>
> >
> >
> > On Thursday, October 17, 2013 at 4:13 PM, porneL wrote:
> >
> > >
> > > > This said, your points on the complexity of implementation are all
> > true.
> > >
> > > I disagree. I've shown that source implementation can be simplified to a
> > > dozen lines of JS.
> >
> >
> > I guess Yoav might have some details here, as he is they person who has
> > had to deal with this on the C++ level.
> >
>
> Implementation of picture's parsing is simpler then srcN (need to add some
> dataset() like facilities). Implementation of picture's preloadScanner is
> slightly more complex, since we need to maintain state ("are we in
> picture?", etc)
> All in all, both implementation are similar in their complexity.
>
> *But*, what I understood from browser vendors, the "scary" part about
> picture is testing. A new element would need a full test suite (very
> similar to the one img currently has).
> Briefly checking Blink's Layout-tests for tests that have "image/img" in
> their name shows about 800 tests. These tests would need to be duplicated
> and modified by hand to match picture.
> Having started that work (with David Newton doing most of the work) at some
> point, I understand that if this can be avoided, it'll be taking a huge
> maintenance burden off the shoulders of browser vendors.
>
> I heard one browser vendor saying that adding picture would require 10,000
> new tests. I think this is an exaggeration in an order of magnitude
> (assuming the <source> selection is simple and doesn't maintain state,
> similar to the one I implemented), but unfortunately, not more than that.
> 1,000 new tests for picture won't surprise me :/
>
>  >
>
> > > Please don't assume it has to be as messed up as <video>. Complexity
> > > doesn't come from DOM nodes, but from statefulness and massive JS API
> > > exposing network state.
> > >
> > > We can use <source> without repeating those mistakes.
> > Yoav?
> >
> >
> Again, implementation is easy. Testing is hard.
> But I'll be happy to be contradicted by browser vendors.
Received on Thursday, 17 October 2013 16:45:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:40 UTC