- From: Mathew Marquis <mat@matmarquis.com>
- Date: Tue, 24 Jul 2012 11:05:20 -0400
- 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 UTC