[whatwg] Simplified <picture> element draft

[Simon Pieters]

On Mon, 25 Nov 2013 12:48:42 +0100, Kornel Lesiński <kornel at geekhood.net>  
wrote:

>
>> The advantage of the scheme that zcorpan proposed is that there is no  
>> magic proxy; we just add a capability to <img> to select its source  
>> using more than just a src attribute. This has better fallback than  
>> your design and is easier to implement.
>
> I believe that from testing perspective both approaches are equivalent.

I think they are not equivalent.

You introduce a proxy that needs to be tested to see that it works in  
different scenarios (e.g. removing an attribute, that events are forwarded  
properly, that it does not affect parts it shouldn't like document.images,  
that the context menu works, etc.).

You introduce a (or two) new fallback mechanism.

You haven't specified that <picture> should be able to be drawn on a  
canvas in 2d (and WebGL?).

You haven't specified the crossorigin attribute.

You haven't specified that <picture> provides a paint source for CSS's  
element() feature.

You haven't specified that <picture> participates in  
http://www.whatwg.org/html#using-the-a-element-to-define-a-command

You haven't specified what the origin is for <picture>.

You haven't specified that createImageBitmap() accepts <picture>.

You haven't specified that <picture> should default its .draggable  
attribute to true.

I'm sure I've missed a few things, but I think my proposal avoids the  
issues.


> The spec I propose *is* only another way to control src of an image.
>
> The only difference is that I don't expose the <img> to scripts.

What is the motivation?

> That may make it even simpler, because you can't have odd cases like  
> author moving/removing the controlling img or setting values directly on  
> img that conflict with picture's definitions.

I don't see what would conflict in my proposal.

-- 
Simon Pieters
Opera Software