[whatwg] Google Feedback on the HTML5 media a11y specifications
silviapfeiffer1 at gmail.com
Mon Feb 14 19:33:28 PST 2011
On Tue, Jan 25, 2011 at 8:17 AM, Philip Jägenstedt <philipj at opera.com> wrote:
> On Mon, 24 Jan 2011 12:28:36 +0100, Glenn Maynard <glenn at zewt.org> wrote:
>> On Mon, Jan 24, 2011 at 4:32 AM, Philip Jägenstedt <philipj at opera.com>
>>> Wouldn't a more sane approach here be to have each language in its own
>>> each marked up with its own language, so that they can be
>>> individually? I'd certainly appreciate not having the screen cluttered
>>> languages I don't understand...
>> Personally I'd prefer that, but it would require a good deal of metadata
>> support--marking which tracks are meant to be used together, tagging
>> auxilliary track types so browsers can choose (eg. an "English subtitles
>> with no song caption tracks" option), and so on. I'm sure that's a
>> non-starter (and I'd agree).
> Maybe you could enable them all by default and let users disable the ones
> they don't like?
>> A much more realistic method would be to mark the transcription cues with
>> class, and enabling and disabling them with CSS.
> That would work too.
>>> (Also, we're not going to see <video><track> used for anime fansubbing on
>>> the public Web until copyright terms are shortened to below the attention
>>> span of anime fans.)
>> Maybe so. I don't know if professional subtitles ever do this. I'm
>> guessing (and hoping) not, but I'll ask around as a data point--they've
>> taken on other practices of fansubbers in the past.
> That'd be valuable data to have, and something funny to look at :)
>>> Yeah, the monospace Latin glyphs in most CJK look pretty bad. Still, if
>>> wants really fine-grained font control, it should already be possible
>>> webfonts and targeting specific glyphs with <c.foo>, etc.
>> I don't think you should need to resort to fine-grained font control to
>> reasonable default fonts. If you need to specify a font explicitly
>> UAs choose incorrectly, something has gone wrong. It doesn't help if
>> are expected to work without CSS, either--I don't know how optional CSS
>> support is meant to be to WebVTT.
> My main point here is that the use cases are so marginal. If there were more
> compelling ones, it's not hard to support intra-cue language settings using
> syntax like <lang en>bla</lang> or similar.
Having mixed language cues is actually also something I'd like to see
solved, in particular for selecting the right font. If e.g. a Chinese
word was displayed right in the middle of some English captions, it
should be marked up properly. Maybe we can use <c> for this with a
@lang attribute e.g. <c lang="zh">? I think I would prefer that over
introducing another span-like element.
More information about the whatwg