On 25 November 2013 10:59:15 Yoav Weiss <y...@yoav.ws> wrote:
On Mon, Nov 25, 2013 at 11:32 AM, Kornel Lesiński <kor...@geekhood.net>wrote:
> 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.
Yes, you need to test the integration point, but you only need to test that
assignment of one attribute affects the other. You don't need to repeat
tests that test it deeper.
> 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.
Which variant you think is better?
> 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 believe it won't be an issue in the approach I've specified - when the
fallback img is separate from controlling image.
Scripts can avoid creating fallback img at all, because when scripting is
enabled they will use polyfill and can treat all UAs as supporting picture.
In that case fallback img would be like document.write("<noscript>") ;)
Maybe the spec should have authoring guidelines for this?
The controlling image starts with no src, so it won't download anything
that wasn't deliberately chosen through picture.
--
regards, Kornel
