Re: WebVTT feedback

I'm not sure I follow all this, but I don't see the problem with saying "if you want your text to look right, use the right Unicode characters and tag with the right languages, if necessary at the <span> level".

Saying that the results of including say Chinese characters in a span labelled as in say, Klingon, may result in unexpected, unpredictable, behavior, up to and including angry Klingons invading your workspace, seems to be not too bad, IMHO.  You want to be safe from said Klingons?  Label your languages!

On Dec 20, 2011, at 17:43 , Glenn Maynard wrote:

> On Tue, Dec 20, 2011 at 7:25 PM, David Singer <singer@apple.com> wrote:
> > > With or without language information, font switching is needed. I assume that you don't mean that Chinese text in something labeled as English shouldn't be rendered at all, so how should the font for each character be picked?
> >
> > I'm not sure I get the question.  I'm suggesting that if you want correct behavior, I would expect to see a VTT file labelled as 'generally lang=en-US' but this <span> has lang=zh.  (I'm using short language codes here, but full BCP 47 codes might be better).
> 
> The problem is that tagging a span lang=en doesn't prevent including CJK codepoints.  The UA still has to choose which language glyphs to use in that case, so merely providing a default @lang value, or requiring that one be provided, doesn't solve the interop problem.
> 
> > In the absence of font tagging, I would assume that the UA has a set of fonts that are suitable for the intersections of Unicode characters and languages used.  Does that not work?
> 
> It doesn't work in an interoperable way, since every browser has its own rules for this choice.  Worse, some of the rules depend on the user's configuration.
> 
> > If the question is, what happens when the author fails to tag his content with the languages, well, he may not get the expected result.
> 
> The answer should be that you get a predictable, well-defined result, even if it's not what the user expected.  It would be nice to get there, or closer to it, but WebVTT doesn't seem like the place to solve it.
> 
> One possible approach--just to brainstorm a little--would be for HTML to define an attribute "predictableLanguages" (can't think of a good name).  If set, glyph selection would be switched to a new, well-defined, interoperable mechanism.
> 
> WebVTT would simply set this attribute on generated DOM nodes Importantly, the solution would be in the right place--HTML, in the regular layout engine--not a WebVTT-specific special case.
> 
> Not great, but an idea.  It's basically an escape hatch if all attempts to standardize glyph selection are going to fail due to legacy content.  I don't know if it's too early to give up on that.  (Of course, actually defining language selection properly would still be a significant task.)
> 
> --
> Glenn Maynard
> 

David Singer
Multimedia and Software Standards, Apple Inc.