- From: <bugzilla@jessica.w3.org>
- Date: Mon, 07 Nov 2011 00:31:14 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14709 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |http://dev.w3.org/html5/spe | |c/elements#the-lang-and-xml | |:lang-attributes CC| |xn--mlform-iua@xn--mlform-i | |ua.no --- Comment #2 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-11-07 00:31:11 UTC --- (In reply to comment #1) > Another way to look at this problem is "should ISO 639-3 (three-letter) codes > be allowed when the BCP47 tag for a given language is the two-letter ISO 639-1 > code?" Due to the fact that the BCP47 tag is "my", there can be no doubt that it is invalid to use lang="mya". However, I think what you ask, is whether it would be against HTML5 for the screenreader to report the 3-letter tag "mya" as Burmese when the valid BCP47 tag for Burmese is "my". The spec seems to say that "mya" should be reported as "mya" and not as "Burmese". On the other side, the spec does not seem to have considered what to do in a case such as "mya". If I read you correctly, you want HTML5 to explicitly forbid that "mya" is treated like a synonym for "my". And this might make sense. When it comes to CSS, then it is clear that it is not synonymous - just consider that div:lang(mya){} would not select <div lang="my">. But when it comes to screenreaders and OpenType APIs etc, then this might not be as clear. BCP47 itself has its own extension points, and in order that extensions happens in BCP47 and not elsewhere etc, it might make sense to say that codes that are not part of BCP47 should not be treated as synonyms of codes that *are* part of BCP47. Or something like that. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 7 November 2011 00:33:20 UTC