Sorry, forgot to include list. Date: Mon, 26 Nov 2012 21:09:01 +0100 From: Nils Dagsson Moskopp <n...@dieweltistgarnichtso.net> To: Silvia Pfeiffer <silviapfeiff...@gmail.com> Subject: Re: [whatwg] Feature Request: Media Elements as Targets for Links
Silvia Pfeiffer <silviapfeiff...@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>