W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: Proposal: accessibility revision for the img element...

From: Robert Burns <rob@robburns.com>
Date: Tue, 26 Jun 2007 05:26:15 -0500
Message-Id: <D6BF434F-1F60-4653-83F7-61B244DF74EA@robburns.com>
Cc: "Ben Boyle" <benjamins.boyle@gmail.com>, "Charles McCathieNevile" <chaals@opera.com>, "Olivier GENDRIN" <olivier.gendrin@gmail.com>, "Sander Tekelenburg" <st@isoc.nl>, public-html@w3.org
To: Anne van Kesteren <annevk@opera.com>

On Jun 26, 2007, at 5:06 AM, Anne van Kesteren wrote:

> On Tue, 26 Jun 2007 12:01:59 +0200, Ben Boyle  
> <benjamins.boyle@gmail.com> wrote:
>> Still, it would be good if the spec allowed for it so that one future
>> day we can use <img> consistently ... the proposal to add <image>
>> (separate to <img>) has merit I believe... leaving <img> as is for
>> compatibility and introducing <image> for consistency with <video>  
>> and
>> <audio>. I vote for this option.
> Apparently it was not clear before: we can't change parsing rules  
> for <img> and <image>. <image> turns into <img> during parsing for  
> legacy reasons. Neither element has a closing tag. I believe the  
> goal for this WG is to remain backwards compatible. Not invent a  
> new language on top of the old one.

This is being discussed in another thread: "the market hasn't spoken  
- it hasn't bothered to listened [was Re: fear of "invisible metadata"]"

For example:

Understood about the specific <image> example.  However, the idea  
remains the same. Other options have been provided such as: <still>,  
<pic>, <picture>. I'm sure with a little creativity we could think of  
others. The issue is that <img> and <embed> do not really fit in the  
new language envisioned by HTML5. The best way to send that message  
is to drop those elements (or not add <embed>) and provide a new  
element for the future.

Take care,
Received on Tuesday, 26 June 2007 10:26:44 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:22 UTC