W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] Google Feedback on the HTML5 media a11y specifications

From: Glenn Maynard <glenn@zewt.org>
Date: Sun, 23 Jan 2011 22:21:17 -0500
Message-ID: <AANLkTinoMvLSUHc2oYLp1mzAjYEBKCz2rQDpKp8DMv+R@mail.gmail.com>
2011/1/14 Silvia Pfeiffer <silviapfeiffer1 at gmail.com>
> Required attributes in WebVTT files should be the main language in use
> and the kind of data found in the WebVTT file - information that is

It should be possible to specify language per-cue, or better, per block of
text mid-cue.  Subtitles making use of multiple languages are common, and it
should be possible to apply proper font selection and word wrapping to all
languages in use, not just the primary language.

When both English subtitles and Japanese captions are on screen, it would be
very bad to choose a Chinese font for the Japanese text, and worse to choose
a Western font and use it for everything, even if English is the predominant
language in the file.

On Sat, Jan 22, 2011 at 9:23 AM, Philip J?genstedt <philipj at opera.com>wrote:

>  * Suggest dropping ?-->?: In the context of HTML, ?-->? is an end
>> comment marker. It may confuse Web developers and parsers if such a
>>
>
> Trying to use an HTML or XML parser to make any sense of WebVTT is going to
> fail horrendously in any case, so if anything I think it's good that they
> fail early. Also, a translation tool that has no concept of WebVTT is going
> to make a mess of various magic strings used in the file format too.


Changing "-->" to "->" would allow HTML-style comments to be used, though.

I'm inclined to say that we should normalize all whitespace during parsing
> and not have explicit line breaks at all. If people really want two lines,
> they should use two cues. In practice, I don't know how well that would
> fare, though. What other solutions are there?
>

I don't know if explicit line breaks are needed, but an obvious option is a
<br/> tag.

-- 
Glenn Maynard
Received on Sunday, 23 January 2011 19:21:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC