Re: Simplified source selection algorithm

On Tue, 17 Sep 2013 19:46:43 +0100, Kornel Lesiński <kornel@geekhood.net>  
wrote:

> On Tue, 17 Sep 2013 18:06:26 +0100, Cory Brown <oh.wise.man@gmail.com>  
> wrote:
>
>>> - The algorithm picks the first <source> that matches. Matching is done 
>>> based on media and type attributes.
>>
>> Agreed!
>> This would match the way video source is selected, but counter to the  
>> way CSS @media rules cascade. I had to address this in  
>> [x-picture](https://github.com/ResponsiveImagesCG/x-picture/blob/master/js/x-picture.js#L82)  
>> and leaned on last (media) match wins. Selecting the first match makes  
>> the selection algorithm simpler, but would mean authors address their  
>> media attributes on source elements in the reverse order they would in  
>> CSS. By no means a deal breaker, but since source elements with media  
>> attributes merges two paradigms, I wanted to make sure it was at least  
>> considered. I suppose no matter which way it went, first or last, it  
>> would be opposite one of the paradigms picture is borrowing from.
>That's a very good point. Since <video> MQs are rare (might even be  
> dropped from the spec) and authors are more likely to work with  
> images+CSS MQ than just images+video MQ, it may be worth adjusting the  
> order.

Reversing the order creates a problem: the algorithm can't be run during  
parsing until the </picture> end tag is seen. This is bad and something  
that HTML tries to avoid (<video> avoids it, but <object> has to do it  
because plugins need all parameters at init time).

Consider the following case:

<picture>
  <source ...>
  <source ...>
  <!-- packet boundary here, and data is a bit slow to arrive -->

With reverse order, the browser can't start downloading any source because  
there might come other <source>s that need to be checked first.

The same thing can happen if there's a lot of fallback content in the  
<picture>.

-- 
Simon Pieters
Opera Software

Received on Monday, 30 September 2013 15:02:54 UTC