Re: [whatwg] The src-N proposal

On Tue, 19 Nov 2013 12:40:17 +0100, James Graham <james@hoppipolla.co.uk>  
wrote:

> On 19/11/13 01:55, Kornel Lesiński wrote:
>> On Tue, 19 Nov 2013 01:12:12 -0000, Tab Atkins Jr.  
>> <jackalmage@gmail.com>
>> wrote:
>>
>>>> AFAIK it makes it as easy to implement and as safe to use as src-N.
>>>>
>>>> Simon, who initially raised concerns about use of <source> in  
>>>> <picture>
>>>> found that solution acceptable[2].
>>>>
>>>> I'd love to hear feedback about simplified, atomic <source> from other
>>>> vendors.
>>>
>>> The cost there is that <picture><source> is now treated substantially
>>> differently than <video><source>, despite sharing a name.
>>
>> The substantial difference is that it lacks JS API exposing
>> network/buffering state, but IHMO that's not a big loss, as those
>> concepts are not as needed for pictures.
>>
>> IMHO the important thing is that on the surface (syntactical level)
>> they're the same - multiple <source> elements where the first one  
>> matches.
>
> So the remaining objections I am aware of to atomic-source are:
>
> * Something related to animations. I don't actually understand this, so  
> it would be nice if someone who does would explain. Alternatively this  
> might not actually be an issue.
>
> * Verbosity. This proposal is clearly verbose, but it is also the one  
> that authors seem to prefer, largely because it uses the underlying  
> markup syntax in a natural way. It seems that people will likely deal  
> with the verbosity by copy and paste, templates or libraries to provide  
> a convenient shorthand. If the latter occurs we can look at  
> standardising it later.
>
> * More testing is needed. Specifically it seems that tests will be  
> needed to use <source> elements (or <picture> elements?) where you can  
> currently use <img> elements. This is a real concern of course, but  
> seems lower on the priority of constituencies than authoring concerns,  
> unless we think that poor interop will poison the feature. With an  
> atomic proposal this seems much less likely, Hopefully implementations  
> will be able to reuse the existing <img> code so that the actual amount  
> of new *code* to test is less than you might think by looking at the  
> extra API surface.

Also see discussion in  
http://krijnhoetmer.nl/irc-logs/whatwg/20131119#l-537

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.

If we want to avoid that problem but still use <source> elements, that is  
possible by using <img> for rendering the image and <source> for providing  
the sources. There is precedent for this sort of thing in HTML, namely  
<input list=x> <datalist id=x><option>...</datalist>.

My first idea along these lines was to use <img list="">  
<sourcelist><source ...>...</sourcelist> where, if the img element has a  
list attribute, the next element sibling is used for the sources. However,  
Anne pointed out a problem that it wouldn't work so well if you want to  
create the image in script and have it load without appending it to the  
document, since they wouldn't be siblings. There are ways to make it work  
but it would be non-obvious and it's better to come up with something that  
just works.

So my next idea is to put the img element inside the sourcelist element,  
like so:

    <sourcelist> <img list=""> <source>... </sourcelist>

The sourcelist element would be a normal inline element and only serve to  
bind together the img with the source elements. I've left the list  
attribute on img because currently the <img src> would start loading as  
soon as the element is created by the HTML parser, before the element is  
inserted to the document so there is no parent. If we want to get rid of  
the attribute, we can make the HTML parser set a "parser-created" flag on  
the img element and upon element creation, if the flag is set, do nothing,  
and when it is inserted to the document, if the flag is set, unset it and  
run 'update the image data' steps. (The spec says to await a stable state  
before downloading anything, I don't know if browsers want img to wait  
with downloading until the parser yields or would rather handle a flag and  
not await a stable state for parser-created 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.

If we want similar syntax to <video>, the <source>s should go first and  
the <img> last.

So:

<picture>
  <source ...>
  <source ...>
  <img src="fallback" alt="...">
</picture>

The selection algorithm would only consider <source> elements that are  
previous siblings of the <img> if the parent is a <picture> element, and  
would be called in place of the current 'process the image candidates' in  
the spec (called from 'update the image data'). 'Update the image data'  
gets run when an img element is created, has its src or crossorigin (or  
srcset if we still want that on img) attributes changed/set/removed, is  
inserted or removed from its parent, when <source> is inserted to a  
<picture> as a previous sibling, or a <source> that is a previous sibling  
is removed from <picture>, or when a <source> that is a previous sibling  
and is in <picture> has its src or srcset (or whatever attributes we want  
to use on <source>) attributes changed/set/removed. 'Update the image  
data' aborts if the parser-created flag is set. When img is inserted to  
the document, if the parser-created flag is set, the flag is first unset  
and then 'update the image data' is run but without the await a stable  
state step.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 19 November 2013 22:08:04 UTC