401
edits
Accessibility/Experiment1 feedback: Difference between revisions
Jump to navigation
Jump to search
added feddback
(added feddback) |
|||
| Line 61: | Line 61: | ||
SP = Silvia Pfeiffer | SP = Silvia Pfeiffer | ||
PJ = Philip Jagenstedt | 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 itextlist. This | * SP: the HTML specification could be improved by including an extra hierarchical element, such as itextlist. This allows all time-aligned text categories to be handled in the same way with itext, but provides a selection mechanism for the alternative tracks. category is a required attribute. | ||
< | <pre> | ||
<video ...> | <video ...> | ||
<itextlist category="CC" activelang="de"> | <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> | ||
<itextlist category="TAD" activelang="en"> | <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> | </itextlist> | ||
</video> | </video> | ||
</ | </pre> | ||
* 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; | |||
} | |||
::: SP reply: I suppose, similar to [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021125.html Ian's proposal for extending srt to support karaoke and lyrics], it could also be extended with functions for onenter and 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: 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. | ||
| Line 101: | Line 103: | ||
* 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: 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. | ||
::: SP reply: By providing a selection mechanism through the "display" attribute, it is possible for the Web developer to override the preferred language setting. Further, the user can do explicit selection through the menu. | |||
* 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. | * 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. | ||
::: SP reply: srt does not have a specification for charset, so the server can only guess the correct charset to provide with the srt file. Thus, IMHO the only means in which a Web developer can provide the correct charset to use for a srt file is by providing it in such an attribute. If that could be avoided, I'd be all for it. | |||
* more feedback encouraged! | * more feedback encouraged! | ||