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

> 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).

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.

> 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'.

> > 	What I'm trying to write is that not all browsers support
> > JavaScript, not all pages must be able to control playback more than
> > play, pause, seek etc and that a mechanism for linking to files and
> > alternative encodings thereof semantically. Currently, that seems to be
> > only possible with video and audio. But if you create a media element
> > that adds no extra interface, you get this for all other types as well
> > (albeit with a lesser scripting interface). Although the <include>
> > element won't be as good integration point between one media and
> > scripts, it will have a standard interface somewhat applicable to many
> > medias/mediums and at least provide something to all medias, versus
> > (close to) nothing.
> 
> I'm not sure I follow. 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'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.

> 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.

Received on Wednesday, 4 August 2010 19:25:53 UTC