Re: Proposal for new direction attribute

On 2013/02/21 5:25, Andrew Cunningham wrote:
> 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.

Very much so. The idea to base direction on the lang attribute was 
proposed very early on, in the work on what became RFC 2070. But it was 
rejected then based on the arguments above: It'as easy to make this for 
the Arabic and Hebrew languages, but there are many more languages out 
there that are written rtl, and some that are written both ways. So we 
abandoned the idea quickly.

Content management systems have a fairly good control over the languages 
they deal with, but browsers don't. Keeping a list of which languages 
should be rtl may be slightly more feasible today than almost 20 years 
ago, but it would still be unnecessary overhead and difficult to keep 
everything in sync and deal with updates.

Regards,   Martin.

> 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 Friday, 22 February 2013 08:39:45 UTC