[whatwg] <INCLUDE> and links with @rel=embed
ian at hixie.ch
Thu Aug 26 10:26:14 PDT 2010
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
> 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>.
> 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.
> <source src=f.utf8 charset=utf8>
> <source src=f.latin1 charset=latin1>
> <source src=img.png type="image/png">
> <source src=img.svg type="image/svg+xml">
> 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
<object data=img.png type="image/png">
<object data=img.svg type="image/svg+xml">
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg