This is a bit of a sideways step here, but why not make tags reflect
MIME type,
e.g.
<image> image/*
<video> video/*
<application> application/*
<audio> audio/*
That way we have a clear identification of what is going to be in the
tag, API's can be tailored sufficiently for each one.
Each tag can have appropriate fallback also.
Just a thought, and it gets us out of the <object> hole.
Gaz
On 20 Mar 2007, at 23:42, Nicholas Shanks wrote:
On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote:
Ian Hickson wrote:
However, I think if <object> is so widely derided by everyone,
than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't
think we can
actually do it given the large amount of legacy content, e.g.
tutorials
for how to embed flash which encourage use of <object>.
In the unlikely event that <object> be in any way discouraged, can we
ensure we allow element level fallback content for <img> (or some
replacement element) as opposed to the alt attributes we're currently
lumbered with and the longdesc attribute that WHATWG has done away
with?
I asked for the resurrection of HTML+'s <image>fallback</image>
element last month.
The reasons I cited were exactly the same as the reasons being
given now in favour of the <video> element, however I was told
(paraphrasing) "Why bother, you can just use <object>" and "That
would break existing implementations" (though no such
implementations were cited).
So again, I ask for an <image> element to replace <img>. Benefits
include:
• As <video> would cater for video/* MIME types, <image> would
cater for image/*
• The alt and longdesc attributes can be part of the fallback
content, allowing markup.
• You don't have to provide a type attribute and match on: object
[type^="image/"]
• and more…
- Nicholas.
