Re: What do we do with picture?

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.