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

[Nils Dagsson Moskopp]

Philip Jägenstedt <philipj at opera.com> schrieb am Wed, 19 Dec 2012
11:19:14 +0100:

> On Tue, 18 Dec 2012 22:25:19 +0100, Nils Dagsson Moskopp  
> <nils at dieweltistgarnichtso.net> wrote:
> 
> > Nils Dagsson Moskopp <nils at dieweltistgarnichtso.net> schrieb am
> > Tue, 18 Dec 2012 17:01:40 +0100:
> >
> >> […]
> >>
> >> I therefore prefer a declarative way of linking to timed resources
> >> embedded in their original context. Working on a polyfill right
> >> now.
> >
> > <http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/>
> > I am delighted how useful it is. Is there any implementor interest?
> 
> Redefining/extending what the fragment component does for HTML is
> somewhat risky, so it really comes down to what exactly the
> processing should be.
> 
> What should a browser do with a URL ending with #foo&t=10 if there is
> an element on the page with id="foo&t=10"? What about #foo&bar if
> there is an element with id="foo"? I would be surprised if treating
> #foo& the same as #foo were Web compatible...

I have downloaded an archive of the top 10000 HTML files to look into
used ID values (thanks to Anne van Kesteren for the hint):
<http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/>

> The part of the spec that would be affected is  
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid>,  
> can you give more details about the changes you'd make?

When the fragment changes and on page load, the script splits the
fragment on „&“, interpreting the first part as element ID and the
second as media fragment. It scrolls to that element, gives it focus and
sets the src of that element to the currentSrc with the media fragment
applied. Working code is here; part of it is undoubtedly naive.
<http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/media-fragments-html-polyfill.js>

Working from this, my ad-hoc approach would be to insert new steps
after step 4 or 6 of the algorithm to determine the indicated part of
the document. (I doubt that I am qualified for this, though.)

[…]

- If the decoded fragid includes no U+0026 AMPERSAND character, stop
  the algorithm here. There is no indicated part of the document.

- Let element id be the part of the decoded fragid up to, but not
  including the first U+0026 AMPERSAND character. If there is an
  element in the DOM that has an ID exactly equal to element id, then
  the first such element in tree order is the indicated part of the
  document, hereafter referred as media element.

- If the media element is not an audio or video element, stop the
  algorithm here.

- Let media fragment be the part of the decoded fragid after
  the first U+0026 AMPERSAND character.

- Parse the the currentSrc attribute of the media element, let the
  address of the current media resource be the result of replacing the
  <fragment> component of the URL with the media fragment.

- Invoke the media element's load algorithm.

[…]

The drawback of this would be that and element whose ID contains an
ampersand would take precedence before media fragments – preserving old
semantics, but adding possible headscratchers.

Also, img elements could certainly benefit from spatial media fragments.

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