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

[whatwg] Google Feedback on the HTML5 media a11y specifications

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 15 Feb 2011 14:33:28 +1100
Message-ID: <AANLkTimKZcgC5G9qaN_Xsz+S9QV7veNPLbFFLjuVx5WO@mail.gmail.com>
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>
>> wrote:
>>>
>>> Wouldn't a more sane approach here be to have each language in its own
>>
>> file,
>>>
>>> each marked up with its own language, so that they can be
>>> enabled/disabled
>>> individually? I'd certainly appreciate not having the screen cluttered
>>
>> with
>>>
>>> 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
>> a
>> 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
>>
>> one
>>>
>>> wants really fine-grained font control, it should already be possible
>>
>> using
>>>
>>> webfonts and targeting specific glyphs with <c.foo>, etc.
>>
>> I don't think you should need to resort to fine-grained font control to
>> get
>> reasonable default fonts. ?If you need to specify a font explicitly
>> because
>> UAs choose incorrectly, something has gone wrong. ?It doesn't help if
>> things
>> 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.


Cheers,
Silvia.
Received on Monday, 14 February 2011 19:33:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:04 UTC