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

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>

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>

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 Monday, 23 July 2012 21:39:29 UTC