Re: [whatwg] Simplified <picture> element draft

On 25 November 2013 08:00:10 Yoav Weiss <yoav@yoav.ws> wrote:

> It contains some parts that I'm not sure have a consensus around them yet:
> * It defines <picture> as controlling <img>, where earlier on this list we
> discussed mostly the opposite (<img> querying its parent <picture>, if one
> exists)

Controlling image is a great idea. It greatly simplifies the spec and 
hopefully implementations as well.

I chose not to expose that implementation detail, assuming that one day 
(when all UAs, crawlers implement it) we will not need explicit <img> 
fallback any more.

If picture was explicitly controlled by img then websites could start 
depending on that behavior, and we'd be stuck with it. OTOH picture can 
have "native" DOM interface and still reuse img for implementation.

> * It defines <img> as a part of <picture>'s shadow DOM, which we need to
> see how it fits with having fallback <img> elements (which are necessary in
> the near future).

I've added section about preloader. The img in fallback content should be 
ignored by the preloader. It's purely for picture-less UAs.

I do wonder however if fallback img should be used as equivalent of a 
<source> to save authors a bit of repetition. (in selection algorithm the 
first step would be "for each source or img child...") or perhaps be used 
as last-resort fallback when no source matches (step 2 of the algorithm).

> This proposal does contain srcset as a subcomponent, but it's not the same
> srcset as defined in the HTML spec, but a modified version based on
> improvements from the src-N spec. (that cover the variable-width images
> use-case)

Indeed. This part of the spec isn't ironed out yet.

> The proposal will also require some changes to <img> and specifically, when
> not created by JS, <img> will have to avoid loading of resources until the
> element is added to the DOM, and can see if its direct parent is <picture>.
> If the parent is <picture>, <img> would then query the parent (or wait to
> be "controlled" by its parent), otherwise, it'll load its resources as
> usual.

I've specified something like that. I think it can be as simple as a flag 
that preload scanner uses internally.

I think we don't need to add any runtime behavior changes for this, as 
scripts constructing <picture> will not insert explicit fallback <img> node 
- it makes more sense to rely on <picture> polyfill instead (that will use 
img with correct src from the start).

-- 
regards, Kornel

Received on Monday, 25 November 2013 10:33:14 UTC