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

[Tab Atkins Jr.]

On Wed, Aug 4, 2010 at 7:25 PM, Bjartur Thorlacius <svartman95 at gmail.com> 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).

If this is useful, browsers can do it today.  @src and @href are
consistent in having their values be urls.


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

I'll note, though, that that isn't a very useful pattern for users in
the first place.  Most users won't have any idea what to do with a
video file, especially if it doesn't come with an identifying
extension.


> In fact, having the ability to follow this link is useful even though
> my browser supports <video>. But that's an UI issue.

Does your browser somehow not offer an "Open Video in New Tab" or
similar option in the context menu?


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

I can assure you that you are a tiny, tiny minority.  Almost no one
wants the video resource itself, because almost no one understands
video playback, codecs, etc.  If they're lucky, the format is just
right and they can just doubleclick it to play it in Windows Media
Player.

Doing a Flash or similar fallback that still plays the video is
virtually always the best choice for the user.


>> >     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 understand what either of these examples could possibly mean.
What is the charset of a video?  Why are you trying to use <video> to
show an image?


> I don't need to know the duration of an unanimated PNG.

Correct, so why are you using <video>?  If you want image fallback,
agitate for a solution to solve that problem.  Overloading <video>
isn't a good idea.


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

What media do you want to do fallback on?  audio and video are already
covered.  Images aren't, but I think the image space is pretty stable.
 If we have codec fights in the future surrounding images, we can
solve the problem then.

~TJ