On Tue, 19 Nov 2013 22:07:33 -0000, Simon Pieters <sim...@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
