[whatwg] <video> element feedback

[Gareth Hay]

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.