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

Forwarding a message 'cause I forgot to CC WHATWG so it got stuck in moderation.

---------- Forwarded message ----------
From: bjartur <svartman95@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.

Received on Wednesday, 19 May 2010 04:56:31 UTC