Re: Adaptive Image Element Proposal

On Sep 11, 2012, at 10:10 AM, Leif Halvard Silli wrote:

> Laura Carlson, Tue, 11 Sep 2012 06:23:30 -0500:

[ … ]

> By the way: We have (please test to verify!) the same situation today 
> for <canvas>: If someone places a <img> with a longdesc inside a 
> <canvas>, then contextual menu access users will not get access to the 
> longdesc unless the <canvas> fails to load so that users get the 
> fallback instead. HOWEVER, screenreader users and other AT users might 
> still get access. And perhaps that is good enough?  May be not all 
> users need access to @longdesc - perhaps that is to aim too high?

I feel we could put together a somewhat representative test case for this behavior using the `canvas` or `video` tags with a fallback image, though I’m not sure if it would be a 1-1 comparison. I can put those test cases together, but I may not have time to test much — perhaps that’s something we could open up to the community?

> 
> We don't know ho <picture> will end up functioning, but we should 
> assume that its (rendered) graphic resource will overlay the image of 
> the child <img> element. If we should expect something else, then 
> please - Mat or whoever - gives us reason to believe so. Until then: 
> Provide @longdesc and @alt really aer crucial, the I come back to the 
> conclusion that it is better to drop <picture> and instead go for 
> extending <img> with @srcset etc. Because, in that case, there would be 
> no doubt thagt the <img> element lands on top.

I’m not sure what you mean in terms of “overlay”—you mean from a rendering standpoint? In browsers with native support for `picture`, the fallback image would never be rendered at all. The behavior of Harry Roberts’ polyfill wouldn’t be indicative of the final native behavior; I believe it uses absolute positioning to do as you describe above.

> 
> In the debates about <picture> on WHATWG, it seems like Mat's reason 
> for going for <picture> rather than for @srcset on <img>, has to do 
> with authoring convenience. Then remember that, provided @longdesc and 
> @alt is a must, the much debated HTML5 design principles put users 
> needs above author needs. 

Author preference is certainly a factor, but one that should only ever trump implementor preference — it is a very small factor when compared to the potential for an improved user experience.

There are a number of use cases fulfilled by `picture` that aren’t addressed by the extended `srcset` syntax. I won’t go into detail on the specific use cases here (they’re documented in the proposal itself), but one of the key points of difference is this: as new media queries are specced and implemented, we’ll be able to make even greater use of `picture` over time. It’s one thing to say “we probably won’t need more than X, Y, and Z to serve images appropriately” right now, but we similarly couldn’t have anticipated a “high-contrast mode” media query prior to a few years ago either — once that high-contrast mode MQ avails itself, perhaps we could use it to better tailor the images on sites to users of that context. Perhaps by next year, we’ll have scores of proposed a11y-related media queries we can leverage to the benefit of our users. Unless those were implemented independently in `srcset`, those would be unavailable to us.

This even extends to current features: it’s becoming common practice for authors to use `em`-based media queries in speccing their layouts, which is incredibly heartening to see: in all the major browsers, this allows the user to set their zoom level at whatever they prefer without fear of the layout collapsing in on itself. ( See: http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ ) A tremendous a11y benefit with little additional effort on the part of authors — a potentially *accidental* benefit, in fact. Seamless accessibility. Using the extended `srcset` syntax, on the other hand, authors will be forced to convert those `em`-based values to pixels — the only supported value — and the sources (based on current browser behavior) wouldn’t be reevaluated on user zoom. A zoom-appropriate layout with blurry images, or images at sizes inappropriate to the current layout.

We’re locked into a siloed microsyntax with the extended `srcset` — either forever playing catch-up with media queries, or locked into a limited set of options forever. It’s well beyond being simply an author preference for media queries: media queries are  the author preference because they’re the better solution, for themselves and for the users they support.

The primary justification for the extended `srcset` syntax is that media queries in markup are difficult to implement on the UA side — this is a real concern, and there have been no small number of vocal UA representatives speaking to this. Granted, this should — on paper — be trumped by author preference alone, if we were to set aside the users for a moment. But we cannot and should not set aside the users in any discussion of upcoming standards. Both author and implementor preferences pale by comparison.

So, that said: I have yet to see a user benefit cited in favor of `srcset`. It fulfills only a faction of `picture`s use cases today, and has incredibly limited potential for the future. It doesn’t stand to benefit users more than `picture` — and fortunately, authors prefer the solution that *does* stand to have greater user benefit. A good situation to be in, I’m sure we can all agree.

All things considered, I’m not certain why the extended `srcset` syntax is still on the table apart from implementor preference.

> 
>> Leif, I also checked your test page:
>> http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/
>> The images on this page do not seem to be responsive images but static
>> images.
> 
> Like I say in test 2,[1] that specific test is a inspired by Harry 
> Roberts’ “responsive images right now”-technique. [3] However, there is 
> no "break point" in that test - so there is only one image size ... It 
> is not necessary, for the subject at hand, that it is more real than 
> that.

All things considered, the deciding factor here seems to be whether AT would be able to “reach into” the `picture` element to determine the attributes and content set within — if that is how things work, the behavior of `picture` with a fallback image will be no different from an independent `img` tag. 

We shouldn’t let our decision on the best *native* solution hinge on the behavior of a single JavaScript solution that wasn’t designed to perfectly align with the proposed native behavior.

I’ve been maintaining a branch of Scott Jehl’s Picturefill that matches the proposed syntax and behavior as closely as possible, though it has not yet been updated to match the updated a11y guidelines in the proposal based on our discussions here. Where this branch is the closest to parity with a native implementation, I feel it makes the most sense to test against this. Again, as I said above: a polyfill won’t serve as a perfectly representative test case, but something closer to the proposal may serve to shed more light on the subject.

https://github.com/scottjehl/picturefill/tree/div-markup-currentprop

This doesn’t warrant testing at the moment, as it doesn’t follow the behavior we’ve outlined this far. I’ll update it to match the proposal, and we can test when that time comes. I’ll keep you all posted.

-M