Re: [whatwg] Video proposals

Håkon Wium Lie schreef:
>  > Correct me if I$,1rym wrong, but I don$,1ryt think there is a single reason why 
>  > the browser couldn$,1ryt play back content embedded with an <object> tag, 
>  > like it$,1rys supposed to. What$,1rys more, that would allow it to work with 
>  > existing web content, too. Plus it$,1rys backwards compatible.
>
> There are two main reasons for using <video> instead of <object>. The
> first is that <object> is broken in the sense that its interoperbility
> score is low. People have been trying to fix it ever since it was
> created, but their efforts are unlikely to succeed.
>   

One of the main reasons that <object> is still broken on the web and why 
<embed> needs to be used is Mozilla; their plugin finder doesn’t work 
with <object>. Other than that, it works, as far as I know. Sorta. At 
least it is more backwards- and forwards-compatible than <video> is. One 
thing that browsers certainly can do is hook into the <object> tag to 
provide native rendering instead of letting a plugin do it. Also avoids 
the Eolas patent, I bet :).

Besides, isn’t the WHATWG also about fixing things that are somewhat 
broken? Otherwise, might as well give up on e.g. contentEditable and 
create a new element/attribute for that too…

> The second is that 'video' is a much better name for video content
> than 'object' or 'embed'; it's intuitive and semantic. 'object' may
> have a minimalistic charm, but if you know something is video (or
> audio, or ...) it's easier to give it a video (or audio ...) icon, or
> not download it if the browser doesn't have video capabilities. Also,
> it can more easily be styled. For example:
>
>   video { display: none }
>
> If we opted for generic names, we could write our web paged only using
> <div> elements for headlines and paragraphs. Having <h1>, <h2>, <p>,
> <blockquote> etc. enables us to do interesting stuff with the content;
> styling it, searching it, adding sematics.
>   

But then what’s next. <sound>? <presentation>? <flash>? (Oh wait, we 
have bgsound already, and iframe too.) In Anne’s blog people mention a 
<media> element, which I would agree with because making a distinction 
between video and audio doesn’t really grok it with me; but that’s the 
whole point in the first place; media’s still too specific.

I do not think it’s very important semantics we’re presenting here. If 
you look at the semantic elements in HTML, pretty much all of them have 
a practical use; various for typographical purposes, element like dfn to 
generate indices, etc. With <video>, I do not really see any practical 
use [that is not also offered by object]. From my perspective, any kind 
of medium should be treated the same and not be cast in separate ‘boxes’ 
of stills, animated frames (+ sound), sound, interactive frames (flash, 
presentations), text, etc.

For example, why should these be considered ‘different’: (The <figure> 
element is name kind of awkward…)

<figure>
   <audio src="podcast1.mp3" />
   <label>My first podcast</label>
</figure>

Or:

<figure>
   <text src="flowerpoem.txt" />
   <label>A poem about flowers</label>
</figure>

Ultimately, what specific kind of medium is inserted in that figure 
doesn’t really matter, I think. You provided that hide-video CSS, but it 
seems a gimmick to me, I don’t really see a practical use for specifying 
that information in the document.

> There is a cost associated with creating new elements. It shouldn't be
> done easily. I believe <video> and <audio> have proven themselves
> worthy, though.
>   

Eh, how exactly have <video> and <audio> proven themselves worthy? I 
think you can only say that in hindsight.

Well anyway, I don’t see it yet. It’s not only the ‘cost’ in terms of 
losing backwards compatibility, etc. that should be considered, but also 
whether it is architecturally sound and whether there is not existing 
functionality that it can be built upon. I don’t see a big deeper 
thought behind this in terms of design and architecture, but primarily a 
practical one (that <object> does not provide Javascript API). I do see 
one in the path that was e.g. explored in XHTML2, where they even went 
as far as to entirely remove the need for the object tag. A little too 
much for the current web, but that didn’t make the idea any less nice.

So now we have <img> and <bgsound> and <audio> and <iframe> and <video> 
and <object> and <embed> and <applet>, and I’m sure I forgot one or two 
browser-specific elements :). There are already several duplicates in 
there, and none of them is re-used even if they specifically were 
designed for the purpose like <object> is. It’s a mess, and this idea is 
only adding to it. Wasn’t the mantra reuse and be compatible, and what 
the element is called doesn’t matter as long as it works (otherwise, why 
do we still have <h1> instead of <h> and <hr> instead of <separator>)?

In the end, you would end up with 8 (!) elements that basically all do 
the same, which is embedding an object of different types of media, and 
given that the beast is now loose, I’m sure more will follow. Macromedia 
would surely object it’s being treated as a second-class citizen because 
flash doesn’t fit in any of the primary categories. <flash> seems 
unlikely, but <interactive> is surely next.

But what if the flash does not contain any interactive elements? Try to 
explain the authors to use <video> instead? Using that probably wouldn’t 
work. Also, Youtube Flash-content does contain interactive elements, and 
many Flash-animations also have a ‘start’-button of some kind. Does that 
qualify as interactive, or as video (the latter being the nature of the 
content, but not the technical nature)?

Anyway, I think it’s a bad idea to go this way.


~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.