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

[Silvia Pfeiffer]

On Wed, May 19, 2010 at 4:38 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, May 18, 2010 at 11:20 AM, bjartur <svartman95 at gmail.com> wrote:
>> --------
>>
>> First of all I think we should use <a rel="embed" href="uri-ref"> instead of <source>. I'm not aware of previous proposals of that on this list. Feel free to provide links if it's already been proposed.
>
> That's syntax; like I said, syntax has never been a problem.
>
>> Second, all the responses I've seen so far have been along the lines of "it's the HTML5 way" (implying it's more of an XHTML 1 way, or [insert unfashionable tech here] way) or that video is so important that it deserves first-class treatment, and for the sake of completeness <audio> has to be included as well (though interactive content, text and 3D models don't deserve to be "first-class").
>
> Then you haven't looked into it enough.
>
> The reason why a single inclusive multimedia element is bad is because
> different types of media have different requirements.  The javascript
> API that makes sense to expose for audio is different than the one you
> want to expose for video.  Video needs subtitles, audio doesn't (it
> needs transcription, but that's something different entirely, and can
> be handled with a simple link).  Etc.
>
> Theoretically, you can swap out what type of api you expose based on
> what the currently active media is.  In practice, that's a horrible
> idea and no one wants to try to do it again.  It's even harder to try
> and sort out multiple additional resources that should be attached to
> particular media, but not others, like subtitle tracks that should be
> attached to a video but shouldn't be exposed to an audio, etc.

I disagree with that last statement - audio does need subtitle-like
constructs, too. For example, if you want lyrics to be displayed in
sync with the audio, then it can be done with the same construct as
captions or subtitles work for video.


But I do agree with the need to keep audio and video as different
resource types with their own APIs. This far, in the life of HTML,
text has been the main driver of the Web, interspersed with images and
formatting instructions for text. By treating video and audio as their
own elements in their own right, we can finally move on into a world
of multimedia where audio and video can have their own formatting
instructions and their own JavaScript API - none of this would e
possible by leaving them hidden in an <a> element, or even in an
<embed> element, where it is totally unclear what the content will be.

Bjartur, I do wonder what exactly your motivation is in suggesting
audio and video be degraded back to undetermined embedded outside
content. What would be won by going back to that way? Lots will be
lost though - if you have ever developed a Website with Flash video,
you will know how much work is involved in creating a specific
JavaScript API to the Flash video player so that you can have some
interaction between the rest of the Webpage and the video or audio
resource. We honestly don't ever want to go back to that way.

Cheers,
Silvia.