search

cgiffard / Captionator

HTML5 polyfill for closed captioning with the <track> element, and implements the WHATWG Timed Text Track specification.
captionatorjs.com
300 stars 66 forks source link

Enable use of verbose <source> type markup in MediaTracks #4

Closed cgiffard closed 13 years ago

cgiffard commented 13 years ago

This could be hard, as it runs up against a browser parser bug. Basically the following syntax should be supported:

<track kind="commentary" srclang="en" label="Director's Commentary">
    <source src="audio/commentary.ogg" type="audio/ogg" />
    <source src="audio/commentary.mp3" type="audio/mp3" />
    <source src="audio/commentary.wav" type="audio/wav" />
</track>

At the moment the elements appear outside of the track, meaning they can't be associated with it (negating the whole point of marking the document up like this!)

I do think this syntax should be supported. It makes sense.****

Synchronised media is nice, (and already supported, I might add!) but semantically it seems a little off. An assistive/media enhancement track shouldn't appear separately to a media element, since it is hierarchically a descendant of that element. Additionally, it clutters up the page, adding unintended meaning and distraction to users uninterested in assistance or additional media features. Synchronised media doesn't degrade nicely in browsers not capable of associating it with the syncMaster - but assistive and enhancement tracks are nicely hidden from those agents with the syntax above. (Then you can make them work with Captionator!)

This is a parsing problem which may require re-downloading the whole page (painful, and runs into edge cases, especially where the page might have been originally requested using POST, or as part of a one-time-only user action.)

If it's somehow possible to easily extract the raw text, or work out which orphaned <source> elements are associated with the parent <track>, then that's the method we want to attack.

cgiffard commented 13 years ago

Don't think I can fix this. :(

http://stackoverflow.com/questions/6935945/parsing-unsupported-page-markup-in-js-without-re-requesting-via-xhr