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

[Silvia Pfeiffer]

On Wed, May 19, 2010 at 9:56 PM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> Forwarding a message 'cause I forgot to CC WHATWG so it got stuck in moderation.
>
> ---------- Forwarded message ----------
> From: bjartur <svartman95 at gmail.com>
> Date: Tue, 18 May 2010 21:20:30 +0000
> Subject: Re: [whatwg] <INCLUDE> and links with @rel=embed
> To: "Tab Atkins Jr." <jackalmage at gmail.com>
>
> --------
>
>        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>.
>
>        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 also propose using normal backwards compatible <a> elements with
> another relation (=embed) rather a new <source> element as the use
> case of <a> (linking to resources) seems to cover multimedia resources
> as well, and because it's more backwards compatible than a brand new
> element -- in fact it can remove the need to add a fallback link to
> content that would otherwise be required to be added for unsupporting
> browsers, or even worse: forgotten (though authors will still be able
> to add other fallback content if they so desire).
>
>        At last, I propose not forbidding usage of @rel=embed outside of
> media elements.
>
> -------
>
> <a> is more widely implemented than <source>, links to multimedia are
> also links, so it seems to me that <a> should be used. Otherwise you
> have to readd attributes like hreflang, charset, type, etc to an
> element with almost exactly the same meaning, but slightly different
> behaviour. Using source is like adding a new element for paragraphs
> that should be colored, rather than using <p>.
>
>>The source element allows authors to specify multiple alternative media resources for media elements. It does not represent anything on its own.
> I want to change this to allow authors to specify alternative
> resources. And possibly to make it represent the linked media itself
> if it appears on itself (not inside a media element) and/or doesn't
> have the alternate keyword in @rel.
>
> <source> vs <a rel="embedded"> aside, I don't see the cost of
> introducing a new media element that has just exposes the interface
> HTMLMediaElement so resources that don't need audio or video specific
> scripting interfaces and/or when such interfaces haven't been
> standardized WHATWG/W3C for the media in question can still embed
> multiple alternative <a rel="embedded">s, <track>s, etc.
>
> Silvia,
> I don't understand what you do mean when you say that audio and
> video need to be seperate elements so they can be formatted
> properly (the reason possibly being that I've never coded in Flash).
> But it's not "totally unclear what the content will be" if the author
> uses proper metadata (which can be mandated by the spec).
> Embedding metadata about external resources in tag names
> is abusing their purpose. It's especially bad when you don't even
> provide one element per MIME-type (like <model> and <text>).
>
>> 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.
> I'm not writing that you must throw <audio> and <video> out of the
> window. You should add a new element; <include>. That element
> will be a media element, might expose HTMLMediaElement (if it's
> not deemed to audio and video specific) or some subset/superset
> thereof. It will not put as much restrictions on what type of media
> may be linked to with it (and in specific: not require that media to be
> of certain MIME-type). If <audio> and <video> can't be generalized
> to expose some interfaces based on what the underlying media is
> capable of or throw exceptions when scripts try to do impossible things
> (like playing static/non-linear media or media that hasn't been loaded
> yet) than keep <audio> and <video>. Just don't make the features of
> those elements that don't require media specific scripting interfaces,
> like multiple alternative resources to those "first-class" media types.
>
> Allowing scripting "second-class" media types will be harder, as that will
> require telling scripts whether the media is seekable, play/pause able,
> possibly rotateable (though that may be a part of CSS), etc. If you also
> make the @type attribute optional, this has to be able to change when
> the type of media is established (and of course if the media fails to load).
>
> Even a simple use case like linking to the GPL and translations thereof
> isn't served well by the current spec. But using <include> or <media>
> it becomes a nobrainer to allow the user-agent to choose the preferred
> language and format or choose to index all of them or just the English
> HTML version, or do whatever it wants with this info.
>
> This can be used as payload/entity-body of a HTTP 300 and allows a UA
> to semantically understand all metadata embeddad in the document like
> @hreflang, @type, @charset and more, even for content that isn't video
> or audio. TSV would probably be better suited, but HTML should be capable
> of this as a hypertext markup language.
>

This all seems way too abstract - I think you are arguing for the
wrong case with the right reasons. But in any case, you should try and
make an example markup with your ideas and check if it really gives
you what you think it will. I have sincere doubts.

Regards,
Silvia.