Re: handling fallback content for still images

On Jul 2, 2007, at 11:33 PM, Maciej Stachowiak wrote:
> As far as authors go, I don't think it's just a matter of whether  
> one option is confusing. <video src="foo.mp4"> is more intuitive  
> than <object type="video/mpeg4" data="foo.mp4"> and more clearly  
> expresses the semantic of an embedded video. "video" is clearly  
> more of a first-class concept than "object of type video". I don't  
> see any reason why the object version would be better for authors,  
> novice or otherwise, and a distinguished element way better for  
> data mining tools once widely deployed (they don't have to guess at  
> the magic strings in an <object> that would result in it being a  
> video).

A few more responses worth posting on this. What I'm looking for is  
interoperability for:
<object data="foo.mp4">

where declaring the type is not necessary. The UA can query the  
server for the type. The initial standby presentation would come from  
fallback or CSS (i.e., height, width, etc) and adjusted, if  
necessary, as resources were loaded.

As for data mining, I would just expect the data-mining application  
to load the resource  referenced by data= and from the server headers  
or from the resource itself mine any other data of interest. Perhaps  
that requires some more work, but getting the mime-type from a server  
shouldn't be all that network intensive.

As for adding <video>, <audio>, <canvas>, <embed>, <applet>,  
<picture>, etc. to create more explicit semantic distinctions (other  
than using <object>@type), I'm not convinced either way. I can see  
how it could be useful. I can also see how it could quickly get out  
of hand and provides no more information than simply declaring the  
@type. I guess I'm saying I can see it both ways. However, I can't  
see how <video> might be justified but <picture> which would replace  
a problematic element like <img> would not be justified.

Take care,
Rob

Received on Tuesday, 3 July 2007 05:28:11 UTC