401
edits
Accessibility/Experiment1 feedback: Difference between revisions
Jump to navigation
Jump to search
added Philip's feedback
(added feedback) |
(added Philip's feedback) |
||
| Line 29: | Line 29: | ||
=== Features of the Implementation === | === Features of the Implementation === | ||
The demo: | '''The demo:''' | ||
* contains four different types of time-aligned text: subtitles, captions, chapters, and textual audio annotations | * contains four different types of time-aligned text: subtitles, captions, chapters, and textual audio annotations | ||
| Line 44: | Line 44: | ||
Bugs / missing features / limitations of the demo: | '''Bugs / missing features / limitations of the demo:''' | ||
* the "delay" functionality of the specification has not been implemented yet | * the "delay" functionality of the specification has not been implemented yet | ||
| Line 60: | Line 60: | ||
=== Thoughts / Feedback === | === Thoughts / Feedback === | ||
SP = Silvia Pfeiffer | |||
PJ = Philip Jagenstedt | |||
* SP: the distinction between captions and subtitles may not be necessary | * SP: the distinction between captions and subtitles may not be necessary | ||
* SP: the HTML specification could be improved by including an extra hierarchical element, such as | * SP: the HTML specification could be improved by including an extra hierarchical element, such as itextlist. This increases complexity, but makes the creation of the selection menu much easier. | ||
<nowiki> | |||
<video ...> | |||
<itextlist category="CC" activelang="de"> | |||
<itext src="caption.de.srt" lang="de" type="text/srt" /> | |||
<itext src="caption.en.srt" lang="en" type="text/srt" /> | |||
<itext src="caption.it.srt" lang="it" type="text/srt" /> | |||
</itextlist> | |||
<itextlist category="TAD" activelang="en"> | |||
<itext src="audioann.de.srt" lang="de" type="text/srt" charset="ISO-8859" /> | |||
<itext src="audioann.en.srt" lang="en" type="text/srt" charset="ISO-8859" /> | |||
</itextlist> | |||
</video> | |||
</nowiki> | |||
* PJ: can we make this fit in with or replace the addCueRange/removeCueRanges interface? Basically, I believe it should be possible to, using a DOM interface, add the same timed text ranges that would result from letting the browser parse SRT. The only difference between itext and the cue ranges interface is that one is associated with text while the other uses callbacks. The allText property would need to be replaced with another representation where both the times and the text (or callbacks) can be created/modified/deleted. Something like an array of | |||
interface MediaTimeRange { | |||
attribute double start; | |||
attribute double end; | |||
attribute DOMString text; | |||
attribute Function onenter; | |||
attribute Function onleave; | |||
} | |||
* PJ: Then, the delay method would become somewhat redundant, better to handle this by rewriting the times via DOM (also allows fixing drift, not just constant delay) currentText also wouldn't be needed. | |||
* PJ: I think that the fetch and error mechanism might be overkill, how about letting the UA decide if/when to download the resources? You might still want a fetched property I guess, but we might reuse the [http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#dom-img-complete complete property and onload event from the img element]. | |||
* PJ: Making enabled writable would remove the need for enable()/disable(). | |||
* PJ: Depending on the user agents preferred language setting has failed miserable so far - most users just leave it as the default. Sites are forced to use explicit language selection or guess the language based on IP, I expect it would be no different for this feature. I honestly don't know what a good solution for this is. | |||
* PJ: For scripts, the charset attribute is ignored for cross-origin because interpreting something under a different charset than intended can give different results. The cross-origin problem is probably more relevant when it comes to allText/currentText/MediaTimeRange. I'm not sure if verifying that the resource is in fact a supported type is enough, as that would still allow web sites to read subtitle files from the intranet of the client if they can guess the URL. Imagine if the full text of http://internal/secret-talk-transcript.srt was available for all to see through this API. | |||
* more feedback encouraged! | |||