- From: Cameron Jones <cmhjones@gmail.com>
- Date: Wed, 21 Nov 2012 13:41:37 +0100
- To: "Phillips, Addison" <addison@lab126.com>
- Cc: Richard Ishida <ishida@w3.org>, Mark Davis ☕ <mark@macchiato.com>, Robin Berjon <robin@w3.org>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, "www-international@w3.org" <www-international@w3.org>
- Message-ID: <CALGrgetdp_M0TgzVffr2BLn7XFoosR6oSyeonkxua86eetQh-Q@mail.gmail.com>
On Mon, Nov 19, 2012 at 8:08 PM, Phillips, Addison <addison@lab126.com>wrote: > Hello Cameron,**** > > ** > Hi Addison, > ** > > > The point i was making during the F2F is that valid BCP-47 requires the > preceeding language identifier before any extension attributes. Using just > an extension attribute is not valid BCP-47, it would not conform to the > parsing rules.**** > > ** ** > > AP> You’re correct. However, you probably want the other information in > the language tag when formatting a date control anyway. Setting the > calendar to (for example) the Islamic calendar is just one bit of > information you need to achieve correct formatting. You also need the > language to use, the specific regional customs (first day of week, > abbreviation formatting, week numbering, etc.) to use.**** > > ** > CJ> I understand the scope of @lang with regards to the whole element consisting of attributes and any content model, but i wonder if there is actually a need for intra-element localization? The element seems like a suitable level of granularity, otherwise each attribute or attribute set would require another localization option. ** > > AP> Perhaps this would be a reason to change from calling it @calendar to > something slightly more generic, like, say, @format? > CJ> I'm interested in maintaining the @lang attribute for structural markup and deferring formatting as a presentational customization through CSS. The :lang pseudo class is already available which is a nice intersection rather than introducing new structural markup, and i can see some simple CSS properties being capable of controlling the formatting based on the CLDR. > **** > > ** ** > > BCP-47 does not limit calendars to certain languages, so you can use > islamic calendar with any lanugage set. In that regard BCP-47 has complete > flexibility with regard to all localization identification.**** > > ** ** > > AP> Richard’s point is that @lang is supposed to declare the language of > the content and it applies to the whole of the element. What we are doing > here is using an attribute to cause the user-agent to format some content > for us and this might apply only to the one specific thing (the > presentation of the calendar itself). > CJ> Yes, but i think looking at this specific case of an <input type="date">, the calendar should be included within the scope of the whole element and its declaration. CJ> The multi-language use of elements can be see to be a more divergent use case than the use of @lang for acquiring inherent localization information. > **** > > ** ** > > AP> When Mark and I started our work on the current BCP 47, one of our > precepts was that a language tag and a locale identifier are the same thing > and want to be interchangeable. The addition of the Unicode Locale > extension allows language tags full expressiveness in this regard and, when > this issue was first raised, my reaction was along the lines of: “the > language attribute is a perfectly effective vehicle for conveying both the > language of static text in an HTML document and for conveying the locale to > use when formatting content inserted into that document.”**** > > ** ** > > AP> When we discussed this in the WG call, though, Richard made the point > that he is making in this thread: that there may be times when you want to > separate a particular static text declaration from the locale formatting > used in the control.**** > > ** ** > > AP> Richard goes on to make the point that, in the absence of an @calendar > value, the @lang ought to control the format of the calendar. That is, each > of these three fragments has the same result for the calendar (assuming no > intervening @lang values):**** > > ** ** > > <html lang=”de-u-ca-islamic”>**** > > …**** > > <input>**** > > ** ** > > ---**** > > <html>**** > > …**** > > <input lang=”de-u-ca-islamic">**** > > ---**** > > ** ** > > <html>**** > > …**** > > <input calendar=”de-u-ca-islamic”>**** > > ** ** > > AP> … and, as Richard points out, that allows for the @lang to have one > value while the @calendar does something else:**** > > ** ** > > <input type=date lang=de calendar=ar-u-ca-islamic title=”Abfahrtsdatum“><!-- > Arabic calendar with German title -->**** > > ** ** > > AP> A good analogy for what Richard, I think, is looking for is the > proposal we had about being able to have an ‘attrdir’ to set the base > direction of an attribute separately from that of the element. In that > case, you want to be able to do something like:**** > > ** ** > > <p dir=rtl alt=”english explanation here” attrdir=ltr>HEBREW TEXT HERE IS > RTL.</p>**** > > ** ** > > AP> … in which the direction of the attribute is different from the > direction of the element’s contents. It is a rare case, but equivalent. > (It’s such a rare case that we didn’t end up adding @attrdir to HTML). > Question is whether it is appropriate for language/locale.**** > > ** > CJ> I see the example but i'm unsure of the approach. CJ> If this didn't pass for @attrdir, i'm not sure it should pass here where it would introduce more complexity only for a speculative edge case. Thanks, Cameron Jones
Received on Wednesday, 21 November 2012 12:42:05 UTC