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

Re: [whatwg] Video proposals

From: Benoit Piette <benoit.piette@gmail.com>
Date: Mon, 26 Mar 2007 07:59:14 -0400
Message-ID: <ecc676290703260459g2159fagc56b290cf738cc5f@mail.gmail.com>
To: public-html@w3.org
Cc: "WHAT Working Group Mailing List" <whatwg@whatwg.org>
Another thing I like about the <video> proposal apart from the consistent
API across browsers is that controls buttons could be generated by the
browser, which would leed to a consistent user interface within the browser.
This would be good for usability. Same with <audio>. I don't think those two
tags would replace <object> though .<video> and<audio> would be a simpler
way to do 80% of the needs of video / audio integration. I would be happy to
use <object> for a more complex need.

In the same train of thought, a <document> tag might be useful. I always
found anoying that for many embeded documents (word or pdf) you would have a
second user interface that have similar functionnality to the web browser
(ex: search within a document). Something like <document src=""
type="application/ms-word" />. Having a consistent API and consistent user
interface for an embeded document would be certainly useful. Imagine a
consitent interface (user and API) for an embeded word document, a pdf, or
even an editable content / controls for a CMS, wiki or a blog... Of course,
creating an API that can edit both a PDF and a Word document is something
daunting to say the least... But something that could be useful for simple
content creation (like in a simple CMS, blog or wiki, something that can
actualy generate valid HTML!) and general document embedding for viewing
might be possible.

There is a thing that concern's me though is that this is coming close to
compound documents.

-Benoit Piette

2007/3/25, Matthew Ratzloff <matt@builtfromsource.com>:
>
>
> I didn't think I was crediting <object> with that simplification, since
> they were both <object> tags... :-)
>
> The idea is that it should work the same across all browsers.  The format
> (MP3) was just an example to illustrate my point.  You shouldn't have 3
> different ways of specifying plug-ins, and it would be nice if extremely
> common file types (when not encumbered my patents) had native players,
> which the user could then override if they preferred to do so.
>
> If, as some suggest, we need a new element (such as <audio>) in order for
> every browser to start fresh and handle it in the same way, then fine.
>
> -Matt
>
> On Sun, March 25, 2007 4:49 pm, Maciej Stachowiak wrote:
> > I don't think you can credit <object> for the simplification that
> > results when you replace something that works across many browsers
> > with something that doesn't.
> >
> > On Mar 18, 2007, at 4:21 PM, Matthew Ratzloff wrote:
> >> "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>
>
>
>
Received on Tuesday, 27 March 2007 04:18:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2007 04:19:43 GMT