W3C home > Mailing lists > Public > www-international@w3.org > January to March 2013

Re: Proposal for new direction attribute

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 20 Feb 2013 21:49:10 +0100
To: Andrew Cunningham <andrewc@vicnet.net.au>
Cc: "Amir E. Aharoni" <amir.aharoni@mail.huji.ac.il>, www International <www-international@w3.org>, "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>, Richard Ishida <ishida@w3.org>, "Phillips, Addison" <addison@lab126.com>
Message-ID: <20130220214910036646.db0c71d0@xn--mlform-iua.no>
The way I propose to link direction to @lang,[1] then, to get the new 
isolation behavior for unsupported languages, one could do this:

<div lang="unsupported-language" dir="auto">
    <div dir="rtl">Lorem Ipsum</div>
</div>

[1] 
http://www.w3.org/mid/20130220214342391704.d3a0addd@xn--mlform-iua.no


Leif H Silli




Andrew Cunningham, Thu, 21 Feb 2013 07:25:20 +1100:
> Hi Amir,
> 
> In theory basing it on language sounds good, but I doubt it would be
> practical. I suspect that even if browser developers implemented it, that
> it would only cover a small subset of languages. And could damage minority
> languages, ie. set the direction incorrectly for minority languages.
> 
> Additionally a number of languages have orthographies using different
> scripts and require different directions being set.
> 
> In theory this could be covered by language tagging being accurate and
> including script codes where necessary. But ...
> 
> Personally, as a developer working with multiple languages, I prefer to
> have full control of languages, their typography, text direction and other
> aspecta.
> On Feb 21, 2013 5:37 AM, "Amir E. Aharoni" <amir.aharoni@mail.huji.ac.il>
> wrote:
> 
>> i2013/2/20 Phillips, Addison <addison@lab126.com>:
>>> Hello Amir,
>>> 
>>> In my opinion, using the @lang attribute to set direction is a bad idea.
>> The
>>> language tag is not an explicit indicator of the direction of content. It
>>> may, of course, imply the direction. But it is a poor indicator compared
>> to
>>> either explicit direction or to first strong (auto direction).
>> 
>> Contrariwise: first-strong is just a poor heuristic when no other
>> information about direction is available.
>> 
>> dir="rtl/ltr" is what's used in practice today, of course, and it's
>> OK, but how is it used? How does the developer decide that something
>> should be ltr or rtl? According to the language, of course. At least
>> that's what happens in major CMSs, like WordPress and MediaWiki. I am
>> a developer of the latter; it applies dir server-side (and sometimes
>> client-side) according the language whenever it is known. We currently
>> maintain our list of languages, with a direction specified for each
>> language, and we are gradually moving to using the CLDR for providing
>> information about the writing system, and hence the direction, of each
>> language. I cannot imagine web developers doing anything else. And
>> since that's what's happening in practice, it should be done by the
>> browser.
>> 
>> There are edge cases, the most famous examples being Punjabi and
>> Azeri, but as I explain in
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19888 , using correct
>> language codes solves this problem. Developers should use a correct
>> lang attribute anyway. This also means that "few people use the lang
>> attribute" is a weak argument.
>> 
>> What I am proposing is to apply a *default* direction according to the
>> specified language, and to make it possible to override with an
>> explicit dir (or direction) attribute.
>> 
>> --
>> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
>> http://aharoni.wordpress.com

>> ‪“We're living in pieces,
>> I want to live in peace.” – T. Moore‬
>> 
>> 
>>> 
>>> Having @lang start a new isolate might be worthwhile, though, since one
>>> language embedded in another might very well have different directional
>>> characteristics and there is no reason to require users to input both
>>> attributes if the content does not inherently require more complex
>> markup.
>>> 
>>> Addison Phillips
>>> Globalization Architect (Lab126)
>>> Chair (W3C I18N WG)
>>> 
>>> Sent from my Kindle Fire HD
>>> 
>>> 
>>> "Amir E. Aharoni" <amir.aharoni@mail.huji.ac.il> wrote:
>>> 
>>> The direction/dir transition plan is nice.
>>> 
>>> It's a bit disappointing, though, that neither of the following
>>> suggestions was considered:
>>> 1. Make any element with an explicit lang or dir attribute
>>> bidi-isolated by default
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18490

>>> 
>>> 2. Apply the direction according to language
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19888

>>> 
>>> Is there, maybe, a plan to consider this in the future?
>>> 
>>> --
>>> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
>>> http://aharoni.wordpress.com

>>> ‪“We're living in pieces,
>>> I want to live in peace.” – T. Moore‬
>>> 
>>> 
>>> 2013/2/20 Richard Ishida <ishida@w3.org>:
>>>> Unicode 6.3 will shortly be released, and will contain new control codes
>>>> (RLI, LRI, FSI, PDI) to enable authors to express isolation at the same
>>>> time
>>>> as direction in inline bidirectional text. The Unicode Consortium
>>>> recommends
>>>> that isolation be used as the default for all future inline
>> bidirectional
>>>> text embeddings.
>>>> 
>>>> The i18n WG has been discussing how to ensure that HTML5 encourages and
>>>> enables content authors to adopt and apply isolation *as the default*
>>>> whenever they set direction on inline content, and discourage future use
>>>> of
>>>> dir=rtl or dir=ltr (which does not produce isolation).
>>>> 
>>>> The proposal of the WG, with rationales, can be found at
>>>> http://www.w3.org/International/wiki/Html-bidi-isolation

>>>> 
>>>> i18n WG folks, please let me know asap if you think this needs changing
>> in
>>>> some way.
>>>> 
>>>> RI
>>>> 
>>>> 
>>>> --
>>>> Richard Ishida
>>>> W3C
>>>> http://rishida.net/

>>>> 
>>> 
>>> 
>> 
>> 
Received on Wednesday, 20 February 2013 20:49:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 February 2013 20:49:45 GMT