W3C home > Mailing lists > Public > public-respimg@w3.org > September 2013

Re: Simplified source selection algorithm

From: Cory Brown <oh.wise.man@gmail.com>
Date: Tue, 17 Sep 2013 13:06:26 -0400
To: Marcos Caceres <w3c@marcosc.com>, Kornel Lesiński <kornel@geekhood.net>
Cc: public-respimg@w3.org
Message-ID: <etPan.52388c12.2ae8944a.20c@corbrown7302mlb>
> - 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.

-- 
Cory Brown
Sent with Airmail

On September 17, 2013 at 10:33:43 AM, Marcos Caceres (w3c@marcosc.com) wrote:




On Monday, September 16, 2013 at 11:53 PM, Kornel Lesiński wrote:  

>  
> In response to Simon Pieters' criticism that <source> selection algorithm  
> is too complex[1], I've drafted a simpler one:  
>  
> https://github.com/ResponsiveImagesCG/picture-element/issues/62#issuecomment-24479164  
Just a quick note that we've (the Editors) been thinking along the same lines (and I've got a hacked up version of the spec over in my repo that already does some of the above). It's also what I presented during the workshop (i.e. "we are getting rid of the kitchen sink!")  
>  
> Simon finds this algorithm acceptable[2]. I'd like to hear your opinion  
> whether such solution is OK.  

I thought his concern was more about having multiple elements … but anyway :)  
>  
> - Dependency on Media Element and <video>-like algorithm is gone. There's  
> no networkState property.  

Agreed!  
>  
> - The algorithm picks the first <source> that matches. Matching is done  
> based on media and type attributes.  

Agreed!  
>  
> - I haven't written that explicitly on github, but selected <source  
> src/srcset> is interpreted pretty much like copying of its attributes to  
> <img src/srcset>.  

Yep. Note also that <picture> no longer has a src or srcset attribute.  

> - Browser will re-evaluate sources whenever conditions change (so if  
> device is rotated or window is resized a different source may be picked,  
> and different image may be loaded).  

Agreed.  
>  
> - Choice is made asynchronously and atomically from JavaScript's  
> perspective (i.e. messing with <source> DOM elements won't change the  
> selected source until next event loop tick).  

Nice. Had not talked about this in the spec yet - but we were thinking the same thing.  
> - If you use <source media> with media query that browser cannot evaluate  
> immediately (e.g. min-width: in an iframe that has no layout yet) browser  
> may delay fetching of the image until CSS is loaded.  

Nice too :)  
Received on Tuesday, 17 September 2013 17:06:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:40 UTC