[whatwg] The src-N proposal

[Kornel Lesiński]

On Tue, 19 Nov 2013 22:07:33 -0000, Simon Pieters <simonp at opera.com> wrote:

> In http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0045.html  
> I discuss a problem that a new element would have, namely that it would  
> require a new fallback mechanism and a lot of stuff would need to be  
> duplicated from img.

Do we need usemap? We can probably drop it. We don't need to replicate  
lots of legacy features and quirks of <img>.

I think the upside is that we can ship <picture> with almost no features,  
and re-add them only as necessary.


For the fallback:

<canvas> is an existing example of a picture with a fallback DOM, so  
browser vendors already have to implement/implemented fallback for  
<picture>-like element.

I would go further and simplify it by forbidding all interactive  
(focusable) elements in <picture> fallback DOM. Canvas already forbids  
interactive elements with some exceptions, but for picture we don't even  
need these exceptions. This authoring rule can be validated easily, and  
allows UAs to avoid real difficulty of handling focus in fallback.

To make <picture> easy to plug into existing ATs I suggest specifying that  
UAs MAY interpret fallback content as text extracted using innerText  
algorithm (preserves space between elements) with additional rule that  
@alt from any <img> in the fallback is extracted as well (so <picture><img  
alt="old alt"></picture> as well as <picture><p>fancy alt</p></picture>  
will have good accessibility in all UAs).

This should be zero extra work for implementors, since that's what they  
already do for copying selection to plain text clipboard.

With plain text extracted from the fallback it will be possible to reuse  
accessibility interfaces designed for <img alt>.

When <picture> implementations mature we may eventually be able to let  
authors rely on more structured fallback. In any case we're better off  
than with strictly-plaintext-forever <img alt>, and the first version of  
<picture> can be guaranteed to be be easily implementable in terms of  
<img>.

> At this point we could change the name of the wrapping element to  
> <picture> and basically have the same syntax as current <picture> except  
> there would be a required <img> child element.

The <x-picture> polyfill implements <picture> using <img>  
(http://uniqname.github.io/x-picture/), so that's definitely a way to do  
simple implementation.

An <img> element will be de-facto required for a while as a fallback, but  
could it be optional eventually? I think that even if browsers implement  
<picture> using <img>, the <img> element itself should be hidden in shadow  
DOM.


If we don't explicitly define <picture> as wrapper for <img> then yes,  
we'll need separate test cases for <picture>, but:

- hopefully plenty of cases can be adapted with little more than  
find'n'replace <img src=" with <picture><source src="
- We don't need to bring all the legacy baggage of <img>, so a bunch of  
tests for Netscape'isms can be deleted.
- Image element has weird stuff like .complete property that can change  
synchronously. Kill it! With clean slate we can define only minimal,  
quirk-free API that is much easier to deal with.
- Test cases is something that can be shared between browser vendors, and  
the community can help adapt <img> test cases to <picture>, so we can  
spread the effort.

-- 
regards, Kornel