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

2012-11-27 Thread Silvia Pfeiffer
On Tue, Nov 27, 2012 at 11:10 AM, Nils Dagsson Moskopp <
n...@dieweltistgarnichtso.net> wrote:

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

Nobody will stop you from writing a JS library to interpret the pattern of <
http://example.org/podcast.html#episode1&t=01:23> in the way that you
expect it to be interpreted. However, IIUC, browsers will interpret this as
an offset to an element on the html page that has an id of
id="episode1&t=01:23". If such an element happens to exist, the page will
scroll to it. You can additionally run the JS, but that won't stop the page
from getting scrolled.

Fortunately, it's not very likely that HTML pages have an element with such
an @id value, so a polyfill as you describe could indeed be very useful.

Regards,
Silvia.


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

2012-11-26 Thread Nils Dagsson Moskopp
Sorry, forgot to include list.

Date: Mon, 26 Nov 2012 21:09:01 +0100
From: Nils Dagsson Moskopp 
To: Silvia Pfeiffer 
Subject: Re: [whatwg] Feature Request: Media Elements as Targets for
Links


Silvia Pfeiffer  schrieb am Mon, 26 Nov 2012
12:17:34 +1100:

> […]
>
> What is currently possible is  When
> Alice mentioned Bob 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  elements would be really
> useful and can be converted by browsers to be added to a  or
>  element currentSrc if the  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.


Your example of 
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



-- 
Nils Dagsson Moskopp // erlehmann