[whatwg] The src-N proposal

[Kornel Lesiński]

On Tue, 19 Nov 2013 20:12:23 -0000, Ian Hickson <ian at hixie.ch> wrote:

> I responsed to proposals along those lines last year:

This may be a good time to revisit and re-evaluate this. When <picture>
and srcset were proposed initially there was still a lot of confusion what
"reponsive image" actually means and we spoke past each other a lot.

RICG has collected, evaluated and categorized use cases
(http://www.w3.org/TR/respimg-usecases/), so now we understand problems
better and have terms like "DPR switching" and "art direction" to describe
features we need.

We've discussed many alternatives (multiple times, *sigh*) and <picture>
is being refined.

>    http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html
>
> Search for "multi-element" for the specific response to proposals that
> involve multiple elements.

Here's that response:

>  - it's closer to the solution to the similar problem that is being 
>    resolved for CSS, namely image-set().

image-set() solves the DPR switching use case quite well, but by itself it
doesn't address art direction or other aspects.

At the recent RICG meetup in Paris nobody could give a correct,
straightforward explanation what combination of srcset w/h descriptors
actually does, and meaning of the syntax was commonly misunderstood. The
consensus was that it's a confusing syntax, w/h descriptors aren't going
to be implemented, and that part of srcset should be dropped.

So srcset is a good solution to one of the problems, but is not sufficient
to end the discussion. The latest <picture> proposal adopts srcset, and
srcset concept has been extended in src-N proposal to support remaining
cases.

>  - it doesn't involve multiple elements. Generally, processing models for 
>    multi-element structures in the DOM are a disproportionate source of 
>    trouble in a wide variety of areas:
>     - they introduce the need for much more elaborate error handling,
>       since they have multiple failure modes (what happens if one or 
>       another element is found in another, or if the outer element has an 
>       unexpected inner element?)

It's enough to specify that <picture> should check its <source> children
and implementation is quite simple:

https://github.com/ResponsiveImagesCG/picture-element/issues/62#issuecomment-24479164

>     - the processing model has to deal with changes more complicated than 
>       just "change" (what if an element is added or removed, or moved?)

The "simplified source selection algorithm" I've proposed solves this:
evaluation of sources is scheduled to run on the next tick after mutation,
and the algorithm is stateless, so it doesn't have to track mutations and
JavaScript can't disrupt it.

>     - it introduces all kinds of complicated questions once you introduce 
>       shadow trees (what if you bind something with a special child? what 
>       if the shadow tree contains such a child?)

I'm not sure what kind of binding you mean. Can you elaborate?

Fallback DOM in <picture> is similar to one we have in <canvas>, and I
think it could be simplified even further by forbidding any interactive
(focusable) content (that's not a loss compared to <img alt="">).

>     - it introduces complexities in the algorithms to deal with  
> unexpected
>       text nodes, comment nodes, PIs, etc.

if (children[i].nodeType != 3) continue;

>     - it introduces some complexity in the parser, because you have to 
>       handle the case where you're only half-way through parsing the 
>       "parent" element when you return to the event loop, with more 
>       children elements to process (when does the processing model 
>       start? what do you expose in the DOM API half-way through? etc).

Simplified source selection algorithm solves this. Following Simon Peters'
suggestion it picks the first source that matches (and match is evaluated
immediately without going to the network), so it won't trigger invalid
download when presented with incomplete DOM during page load (packet
boundary), and the preloader doesn't even have to wait for </picture> end
tag.

>  - it resolves the intrinsic sizing for high-res images issue discussed 
>    earlier in this e-mail.

This has been a problem with the earliest draft of <picture>, but now all
proposals solve this as well.

>  - it's a lot less verbose.

For just 2x modifier srcset is nice and concise, but it quickly gets messy
when you add more features. Some of the single-attribute proposals were
pretty close to looking like Perl.

Verbosity of <picture> is a cost of following design patterns prevalent in
HTML, but it makes the syntax really easy to understand. We have <select>
and not <input optionset="">, <meta> and not <head meta-1="" meta-2="">
etc.

Ability to use named attributes on <source> makes it extensible in a
straightforward manner. OTOH microsyntax with multiple delimiters is more
prone to authoring errors and it's impossible to extend without
complicating it even further (e.g. if we ever need more attributes for,
say, 3d glasses, we can just add <source 3dglasses=""> rather than
complicating microsyntax with attribute-within-attribute and/or extra
layers of delimiters and escaping).

Authors already have ways of dealing with verbosity of HTML and DOM APIs
(templating, jQuery, etc.), and we have proposals for reducing repetition
with orthogonal features like Media Query Variables, so I think we can
afford starting with a bit verbose, but sane and straightforward syntax.

> The lesson we learnt from <video>/<source> isn't that the pattern is an 
> easy choice. It's that we should avoid it if at all possible. :-)

<video> was undoubtedly painful, but I've looked at <video> test cases and
media selection algorithm and I think the pain was caused by
video-specific problems and complexity of MediaElement algorithms and
APIs, and is not inherent to use of elements in HTML in general.

Images don't need to expose API for buffering, seeking, playback states,
etc. Image sources can be evaluated using simple, stateless atomic
algorithm - basically same algorithm as you'd use for an attribute, but
instead of using custom attribute parser you read attributes from child
nodes.

-- 
regards, Kornel