W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] Media queries, viewport dimensions, srcset and picture

From: Mathew Marquis <mat@matmarquis.com>
Date: Tue, 24 Jul 2012 11:05:20 -0400
Message-Id: <E6A5CD59-89E8-48CE-AE3F-818EC6012E88@matmarquis.com>
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: whatwg@lists.whatwg.org

On Jul 23, 2012, at 5:38 PM, Steve Faulkner wrote:

> Hi Mat,
> as I previously previously mentioned, I am concerned about the use of the
> alt attribute on <picture> when it would be much better to allow text
> alternatives inside the picture element.
> Some of the advantages are:
> Markup can be used to structure text alternative content.
> The length of the alt text is no longer a constraint, as it is currently
> for assistive tech.
> 
> 
> <picture alt="Description of image subject.">
> <source srcset="small.jpg 1x, small-highres.jpg 2x">
> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
> 2x">
> <img src="small.jpg" alt="Description of image subject.">
> </picture>
> 
> is there any reason why you think the use of alt attribute on picture is
> preferable to
> 
> <picture role="img">
> 
> <p>alt text</p>
> 
> <source srcset="small.jpg 1x, small-highres.jpg 2x">
> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
> 2x">
> <img src="small.jpg">
> 
> </picture>

Yeah, this would be a bit tricky in terms of backwards-compatibility, as you said. I feel the gut reaction from a lot of authors would be ďI donít want that text showing up in some browsers but not others,Ē then (sadly) omission. Itís hide-able with CSS, as you said, but it would add some complexity.

> 
> note:role=img is just of polyfill purposes.
> 
> or
> 
> 
> <figure>
> <picture>
> <source srcset="small.jpg 1x, small-highres.jpg 2x">
> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
> 2x">
> 
> <img src="small.jpg">
> 
> </picture>
> <figcaption>caption text</figcaption>
> </figure>

This seems like a great candidate for `figcaption`, and could be pollyfilled, in a way, through the use of `aria-describedby`. I wouldnít want to discourage the use of `alt` tags on either `picture` or the fallback `img`, but ó and correct me if Iím wrong ó isnít `aria-describedby` specced to take precedence over the `alt` attribute? That might be the ideal approach ó and even if not, a bit of redundancy may not hurt there.

