Re: Is algorithm for selecting based on media query defined?

Well, there are more points of departure here from video than just that. For example, video and audio sources are not reassessed on resize/orientationchange, or at least, as far as I know (I can check). 

If the first source is kept, that'd mean ordering images largest to smallest. That seems unnatural/unexpected to me, but I'm not sure if others agree. Maybe it's my mobile-first mentality seeping in :)


On May 17, 2012, at 9:48 PM, Aaron Gustafson wrote:

> On Thursday, May 17, 2012 at 8:55 AM, Scott Jehl wrote:
>> Fwiw, when working on the picturefill prototype/polyfill, we decided that the last source element that matched would be used.
>> And they would be reassessed on resize, orientation change, etc.
>> 
>> I guess since it's a media query feature, it seemed like mimicking CSS cascade/overriding felt natural there.
>> 
> 
> While I can definitely understand and respect your choice, it does seem to go against existing standards (assuming I am reading the source selection spec correctly). I think if we are going to pursue picture (and I believe we should), and we are using audio/video as a basis for the element, we need to be as true to the existing standards as possible. Make sense?
> 
> Cheers,
> 
> Aaron
> 
> -- 
> Aaron Gustafson
> @AaronGustafson
> aaron-gustafson.com
> 
> -------
> Aaron takes no responsibility for poor spelling in this message. It was pecked out by fat fingers on a tiny screen.
> 
> 
>  
>> 
>> On May 17, 2012, at 8:46 PM, Aaron Gustafson wrote:
>> 
>>> On Thu, May 17, 2012 at 7:47 AM, Kornel Lesiński <kornel@geekhood.net> wrote:
>>>> On Thu, 17 May 2012 15:22:04 +0100, Aaron Gustafson <aaron@easy-designs.net>
>>>> wrote:
>>>> 
>>>>> Traditionally, the first to match is the one picked. In the video
>>>>> element, this is why we put WebM before Ogg: the same browsers support
>>>>> both, but WebM is smaller, so we put it first so it is the one that’s
>>>>> downloaded.
>>>> 
>>>> 
>>>> Is that the case for <picture> as well? It doesn't seem to match examples.
>>>> 
>>>> How is interpreted source without media? (media="all"? media="none"?)
>>>> 
>>>> 
>>>> http://www.w3.org/community/respimg/2012/03/07/14/
>>>> 
>>>> <picture alt="Alt tag should accurately describe the image represented by
>>>> all sources, though cropping and zooming may differ.">
>>>> <source src="mobile.jpg" /> <!-- Matches by default. -->
>>>> <source src="high-res.jpg" media="min-width: 800px" /> <!-- Overrides the
>>>> previous source over 800px before any assets are fetched, resulting in a
>>>> single request. -->
>>>> <img src="mobile.jpg" /> <!-- Fallback content, in the event the <picture>
>>>> tag is completely unsupported by the user’s browser. -->
>>>> </picture>
>>>> 
>>>> In that case I'd expect <source src="mobile.jpg"> to always match and
>>>> <source src="high-res.jpg"> be impossible to use.
>>> 
>>> 
>>> You are correct that it doesn’t match up with the examples. This is
>>> one thing that will have to worked through from an implementor’s
>>> perspective. We need hard and fast rules for precedence. The model
>>> picture is now using seems more like the cascade of style sheets than
>>> the way video and audio sources are handled.
>>> 
>>> In terms of the source element, media queries are evaluated after the
>>> media type in the process (see "resource selection algorithm":
>>> http://dev.w3.org/html5/spec/single-page.html#concept-media-load-algorithm
>>> step 6’s else flow #6) and failure to apply a given source (based on
>>> media query or otherwise) results in a move to the next source.
>>> Picture would need to function the same way lest we cause confusion
>>> for either element type.
>>> 
>>> Cheers,
>>> 
>>> Aaron
>>> 
>>> ----
>>> Aaron Gustafson
>>> Principal
>>> Easy Designs, LLC
>>> +1 877 EASY 313 x101
>>> aaron@easy-designs.net
>>> @aarongustafson
>>> 
>>> === OUT NOW ===
>>> Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement
>>> http://adaptivewebdesign.info
>