W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

Re: [whatwg] Video proposals

From: Matthew Ratzloff <matt@builtfromsource.com>
Date: Sun, 18 Mar 2007 16:21:05 -0700 (PDT)
Message-ID: <50002.24.113.147.1.1174260065.squirrel@webmail.builtfromsource.com>
To: public-html@w3.org
Cc: "WHAT Working Group Mailing List" <whatwg@whatwg.org>

On Sun, March 18, 2007 12:38 pm, Laurens Holst wrote:
> 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.

I agree.  Instead of dealing with a myriad of different tags, why not say
that HTML deals with two things: text and everything else (i.e., embedded
content).  Embedded content is handled universally with the <object>
element.

Audio and video should be handled within the browser natively, although it
should be possible to easily override the default player on the user side.
 I don't know which formats are open and which aren't, though.

Here's a look at five types of media and use cases for each.  The first is
how you might use HTML today.  The second is how I would like to be able
to use it.  (Some of these don't allow self-closing tags, but I don't want
to look up which ones--I think all tags should be allowed to be
self-closing, in any event.  In cases where tags define attributes like
width, height, etc., I think this should be deferred to CSS.)

Images
----------------------------
Simple use case:
<img src="my-picture.jpg />
vs.
<object src="my-picture.jpg" />

Slightly more complex use case:
<img src="my-picture.jpg alt="This is my picture" />
vs.
<object src="my-picture.jpg">This is my picture</object>

Here, Object's fallback mechanism makes more sense than Img's "alt"
attribute, which provides an identical method of handling descriptions but
seems outdated in comparison.

Audio
----------------------------
There are a variety of awkward ways to embed audio into a document.

Simple use case:
???
vs.
<object src="my-sound.mp3" />

"Slightly" more complex use case:
<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"
        codebase="http://www.apple.com/qtactivex/qtplugin.cab"
        width="200"
        height="16">
    <param name="src" value="my-audio.mp3" />
    <param name="autoplay" value="true" />
    <param name="pluginspage"
value="http://www.apple.com/quicktime/download/" />
    <param name="controller" value="true" />
    <!--[if !IE]> <-->
    <object data="my-audio.mp3" type="video/quicktime">
        <param name="pluginurl"
value="http://www.apple.com/quicktime/download/" />
        <param name="controller" value="true" />
    </object>
    <!--> <![endif]-->
    This is a description of my audio file.
</object>
vs.
<object src="my-audio.mp3">
    <param name="autoplay" value="true" />
    This is a description of my audio file.
</object>

(Like most of the rest of the world, I hate background music on pages.  I
would actually prefer that it was a visible control on the page instead. 
Should background music be deemed necessary to retain, it could be done
with a parameter.)

Video
----------------------------
Simple use case:
???
vs.
<object src="my-video.mpg" />

"Slightly" more complex use case:
<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"
        codebase="http://www.apple.com/qtactivex/qtplugin.cab"
        height="195"
        width="340">
    <param name="src" value="my-video.mov">
    <param name="autoplay" value="true">
    <param name="controller" value="true">
    <embed height="195" width="340" align="left" src="my-video.mov"
autoplay="true" controller="true">
        <noembed>This is a description of my video file.</noembed>
    </embed>
</object>
vs.
<object src="my-video.mov">
    <param name="codebase"
value="http://www.apple.com/qtactivex/qtplugin.cab" />
    <param name="autoplay" value="true" />
    This is a description of my video file.
</object>

If there were some way to switch the default for "controller" to true,
that would make more sense.

Iframe
----------------------------
Simple use case:
<iframe src="my-page.html" />
vs.
<object src="my-page.html" />

Slightly more complex use case:
<iframe src="my-page.html"
        longdesc="my-page-desc.html"
        scrolling="auto" />
vs.
<object src="my-page.html">
    <param name="scrolling" value="auto" />
    This is my page description.  No external description required.
</object>

Applet
----------------------------
Simple use case:
<applet code="my-applet.class" />
vs.
<object code="my-applet.class" />

Slightly more complex use case:
<applet codebase="/applets"
	code="my-applet.class"
        width="400"
        height="320">
    <param name="text" value="This is my applet">
    This is my applet description, and maybe a note on downloading Java.
</applet>
vs.
<object src="my-applet.class">
    <param name="codebase" value="/applets" />
    <param name="text" value="This is my applet" />
    This is my applet description, and maybe a note on downloading the Sun
JRE.
</object>

In all cases, Object seems more obvious and more suited for the task of
embedding content than the variety of different tags that currently exist.

-Matt
Received on Sunday, 18 March 2007 23:21:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 18 March 2007 23:21:30 GMT