Re: <video> element feedback

Ian Hickson schreef:
> On Wed, 21 Mar 2007, Laurens Holst wrote:
>   
>>> I see the need for a standalone element now.
>>>       
>> Why? There is no overloading going on anywhere.
>>     
>
> <object> right now is overloaded to do at least four things:
>
>    * inline images
>    * plugins
>    * nested browsing contexts (iframes)
>    * fallback container
>
> ...each of which has very distinct behaviour

I really don’t see how those are different, except for fallback content. 
Which <video> happens to have as well, so that remains.

> (e.g. whether it has a scripting context, whether it shrinkwraps, whether it is replaced or not;
>   

That is implemented today, so it is possible. Also, I think these 
differences only apply to fallback content vs. other content…? The 
problem here is: I don’t know. Nobody seems to know, except for you. 
Hence, see my last comment in this mail.

> whether it invokes an external program,

Why does that matter? Mozilla does this with SVG and it works. I don’t 
think semantically you should make a difference whether something is 
implemented natively or externally through a plugin architecture (as 
<video> currently seems to do).

> what kind of decoder it uses).
>   

Switching decoder based on MIME type is extremely common, just look at 
images.

> Adding a fifth (inline video with an API) would increase the complexity 
> yet again.
>   

There is no ‘adding’. Video is already embedded via <object>, today. 
Also, having video via <object> is no different from having images, so I 
don’t see why you consider it a separate thing.

> <object> is *very badly* implemented. It has been a decade since <object> 
> was first created and browsers STILL don't do it right in all cases (or 
> even in most cases, frankly). Adding more complexity to such a disaster 
> zone is bad design.
>   

If the existing problems with <object> are so severe that it can’t be 
reused (which I somehow doubt), create a new element where you do it 
right. However, don’t start separating it out into separate tags.

You are using one argument, current implementation of object is broken 
in several ways, to promote another idea, splitting up what is perceived 
as different types of media into separate tags.

>> First of all, if one would just take a practical approach and think in 
>> terms of solutions instead of impossibilities, you could simply have a 
>> property HTMLObject.objectController, which then gets you an object 
>> specific to the ‘media group’.
>>     
>
> It wouldn't be "simply", though. You'd need to define how to determine 
> what the media group is, you'd need to define how to change from one type 
> to another, you'd need to have browsers implement all this on top of all 
> their existing bugs -- sometimes, it's just better to keep things 
> separate, even if they seem like they could be abstracted out into one 
> concept. We can't ignore our past experiences in designing HTML5.
>   

That’s just nonsense. It is generic. Create drawing object, retrieve 
source, check MIME type, invoke renderer depending on MIME type with 
drawing object as parameter. Really, what is so difficult here.

I find this argument really awkward. Especially since you’re saying that 
anything that doesn’t fall in the <video> category *or* is not-natively 
implemented could still use <object>. So apparantly it does work ‘good 
enough’ after all.

And it does. It has the functionality it needs to have. The main problem 
<object> seems to have is that there is lack of consistency across 
browsers and object types. Enter specification, and combined effort to 
fix it.

It feels like people are doing their best to think difficult here, in 
order to promote some rather arbitrary changes.

You keep saying that <object> is a huge bag of problems. It would help 
if someone who knows exactly what aspects of <object> are implemented 
badly (you) would instead of proactively making changes to a 
specification on his own judgement with input from others, create a 
document that clearly describes the issues with <object> and what is 
implemented consistently and where browser implementations differ. That 
way everyone can consider what is wrong exactly, and how it can be fixed.

Because without that, it is really just a guessing game. For a change 
like this, there needs to be a clear overview of what is wrong first. 
Otherwise, it is just people saying you should do this or that, and you 
responding overloaded this browser authors that, and there is no real 
way to verify that what you say is correct, to make a general estimate 
of how big the problem is that is tried to be fixed, to provide 
alternative suggestions, and to judge whether what you say is wrong 
really warrants these changes (personally, I think not). I would like to 
see a more structured approach, and frankly, a more open approach.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.