W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] <source>

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 13 Oct 2007 01:00:01 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0710130055400.19595@hixie.dreamhostps.com>
On Fri, 23 Mar 2007, Anne van Kesteren wrote:
>
> I don't really like this element. The name is confusing especially with 
> an attribute named src="". It also introduces yet another void element, 
> can't we just reuse <param>? The value="" attribute of <param> would 
> point to a resource and the type="" attribute (which has been dropped) 
> would be added back. I suppose it might be considered overloading, but 
> in a way we're just defining how the processing model of a plugin could 
> also work...

I actually tried <param> at some point, but having <param> do double duty 
with two sets of attributes was quite confusing.


On Fri, 23 Mar 2007, Maciej Stachowiak wrote:
> 
> So to be sure I understand your proposal, you're suggesting that instead of
> 
> <source type="audio/mpeg" src="mysong.mp3">
> 
> You'd say:
> 
> <param type="audio/mpeg" value="mysong.mp3">
> 
> I think the latter is a lot less clear. Also, <param> would end up 
> having two uses which differ in the following ways:
> 
> 1) Do you have type/value or name/value as allowed attributes?
> 2) Which object can contain it?
> 3) Do you process all of them, or only the first one to match some criteria?
> 
> They would effectively be different elements since the processing model and
> criteria for a valid document would differ.

Indeed.


> I agree the repetition of source/src is a little weird. Another 
> possibility that was discussed is to still have the type attribute on 
> audio/video, and let it be the first item considered for fallback, and 
> name the new element something like <alt> so you could write:
> 
> <audio type="audio/mpeg" src="mysong.mp3">
>   <alt type="audio/x-aiff" src="mysong.aif">
>   <alt type="audio/wav" src="mysong.wav">
> </audio>
> 
> Or, if you want symmetry:
> 
> <audio>
>   <alt type="audio/mpeg" src="mysong.mp3">
>   <alt type="audio/x-aiff" src="mysong.aif">
>   <alt type="audio/wav" src="mysong.wav">
> </audio>

I think that would be confusing due to its similarity yet difference with 
<img alt="">.


> One nice thing about using <alt> is that it makes it more clear that 
> only one source will apply. Another nice thing about it is that it could 
> more naturally be extended to supporting playlists, where a single 
> element is declaratively set up to play multiple media files (this is 
> better than using script for this, since you can start buffering the 
> second and subsequent files early).
> 
> <audio>
>     <li>
>       <alt type="audio/mpeg" src="mysong.mp3">
>       <alt type="audio/x-aiff" src="mysong.aif">
>       <alt type="audio/wav" src="mysong.wav">
>     </li>
>     <li>
>       <alt type="audio/mpeg" src="othersong.mp3">
>       <alt type="audio/x-aiff" src="othersong.aif">
>       <alt type="audio/wav" src="othersong.wav">
>     </li>
> </audio>
> 
> Perhaps reusing <li> like that is too cute and there should be some more 
> specific element for a playlist item. But I guess you could use this 
> syntax with <source> just as well.

Indeed. I'm not convinced this is much better. :-)


On Fri, 23 Mar 2007, Dean Edwards wrote:
> 
> Why not call the element <content> instead of <source>? That way the src 
> and type attributes make more sense.

I'm not convinced it would be that much better, and I'd prefer if we kept 
the name "content" available for other things later.


On Fri, 23 Mar 2007, Anne van Kesteren wrote:
> 
> By the way, people also suggested using an external file to contain the 
> playlist.

That makes sense to me.


On Sat, 24 Mar 2007, Alexey Feldgendler wrote:
> 
> If you put it inside <object> fallback content, it will be misunderstood 
> by the current browsers as pertaining to the <object>.

That is indeed another reason to avoid <param>; though why you'd put 
<video> inside <object> instead of the other way around, I'm not sure.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 12 October 2007 18:00:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC