Re: Feedback on Responsive Images Extension

On Sep 4, 2012, at 9:49 PM, Andrew Kirkpatrick wrote:

> Fair enough.  I'll hold my concerns for now.  I do think that we'll see people targeting specific devices and loading images, and it would be good to prevent or more actively discourage it.  One way might be to get a WCAG failure technique as soon as we see implementations of <picture> so at least people will have another resource to help show that all that is possible is not acceptable.

No question of that! This proposed markup has the benefit of being a very high-visibility issue in the developer community, and that gives us a great opportunity to encourage good habits.

I hadn’t heard of these WCAG failure techniques before — this is helpful information for sure. Thanks so much, man.

-M



> 
> Thanks,
> AWK
> 
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems 
> 
> akirkpat@adobe.com
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
> 
> 
> -----Original Message-----
> From: Mathew Marquis [mailto:mat@matmarquis.com] 
> Sent: Tuesday, September 04, 2012 6:40 PM
> To: Andy Davies
> Cc: Anselm Hannemann; Brett Jankord; Andrew Kirkpatrick; public-respimg@w3.org
> Subject: Re: Feedback on Responsive Images Extension
> 
> On Sep 4, 2012, at 6:17 PM, Andy Davies <dajdavies@gmail.com> wrote:
> 
>> On 4 September 2012 23:03, Mathew Marquis <mat@matmarquis.com> wrote:
>>> 
>>> On Sep 4, 2012, at 5:46 PM, Anselm Hannemann wrote:
>>> 
>>> We had this discussion a couple of months ago in the W3C community 
>>> group. I started it with the same intends as Andrew but after all it 
>>> we came to the resolution that it's not what picture is thought for.
>>> If you define a picture-element you will most likely link to one 
>>> image. This image crop/color/properties can vary but not the image 
>>> meaning / content itself. If you want the meaning / content to 
>>> change, just use a server-technology or JavaScript to properly change 
>>> the source and alt. But it's no use-case for the picture-element.
>>> 
>>> 
>>> Agreed: this is a case better solved by way of JavaScript or 
>>> server-side UA detection. If the subject matter cannot be accurately 
>>> described by a single `alt` attribute ( or additional descriptive 
>>> markup, as discussed previously ), it is a disparate set of images 
>>> and not a case I feel we should account for with `picture`.
>> 
>> I guess my question would be how does someone specify a 'null' image 
>> then i.e. have an image a certain breakpoints but no image at others.
> 
> One could make a case that an image not essential to every browsing context may well be presentational in nature, and should be handled through CSS. Else, in the case of strictly *content* images, that markup should likely be injected/removed or shown/hidden through JavaScript by way of matchMedia — alternately, that markup could be omitted entirely based on server-side device detection.
> 
> I wouldn’t want to encourage inherently "null" markup with regards to images any more than I would encourage a solution for serving "null" text — which is to say, the "null" case is best represented by the absence of said markup altogether. A native solution for controlling the *presence* of markup based purely on client capabilities is a larger conversation, and very likely one worth having. I don’t feel this is best solved on an element-by-element basis, however.
> 
>> 
>> Resorting to JS to fix this seems the 'wrong' way to go to me
>> 
>> Cheers
>> 
>> Andy
>>

Received on Wednesday, 5 September 2012 14:23:46 UTC