[whatwg] <INCLUDE> and links with @rel=embed

[Ian Hickson]

On Thu, 5 Aug 2010, Bjartur Thorlacius wrote:
> > On Tue, 18 May 2010, bjartur wrote:
> > >
> > > First of all I think we should use <a rel="embed" href="uri-ref"> 
> > > instead of <source>.
> > 
> > What problem would this solve?
> 
> It would tell UAs that don't implement HTML 5 that the value of @href is 
> an URI. Then it can provide means for the user to retrieve the 
> identified resource (and do something useful with it).

Surely the kind of URL is already fully given by the scheme, making this 
rather moot.


> For authors it would unnecessiate constructs such as (excerpt from spec):
> <video controls src="http://video.example.com/vids/315981">
>    <a href="http://video.example.com/vids/315981">View video</a>.
> </video>
> 
> In fact, having the ability to follow this link is useful even though
> my browser supports <video>. But that's an UI issue.

I don't understand how it would affect this.


> > On Wed, 19 May 2010, Bjartur Thorlacius wrote:
> > >
> > > 	Is the existing syntax backwards compatible? When using <A>, you
> > > get a nice link as fallback content automagically, not requiring any
> > > special workarounds by the content author. AFAICT you don't even get
> > > that when using a browser that doesn't support <audio> and <video>.
> > 
> > Indeed, with those you have to provide the fallback content (which could
> > e.g. be flash) as a descendant of the <audio>/<video> element.
>
> As a user of a browser that doesn't fully support <video> I'd prefer
> getting a hyperlink to the resource to a Flash program. Just sayin'.

Most authors would rather the user never knew there was a difference and 
just get the video, it seems.

 
> > If you're saying that we should also support other timed-based formats 
> > in the future even if they are not video, e.g. if you are saying we 
> > should support formats like SMIL, then there's no reason you can't do 
> > that with <video> itself. <video> really is just an API to time-based 
> > visual data, it doesn't have to be a sequence of bitmaps.
>
> Oh, the following quote confused me.
>
> > The video element is a media element whose media data is ostensibly 
> > video data

I picked the word "ostensibly" on purpose for that sentence. :-)


> I'm not just talking about SMIL. I'm talking about using a secondary 
> feature of media elements (the ability to link to multiple alternative 
> resources) even if the main feature (the API) is irrelevant.
> 
> <video>
> 	<source src=f.utf8 charset=utf8>
> 	<source src=f.latin1 charset=latin1>
> </video>
> <video>
> 	<source src=img.png type="image/png">
> 	<source src=img.svg type="image/svg+xml">
> </video>
> 
> I don't need to know the duration of an unanimated PNG.

Ah, yeah, that isn't supported. You can just use <object> for the image 
case:

   <object data=img.png type="image/png">
      <object data=img.svg type="image/svg+xml">
      </object>
   </object>

In the character encoding case, everyone supports UTF-8, so just use that.


> > On Wed, 19 May 2010, bjartur wrote:
> > >
> > > Yeah, maybe my crazy idealism and tendency to reuse existing things 
> > > don't mix up in this case. The main purpose of <video> and <audio> 
> > > is to create a scripting interface to online video. But they also 
> > > add new linking capabilities which should be available to any 
> > > content whatsoever.
> > 
> > I don't really see how. In what sense do they add new linking 
> > capabilities?
> 
> In the sense of multiple alternative (media) resources.
> 
> This could possibly be done with <object> but its fallback mechanism 
> seems inferior.

The <video> one is very specific to codecs and so forth; I don't think it 
would make sense to generalise it. <object> already handled it fine.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'