On 25 November 2013 08:00:10 Yoav Weiss <y...@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
