[whatwg] Fw: Feature Request: Media Elements as Targets for Links

Sorry, forgot to include list.

Date: Mon, 26 Nov 2012 21:09:01 +0100
From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Subject: Re: [whatwg] Feature Request: Media Elements as Targets for
Links


Silvia Pfeiffer <silviapfeiffer1@gmail.com> schrieb am Mon, 26 Nov 2012
12:17:34 +1100:

> […]
>
> What is currently possible is  <a href="#episode1" target="audio">When
> Alice mentioned Bob</a> and doing the time offsetting in JavaScript,
> either by changing the currentSrc to something like
> "episode1.oga#t=01:23" or by setting the currentTime to 83.

I do something like that already in redokast.

> […]
> 
> I would support introduction of a standard attribute for this. Maybe
> something like @mediafrag="t=01:23" on <a> elements would be really
> useful and can be converted by browsers to be added to a <video> or
> <audio> element currentSrc if the <a> links to the @id of a media
> element.
>
> The biggest problem that I see, however, is that you really want the
> URL of the Web page be changed to reflect the time offset status of
> the media resource, e.g. http://example.com/AliceAndBobVideo.html ->
> http://example.com/AliceAndBobVideo.html#t=01:23 . In this way people
> can cut-and-paste the URL and share it with the time offset intact.

I think that solving the problem on the URL level would be much more
useful than requiring an additional attribute.

Podcasters from Germany calling themselves Podlove initiative are
planning to re-use fragment identifiers and a part of media fragments
already, but AFAIK there is no implementation of their proposal.
<http://podlove.org/deep-link/>

Your example of <http://example.org/podcast.html#episode1&t=01:23>
seems very usable to me – it would make it possible to have multiple
media elements on a page and target them accurately. Maybe one should
use another character than the ampersand for compatibility reasons, but
that is an empiric question that looking at data can solve.

> […]
>
> I don't think there is a simple way to achieve this with the way that
> the Web currently works because the interpretation of the fragment
> parameters of the HTML page are controlled by the Web application
> where they don't apply to an @id attribute on the page. We would need
> to change the way in which URL fragments are interpreted by Web pages.

Maybe I am misunderstanding you here, but I think the fragment
identifier abuse by JavaScript authors can be of use here – it would
allow for a simple polyfill that could quickly propagate use and
knowledge of such a feature before someone else invents yet another
slightly incompatible way of doing the same thing.


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

Received on Tuesday, 27 November 2012 00:11:38 UTC