- From: Benoit Piette <benoit.piette@gmail.com>
- Date: Mon, 26 Mar 2007 07:59:14 -0400
- To: public-html@w3.org
- Cc: "WHAT Working Group Mailing List" <whatwg@whatwg.org>
- Message-ID: <ecc676290703260459g2159fagc56b290cf738cc5f@mail.gmail.com>
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 UTC