Re: [whatwg] Simplified <picture> element draft

On Mon, Nov 25, 2013 at 11:32 AM, Kornel Lesiński <kornel@geekhood.net>wrote:

> 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'm not saying it isn't, but it's not what we previously discussed on the
list.


> 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.


I believe these interfaces would be something you'd need to test, so you
would have testing duplication, even if you save code duplication. I'm not
sure that the goal of getting rid of <img> 5-10 years from now, is worth
that cost.


>
>  * 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.
>

The problem here is not the preloader, but the HTMLImageElement itself,
which currently downloads a resource upon creation. With that said, it's an
issue we'd have to deal with in both cases, regardless of which element
controls which, and if <picture> has the control, we can probably define
that it controls only the first/last <img> it encounters.


>
> 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).


I agree that it would make sense for authors.


>
>
>  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.
>

Again, this is an issue with HTMLImageElement itself, not the preload
scanner. It'd probably require modifications to the <img> section of the
HTML spec.


>
> 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:59:46 UTC