401
edits
Accessibility/Experiment1 feedback: Difference between revisions
Jump to navigation
Jump to search
added Felipe Sanchez' comments + my replies
(added Felipe Sanchez' comments + my replies) |
|||
| Line 59: | Line 59: | ||
=== Thoughts / Feedback === | === Thoughts / Feedback === | ||
SP = Silvia Pfeiffer | SP = Silvia Pfeiffer/Xiph, Mozilla | ||
PJ = Philip Jagenstedt | PJ = Philip Jagenstedt/Opera | ||
GF = Geoff Freed/WGBH | GF = Geoff Freed/WGBH | ||
FS = Felipe Sanchez/collaborative subtitling | |||
* SP: the distinction between captions and subtitles may not be necessary | * SP: the distinction between captions and subtitles may not be necessary | ||
| Line 104: | Line 106: | ||
* 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. | ||
* FS: I'd suggest adding another synchronization parameter. It could be called "stretch". Sometimes different video encodings lead to slightly different playback speed (maybe due to issues related to different framerates). So, one would not only delay the subtitles but maybe also time-stretch it a bit in order to synchronize it. Default value for this parameter would be "100%". If one needs the subtitles to be displayed 3% faster, then he/she would explicitly set stretch="103%". The itext tag (specially if it provides both delay and stretch attributes) will make it easier to implement a clean version of the collaborative subtitling system. | |||
* 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: 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]. | ||
| Line 116: | Line 120: | ||
::: 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. | ::: 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. | ||
* FS: I suggest that we provide a standard way of adding to the text category menu the subtitles that come embedded in videos. (https://bugzilla.mozilla.org/show_bug.cgi?id=481529) What would be the proposed procedure for adding these to the list? The ogg-decoder would need a way to provide this info to the subtitles list code. It will be good if this info is accessible through DOM so that client code can be aware of embedded subs. | |||
::: SP reply: I haven't started working on in-band time-aligned text yet, but the plan is to experiment with Ogg and Kate to see how far we can get to expose an identical interface to the browser as through the out-of-band time-aligned text. So, while parsing the binary file, the text should be added to the DOM as is happening with the out-of-band text. | |||
* more feedback encouraged! | * more feedback encouraged! | ||