> 
> I can understand that backwards compatibility may be of concern in the
> first example, but that can be resolved through the use of CSS to clip or
> hide text content if so desired.
> 
> regards
> Stevef
> 
> 
> 
> On 23 July 2012 20:06, <whatwg-request@lists.whatwg.org> wrote:
> 
>> Send whatwg mailing list submissions to
>>        whatwg@lists.whatwg.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
>> or, via email, send a message with subject or body 'help' to
>>        whatwg-request@lists.whatwg.org
>> 
>> You can reach the person managing the list at
>>        whatwg-owner@lists.whatwg.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of whatwg digest..."
>> 
>> 
>> When replying to digest messages, please please PLEASE update the subject
>> line so it isn't the digest subject line.
>> 
>> Today's Topics:
>> 
>>   1. Re: Media queries, viewport dimensions, srcset and picture
>>      (Mathew Marquis)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Mon, 23 Jul 2012 11:39:14 -0400
>> From: Mathew Marquis <mat@matmarquis.com>
>> To: whatwg@lists.whatwg.org
>> Cc: Florian Rivoal <florianr@opera.com>
>> Subject: Re: [whatwg] Media queries, viewport dimensions, srcset and
>>        picture
>> Message-ID: <E4FEB344-8A53-438F-928A-9B9F0F3FE270@matmarquis.com>
>> Content-Type: text/plain;       charset=windows-1252
>> 
>> WHATWG,
>> 
>> The Responsive Images Community Group was recently asked to furnish a
>> formal draft proposal for consideration by the HTML WG. I thought it best
>> to post it here along with some details, where Ian Hickson has mentioned
>> that he?ll be considering this issue again within a few days.
>> 
>> More and more it seems that it?s a waste of effort trying to retrofit the
>> original srcset proposal to cover all the use cases of the original
>> `picture` proposal. As we attempt to do so, the `srcset` msyntax grows more
>> confusing, and shares an increasing amount of overlap with media queries ?
>> though with some obvious holes, for example: units other than `px`. To
>> those ends, the Responsive Images Community Group has officially published
>> a draft proposal based on Florian Rivoal?s proposed compromise (
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html) between the two markup patterns. In this way, `srcset` retains the
>> purpose for which it was originally proposed: a terse, easily-implemented
>> syntax for switching image sources based on the client resolution.
>> 
>> The draft proposal can be found here:
>> http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal
>> 
>> Discussion with the HTML WG can be found here:
>> http://lists.w3.org/Archives/Public/public-html/2012Jun/0113.html
>> 
>> ## Proposed Markup
>> 
>> <picture alt="Description of image subject.">
>> <source srcset="small.jpg 1x, small-highres.jpg 2x">
>> <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
>> <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg
>> 2x">
>> <img src="small.jpg" alt="Description of image subject.">
>> </picture>
>> 
>> The chain of events followed by the above markup pattern are:
>> 
>> 1. If the `picture` element is unsupported, the `img` contained therein is
>> shown as fallback markup.
>> 2. If picture is supported, use `media` attributes to determine which
>> source element best suits the user?s viewport, following the same logic as
>> `video`?s specced use of `media` attributes.
>> 3. Once an appropriate source element has been selected, the `srcset`
>> attribute determines which image source is best suited to the user?s screen
>> resolution. If only a single resolution is necessary, the `src` attribute
>> will function as expected, instead.
>> 
>> In terms of selecting a source element, this markup leverages all the
>> strengths of media queries ? the syntax created for this very purpose ? to
>> handle the ?art direction? use case.
>> 
>> However, as has been detailed at length here and elsewhere,
>> `device-pixel-ratio` media queries are poorly suited towards these
>> decisions. As an author, using vendor-prefixed `min-device-pixel-ratio`
>> media queries in the example above would involve a massive amount of text
>> and twice as many source elements. This could get unwieldy for authors very
>> quickly, a concern voiced numerous times in these ongoing discussions.
>> Further, implementation of MQ-based resolution switching is far more
>> difficult on the UA side: a very real concern.
>> 
>> Once we?ve used media queries to determine the most appropriate source
>> element, srcset?s originally intended usage becomes absolutely ideal for
>> our purposes: simply determining the appropriate image source for a user?s
>> resolution.
>> 
>> It?s worth noting that this example is, in fact, the most convoluted this
>> element can ever be. This pattern in no way precludes the use of srcset on
>> an `img` tag for simply preforming resolution switching, nor does it
>> preclude the use of `picture` as originally proposed for the ?art
>> direction?/screen size use cases, with `src` in source elements rather than
>> `srcset`.
>> 
>> ## Bandwidth
>> 
>> We cannot reliably make assumptions about bandwidth based on client
>> capabilities ? a MacBook Pro with a Retina display may be tethered to a 3G
>> phone; a high-resolution mobile device is as likely to be connected to WiFi
>> as it is an EDGE connection.
>> 
>> Based on previous discussion on the list, I think we?re largely in
>> agreement that bandwidth decisions are best left to the browser. It would
>> assume a great deal if authors were to make this decision for the users. It
>> would add a point of failure: we would be taking the bandwidth information
>> afforded us by the browser, and selectively applying that information. Some
>> of us may do it wrong; some of us may find ourselves forced to make a
>> decision as to whether we account for users with limited bandwidth or not.
>> To not account for it would be, in my opinion, untenable ? I?ve expressed
>> that elsewhere, in no uncertain terms. The decision to download high vs.
>> standard resolution images should be made by user agents, depending on the
>> bandwidth available ? and further, I believe there should be a user
>> settable preference for ?always use standard resolution images,? ?always
>> use high resolution images,? ?download high resolution as bandwidth
>> permits,? and so on.
>> 
>> In discussing the final markup pattern, we have to consider the above.
>> Somewhere, that markup is going to contain a suggestion, rather than an
>> imperative. I think `srcset` affords us that opportunity: a new syntax
>> _designed_ to be treated as such. I wouldn?t want to introduce that sort of
>> variance to the media query spec ? a syntax long established as a set of
>> absolutes.
>> 
>> It seems `srcset` won?t be going anywhere, and that?s not an indictment.
>> There is a time and a place for `srcset`, and I feel that place is
>> resolution switching ? as it was originally intended. Our best efforts to
>> bring srcset closer in-line with the originally proposed picture element
>> only stand to leave us with a siloed microsyntax that inconsistently serves
>> the purpose of media queries. With that comes further opportunity for
>> errors by implementors and authors alike ? countless new potential points
>> of failure.
>> 
>> ## Updated Polyfill
>> 
>> In order to better wrap my head around this pattern, I?ve updated Scott
>> Jehl?s Picturefill to make use of the proposed syntax. The source code is
>> available on GitHub ( https://github.com/Wilto/picturefill-proposal/ ),
>> and I?ve posted a demo ( http://wil.to/picturefill/ ) as well.
>> 
>> Thank you for your ongoing consideration, sincerely. I look forward to
>> finally putting this issue to rest.
>> 
>> Mat Marquis
>> 
>> 
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> whatwg mailing list
>> whatwg@lists.whatwg.org
>> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
>> 
>> 
>> End of whatwg Digest, Vol 100, Issue 28
>> ***************************************
>> 
> 
> 
> 
> -- 
> with regards
> 
> Steve Faulkner
> Technical Director - TPG
> 
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Tuesday, 24 July 2012 15:05:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:09 GMT