Philip Jägenstedt <phil...@opera.com> schrieb am Wed, 19 Dec 2012 11:19:14 +0100:
> On Tue, 18 Dec 2012 22:25:19 +0100, Nils Dagsson Moskopp > <n...@dieweltistgarnichtso.net> wrote: > > > Nils Dagsson Moskopp <n...@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>
