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

Tue Jul 24 08:40:26 PDT 2012

Hi Mat,

>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.

I would have thought a <picture> polyfill would handle the hiding. and I am
not sure that the possible backward compat issues should deter us from
providing a better text alternative method in the longer term.

besides thinking about it,  providing the alt on the img would suffice
until such times that lat text as a child of <picture> is supported (if
implemented).
which removes the need for alt on picture altogether, which is of no use
anyway until it is implemented.

<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" alt="Description of image subject.">
> </picture>

>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.

There is one current implenentation [1] (Firefox) of figure/figcation
accessibility.

this implementation can be illustrated using ARIA. although it does not use
ARIA, the acc support is provided through IAccessible2

<figure role=group aria-labelelledby="caption1">

<img>

<figcaption id="caption1"> caption text <figcaption>

</figure>

So the figcaption content labels the figure. Also note that the figcaption
has a role=caption (from IA2), but that is not currently defined in ARIA

In regards to aria-decribedby it does not override the alt attribute,
aria-describedby provides the accessible description, it is not used in
accessible name calculation. if aria-labelledby is on an img element it
overrides that alt.

[1]
figcaption
http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-43
figure http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-44

regards
SteveF

On 24 July 2012 16:05, Mathew Marquis <mat at matmarquis.com> wrote:

>
> 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 at lists.whatwg.org> wrote:
> >
> >> Send whatwg mailing list submissions to
> >>        whatwg at 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 at lists.whatwg.org
> >>
> >> You can reach the person managing the list at
> >>        whatwg-owner at 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 at matmarquis.com>
> >> To: whatwg at lists.whatwg.org
> >> Cc: Florian Rivoal <florianr at opera.com>
> >> Subject: Re: [whatwg] Media queries, viewport dimensions, srcset and
> >>        picture
> >> Message-ID: <E4FEB344-8A53-438F-928A-9B9F0F3FE270 at 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 at 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
>
>

-- 
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