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

[Ian Hickson]

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?


> Isn't interactive content not important enaugh? What about text? What if 
> one want's to link to interactive maps? svg at src? <a class="embed"..> 
> with .embed {content: url(attr(href)) }? AFAIK CSS doesn't support it, 
> and if it does <a rel="embed"..> could be used as well, even without 
> explicit browser support.
>
> Also someone wrote that one should use <object> for media-types that 
> aren't supported in HTML yet. If you insist on keeping <video> and 
> <audio>, think of this as a way for second-class media-types WHATWG 
> hasn't approved/haven't been implemented to use some of the features of 
> <video> and <audio>.

I don't understand these paragraphs at all.


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.


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


I didn't really follow the rest of your e-mail. It would be helpful if you 
could construct your feedback in the form of a problem faced by users, 
rather than in the form of a proposed solution. This would enable the 
proposal to be properly evaluated.


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?

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