W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

[whatwg] add html-attribute for "responsive images"

From: Anselm Hannemann - Novolo Designagentur <anselm@novolo.de>
Date: Wed, 8 Feb 2012 18:16:36 +0100
Message-ID: <4FC86F80-134B-4094-9C59-B406ACFB9B6E@novolo.de>
Okay, I talked with some disabled web developers and Accessibility experts today and talked about the proposal of markup in alt-text.
This seems not to be a good idea as screenreader would read the tags which would confuse many users then.
So we would get into trouble with that approach according to current screenreader features, etc.

I think this should be postponed as it would need a whole rewrite to many (!) element-specs.
We should now focus on the initial problem and let alt contents be plaintext for now.

You might start a whole new discussion about this in a separate email but this would target all html-elements having alt-attributes.


Am 08.02.2012 um 11:18 schrieb Kornel Lesi?ski:

> On 8 lut 2012, at 07:14, Anselm Hannemann <anselm at novolo.de> wrote:
>>>> <picture alt="alternative text" src="default.jpg">
>>>> <source href="large.jpg" media="min-width:700px" />
>>>> <img alt="alternative text" src="default.jpg" />
>>>> </picture>
>>> 
>>> A new element may be an opportunity to get the "alt" right, i.e. in element's body, not flattened in an attribute.
>> 
>> Is there a reason for this? I think this is more confusing than everything else. And, an alternative text shouldn't have markup.
>> Alternative text should be all for accessibility. 
> 
> If my alternative text contains an abbreviation, shouldn't I be able to use <abbr>?
> 
> If it's a comic strip, why should I be forbidden from marking up the dialog accurately?
> 
> HTML already has in-element fallback for <object> and limited markup in <button>. 
> 
>>> <picture src="large.jpg" lowsrc="small.jpg"> <!-- or <source high-dpi-href="" or such> -->
>>> alternative <em>text</em>
>>> </picture>
>>> 
>>> as it's going to be very hard to write a media query that takes into account various screen sizes, DPI and bandwidth/metering at the same time.
>> 
>> This is similar to my approach using the common img-tag. In that case we don't need a new element.
>> But as you've said many people (also here) find it a bit hard to write. Imagine using 6 different image sizes in that case?
> 
> True. I like your approach too.
> 
> I think for bandwidth-saving having more than 2-3 versions (50, 100, 300 dpi) is an overkill, so length of attributes won't be a problem. 
> 
> 
Received on Wednesday, 8 February 2012 09:16:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:11 UTC