- From: Robert Burns <rob@robburns.com>
- Date: Tue, 26 Jun 2007 05:26:15 -0500
- To: Anne van Kesteren <annevk@opera.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
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: <http://lists.w3.org/Archives/Public/public-html/2007Jun/0801.html> 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, Rob
Received on Tuesday, 26 June 2007 10:26:44 UTC