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

Can you provide an example markup and an example URL that you think will
solve your use case?

I'm asking because we don't use the name attribute any more in HTML5,
because we have the id attribute on all elements. Thus, it is always
possible to hyperlink directly to a video element using a hash on a URL and
the value of the id element. But I still wonder what you think is missing.

Regards,
Silvia.

On Sun, Nov 25, 2012 at 7:19 AM, Nils Dagsson Moskopp <
nils@dieweltistgarnichtso.net> wrote:

> Excuse me if I am doing something wrong by submitting this by mail. I
> am doing this for the first time, trying to fill in the template given
> at <http://wiki.whatwg.org/wiki/Problem_Solving> as good as I could.
>
> Use Case Description:
>
>   Linking to specific fragments of media is possible via media fragment
>   URIs [1]. However, it is not possible to apply a link to embedded
>   media declaratively, for example to link to a specific point in time
>   for a media element on a page.
>
>   [1] <http://www.w3.org/TR/media-frags/>
>
> - Current Limitations:
>
>   Linking to media using media fragment URIs changes browsing context.
>
> - Current Usage and Workarounds:
>
>   1. metavid (Videos of United States Congress) uses JavaScript, even
>   though they have CMML transcripts and SRT.
>
>   2. I have a podcast ”Warum nicht?“ generated by a software called
>   redokast. Annotations need JavaScript: Click on the timestamps.
>   <http://warumnicht.dieweltistgarnichtso.net/wn-15.html>
>   <https://github.com/erlehmann/redokast>
>
> - Benefits: Declarative markup would make referring to timed
>   annotations easier. Referring to a specific point in time in a podcast
>   on the same comments, for example, could be possible.
>
> Proposed Solutions:
>
> - My Solution:
>   Give HTML media elements a name attribut. Make them valid targets for
>   links with a target attribut.
>
>   - Processing Model:
>     Processing for media elements and the <a> element needs to change.
>
>     <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-hyperlink-target
> >
>     Change “The target attribute, if present, must be a valid browsing
>     context name or keyword. It gives the name of the browsing context
>     that will be used.” to “The target attribute, if present, must be a
>     valid browsing context name or keyword or the name of a media
>     element in the current browsing context. It gives the name of the
>     browsing context or media element that will be used.”
>
>     <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-0
> >
>     Append after “If the user indicated a specific browsing context when
>     following the hyperlink, or if the user agent is configured to
>     follow hyperlinks by navigating a particular browsing context, then
>     that must be the browsing context that is navigated.” the paragraph
>     “If the user indicated a media element on the current page when
>     following the hyperlink, then change the currentSrc attribute of
>     the media element to the absolute URL given by the href attribute
>     relative to the URL given by the currentSrc of the media element.”.
>
>     (I am unsure about relative URIs. Would we need to change only the
>     media fragment, and not re-run the initialization steps? What about
>     the media formats given by <source> elements?)
>
>   - Limitations
>     (No idea.)
>
>   - Implementation:
>     (I am not a very clever guy. Someone would need to fill this in.)
>
>   - Adoption:
>     Users could easily link to parts of media resources on a page. The
>     solution would be backwards compatible for existing UAs that are
>     able to process media fragment URIs as long as absolute URIs are
>     used. A JavaScript polyfill could be used while not all UAs support
>     this feature. Consumers of web pages could easily see what a
>     discussion about a media resource refers to.
>
> --
> Nils Dagsson Moskopp // erlehmann
> <http://dieweltistgarnichtso.net>
>

Received on Sunday, 25 November 2012 14:30:10 UTC