Nabble - w3.org - i18n

New translations into Romanian

2009-12-15T05:09:20Z

Thanks to the Sorin Velescu, the following articles have been translated into Romanian.

Schimbarea codificarii paginii (X)HTML in UTF-8 (Changing (X)HTML page encoding to UTF-8)
http://www.w3.org/International/questions/qa-changing-encoding.ro.php

CSS3 si textul international (CSS3 and International Text)
http://www.w3.org/International/articles/css3-text/Overview.ro.php

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

From forum: w3.org - www-international

New translations into Spanish

2009-12-11T08:56:27Z

Thanks to the Spanish Translation Team, Spanish Translation US, the following articles have been translated into Spanish.

Verificación de encabezados HTTP (Checking HTTP Headers)
http://www.w3.org/International/questions/qa-headers-charset.es.php

Configuración de información charset en .htaccess (Setting charset information in .htaccess)
http://www.w3.org/International/questions/qa-htaccess-charset.es.php

Verificación de la codificación de caracteres mediante el verificador (Checking the character encoding using the validator)
http://www.w3.org/International/questions/qa-validator-charset-check.es.php

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

From forum: w3.org - www-international

[JLReq] Section 3.3.8, last list

2009-12-10T07:09:37Z

In the last list in Section 3.3.8, "Adjustments of Ruby with Length
Longer than that of the Base Characters", [1]:

- Item "e" covers "Jukugo-ruby at the line head or at the line end",
but item "f" covers "Jukugo-ruby at the line head" and item "g"
covers "Jukugo-ruby at the line end". Is this overlap correct?

- Note 2, following the list, includes:

The handling and positioning of these complexes with adjacent
characters is discussed in Appendix F Positioning of Jukugo-ruby
as a complete table, following 3.9 About Character Classes.

Appendix F is more than just a table, and there are sections and
other appendices between Section 3.9 and Appendix F.

Regards,

Tony Graham Tony.Graham@...
Director W3C XSL FO SG Invited Expert
Menteith Consulting Ltd XML Guild member
XML, XSL and XSLT consulting, programming and training
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
Registered in Ireland - No. 428599 http://www.menteithconsulting.com
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
xmlroff XSL Formatter http://xmlroff.org
xslide Emacs mode http://www.menteith.com/wiki/xslide
Unicode: A Primer urn:isbn:0-7645-4625-2

[1] http://www.w3.org/TR/jlreq/#en-subheading2_3_8

From forum: w3.org - www-i18n-comments

[JLReq] Fig 197

2009-12-10T06:59:51Z

The paragraph before Fig. 197 [1] describes the single figure as "are
examples with the same jukugo-ruby as in [Fig.195] and [Fig.195] ..."

The figure shows the same jukugo-ruby as Fig. 195 and Fig. 196. The
text should be corrected.

Regards,

Tony Graham Tony.Graham@...
Director W3C XSL FO SG Invited Expert
Menteith Consulting Ltd XML Guild member
XML, XSL and XSLT consulting, programming and training
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
Registered in Ireland - No. 428599 http://www.menteithconsulting.com
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
xmlroff XSL Formatter http://xmlroff.org
xslide Emacs mode http://www.menteith.com/wiki/xslide
Unicode: A Primer urn:isbn:0-7645-4625-2

[1] http://www.w3.org/TR/jlreq/#fig_a6-12-en

From forum: w3.org - www-i18n-comments

New article: Choosing a language tag

2009-12-03T08:36:16Z

Thanks for your feedback on this article. Since my last notification of intent to publish, I only received one editorial comment on this article, so today I have published it as a final version.

http://www.w3.org/International/questions/qa-choosing-language-tags.en.php

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

From forum: w3.org - www-international

Re: More best practices for RTL scripts (markup vs CSS for bidi).

2009-11-26T22:54:56Z

On 11/26/2009 05:09 PM, Adil Allawi wrote:

> Actually the reality is worse. Below is your page drawn in Gecko (Firefox) on
> the left and Webkit (Safari) on the right:
>
>
>
> There is a thread on this list started by Aharon from Google that talks about
> exactly theses sort of issues that has received too little discussion. The real
> problem is that the HTML standard is not explicit enough on what should happen
> so you will get different results on different browsers.
>
> Your example is in a fuzzy area. As far as the markup is concerned there are
> three distinct paragraphs but for the user there is one sentence. According to
> the HTML standard, the elements should be ordered according to the Unicode bidi
> algorithm, however that algorithm has nothing to say about what to do when lines
> of a paragraph are drawn inline. I would personally say that the Gecko engine is
> doing the right thing in this case.

I assume your Gecko example is using a very recent version of Gecko,
such as a nightly build or a beta of Firefox 3.6? I fixed this issue
only a few months ago.

The HTML standard does specify what to do in this case, see
http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi:

"When a block element that does not have a dir attribute is transformed
to the style of an inline element by a style sheet, the resulting
presentation should be equivalent, in terms of bidirectional formatting,
to the formatting obtained by explicitly adding a dir attribute
(assigned the inherited value) to the transformed element."

In practice, however, since browsers are not consistent, authors will
have to use CSS properties to achieve the expected results.

>
> regards
>
> Adil
>
> On 25/11/2009 17:40, Najib Tounsi wrote:
>> Dear all, and bidi experts
>>
>> When trying to localize [1] the new W3C homepage style [2], I came across
>> something worth to note.
>>
>>
>> HTML markup (dir="rtl") doesn't have the same effect as CSS (direction:
>> rtl;unicode-bidi: embed;)
>>
>> Some time you want your block-element to display inline (e.g. for menu-like
>> effect). However, by default this block elements flow from left to right. So
>> to make them flow from right-to left, you want to use HTML markup (dir="rtl").
>> It doesn't work. You should use CSS properties
>> (direction: rtl; unicode-bidi: embed;) to get the desired effect.
>>
>> with the following style:
>>
>> <style type="text/css">
>> .a p {display:inline; direction: rtl; unicode-bidi: embed}
>> .b p {display:inline;}
>> </style>
>>
>> the HTML code (case-1):
>>
>> <div class="a">
>> <p>display</p>
>> <p>in</p>
>> <p>line</p>
>> </div>
>>
>> results in
>> line in display
>>
>> while (case-2):
>>
>> <div class="b" dir="rtl">
>> <p>display</p>
>> <p>in</p>
>> <p>line</p>
>> </div>
>>
>> will result in (right justified)
>> display in line
>>
>>
>> The point is: Why CSS 'direction: rtl; unicode-bidi: embed' is not the same as
>> markup 'dir="rtl"'
>>
>> Css vs markup FAQ [3] says (and I strongly agree):
>> "You should always use dedicated bidi markup to describe your content, where
>> markup is available [...] because directionality is an integral part of the
>> document structure." This rule seems violated in the above example.
>>
>> Well... why change writing direction when content is all English?
>> But imagine one of the<p> contains a strong RTL char.
>>
>> The two cases are still different. In the second case (dir="rtl"), the result
>> is like if all<p>s are inline elements, i.e. all inner<p>s are removed.
>> Please try it: http://www.w3c.org.ma/Tests/displayInline.html
>>
>> So, the rule seems to be (grossly paraphrased):
>> For inline elements, CSS direction property applies to the ordering of
>> elements as well as to their content. On the other hand, markup dir attribute
>> applies only to the content of these elements juxtaposed together.
>>
>> Any opinion?
>>
>> [1] http://www.w3c.org.ma/Tests/temp-ar-index.html
>> [2] http://www.w3.org/
>> [3] http://www.w3.org/International/questions/qa-bidi-css-markup
>>
>>
>> -----------------------------
>> Note incidently, that elements displayed inline and floated right, will flow
>> (by side effect) from right to left, whatever direction is specified. Does
>> float style (*cancel*) direction style?
>>
>> Try it: http://www.w3c.org.ma/Tests/inlineFloat.html
>>
>>
>> Best regards,
>>
>> Najib
>>
>>

From forum: w3.org - www-international

Re: More best practices for RTL scripts (markup vs CSS for bidi).

2009-11-26T16:57:53Z

Richard Ishida wrote:

> Najib,
>
> I think it's because your CSS is not applying direction in the same way as
> your non-CSS example. I think that to get equivalence between a and b you
> should use
>
> .a { direction: rtl; unicode-bidi: embed;}
> .a p {display:inline; }
> .b p {display:inline;}
>
> If you use that CSS, the results look identical.

Yes. Aligned to the right because it is the div section which has the
class "a".
> This is because the dir
> attribute is used on the div, not on the p elements,

Now with my initial CSS and dir="rtl" on the p element, a and b become
equivalent, but aligned to the left this time.

> however you were trying
> to apply the direction property, using CSS, to inline elements. Only by
> applying to block elements will you get the right alignment.
>
> Does that make sense?
>

Hum... It remains that dir attribute applied globally to div element
containing p elements, is not the same as if it is applied separately to
each p element. Isn't it "Directional markup used far too often in a
document." ?

Thank you Richard for your notice.

Regards, Najib

>
> ============
> Richard Ishida
> Internationalization Lead
> W3C (World Wide Web Consortium)
>
> http://www.w3.org/International/
> http://rishida.net/
>
>
>
>
>> -----Original Message-----
>> From: public-i18n-core-request@... [mailto:public-i18n-core-
>> request@...] On Behalf Of Najib Tounsi
>> Sent: 25 November 2009 17:40
>> To: public-i18n-core@...; 'WWW International'
>> Subject: More best practices for RTL scripts (markup vs CSS for bidi).
>>
>> Dear all, and bidi experts
>>
>> When trying to localize [1] the new W3C homepage style [2], I came
>> across something worth to note.
>>
>>
>> HTML markup (dir="rtl") doesn't have the same effect as CSS (direction:
>> rtl;unicode-bidi: embed;)
>>
>> Some time you want your block-element to display inline (e.g. for
>> menu-like effect). However, by default this block elements flow from
>> left to right. So to make them flow from right-to left, you want to use
>> HTML markup (dir="rtl"). It doesn't work. You should use CSS properties
>> (direction: rtl; unicode-bidi: embed;) to get the desired effect.
>>
>> with the following style:
>>
>> <style type="text/css">
>> .a p {display:inline; direction: rtl; unicode-bidi: embed}
>> .b p {display:inline;}
>> </style>
>>
>> the HTML code (case-1):
>>
>> <div class="a">
>> <p>display</p>
>> <p>in</p>
>> <p>line</p>
>> </div>
>>
>> results in
>> line in display
>>
>> while (case-2):
>>
>> <div class="b" dir="rtl">
>> <p>display</p>
>> <p>in</p>
>> <p>line</p>
>> </div>
>>
>> will result in (right justified)
>> display in line
>>
>>
>> The point is: Why CSS 'direction: rtl; unicode-bidi: embed' is not the
>> same as markup 'dir="rtl"'
>>
>> Css vs markup FAQ [3] says (and I strongly agree):
>> "You should always use dedicated bidi markup to describe your content,
>> where markup is available [...] because directionality is an integral
>> part of the document structure." This rule seems violated in the above
>> example.
>>
>> Well... why change writing direction when content is all English?
>> But imagine one of the <p> contains a strong RTL char.
>>
>> The two cases are still different. In the second case (dir="rtl"), the
>> result is like if all <p>s are inline elements, i.e. all inner <p>s are
>> removed.
>> Please try it: http://www.w3c.org.ma/Tests/displayInline.html
>>
>> So, the rule seems to be (grossly paraphrased):
>> For inline elements, CSS direction property applies to the ordering of
>> elements as well as to their content. On the other hand, markup dir
>> attribute applies only to the content of these elements juxtaposed
>> together.
>>
>> Any opinion?
>>
>> [1] http://www.w3c.org.ma/Tests/temp-ar-index.html
>> [2] http://www.w3.org/
>> [3] http://www.w3.org/International/questions/qa-bidi-css-markup
>>
>>
>> -----------------------------
>> Note incidently, that elements displayed inline and floated right, will
>> flow (by side effect) from right to left, whatever direction is
>> specified. Does float style (*cancel*) direction style?
>>
>> Try it: http://www.w3c.org.ma/Tests/inlineFloat.html
>>
>>
>> Best regards,
>>
>> Najib
>>
>>
>> --
>> Najib TOUNSI (tounsi at w3.org)
>> W3C Office in Morocco (http://www.w3c.org.ma/)
>> Ecole Mohammadia d'Ingénieurs, BP. 765 Agdal-RABAT Morocco
>> Phone : +212 (0) 537 68 71 50 Fax : +212 (0) 537 77 88 53
>> Mobile: +212 (0) 661 22 00 30
>>
>>
>>
>>
>>
>
>
>
>
>

From forum: w3.org - www-international

Last call for comments on Choosing a language tag

2009-11-26T10:05:52Z

http://www.w3.org/International/questions/qa-choosing-language-tags

The i18n WG feels that this document is ready for publication, and incorporates all feedback so far sent in during the wide review phase. We will publish it in a few days time.

If you have more feedback on the document, please send it immediately, as we do not want to have to make changes after publication.

Thank you.

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

From forum: w3.org - www-international

RE: More best practices for RTL scripts (markup vs CSS for bidi).

2009-11-26T08:28:24Z

Najib,

I think it's because your CSS is not applying direction in the same way as
your non-CSS example. I think that to get equivalence between a and b you
should use

.a { direction: rtl; unicode-bidi: embed;}
.a p {display:inline; }
.b p {display:inline;}

If you use that CSS, the results look identical. This is because the dir
attribute is used on the div, not on the p elements, however you were trying
to apply the direction property, using CSS, to inline elements. Only by
applying to block elements will you get the right alignment.

Does that make sense?

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

> -----Original Message-----
> From: public-i18n-core-request@... [mailto:public-i18n-core-
> request@...] On Behalf Of Najib Tounsi
> Sent: 25 November 2009 17:40
> To: public-i18n-core@...; 'WWW International'
> Subject: More best practices for RTL scripts (markup vs CSS for bidi).
>
> Dear all, and bidi experts
>
> When trying to localize [1] the new W3C homepage style [2], I came
> across something worth to note.
>
>
> HTML markup (dir="rtl") doesn't have the same effect as CSS (direction:
> rtl;unicode-bidi: embed;)
>
> Some time you want your block-element to display inline (e.g. for
> menu-like effect). However, by default this block elements flow from
> left to right. So to make them flow from right-to left, you want to use
> HTML markup (dir="rtl"). It doesn't work. You should use CSS properties
> (direction: rtl; unicode-bidi: embed;) to get the desired effect.
>
> with the following style:
>
> <style type="text/css">
> .a p {display:inline; direction: rtl; unicode-bidi: embed}
> .b p {display:inline;}
> </style>
>
> the HTML code (case-1):
>
> <div class="a">
> <p>display</p>
> <p>in</p>
> <p>line</p>
> </div>
>
> results in
> line in display
>
> while (case-2):
>
> <div class="b" dir="rtl">
> <p>display</p>
> <p>in</p>
> <p>line</p>
> </div>
>
> will result in (right justified)
> display in line
>
>
> The point is: Why CSS 'direction: rtl; unicode-bidi: embed' is not the
> same as markup 'dir="rtl"'
>
> Css vs markup FAQ [3] says (and I strongly agree):
> "You should always use dedicated bidi markup to describe your content,
> where markup is available [...] because directionality is an integral
> part of the document structure." This rule seems violated in the above
> example.
>
> Well... why change writing direction when content is all English?
> But imagine one of the <p> contains a strong RTL char.
>
> The two cases are still different. In the second case (dir="rtl"), the
> result is like if all <p>s are inline elements, i.e. all inner <p>s are
> removed.
> Please try it: http://www.w3c.org.ma/Tests/displayInline.html
>
> So, the rule seems to be (grossly paraphrased):
> For inline elements, CSS direction property applies to the ordering of
> elements as well as to their content. On the other hand, markup dir
> attribute applies only to the content of these elements juxtaposed
> together.
>
> Any opinion?
>
> [1] http://www.w3c.org.ma/Tests/temp-ar-index.html
> [2] http://www.w3.org/
> [3] http://www.w3.org/International/questions/qa-bidi-css-markup
>
>
> -----------------------------
> Note incidently, that elements displayed inline and floated right, will
> flow (by side effect) from right to left, whatever direction is
> specified. Does float style (*cancel*) direction style?
>
> Try it: http://www.w3c.org.ma/Tests/inlineFloat.html
>
>
> Best regards,
>
> Najib
>
>
> --
> Najib TOUNSI (tounsi at w3.org)
> W3C Office in Morocco (http://www.w3c.org.ma/)
> Ecole Mohammadia d'Ingénieurs, BP. 765 Agdal-RABAT Morocco
> Phone : +212 (0) 537 68 71 50 Fax : +212 (0) 537 77 88 53
> Mobile: +212 (0) 661 22 00 30
>
>
>
>

From forum: w3.org - www-international

Re: More best practices for RTL scripts (markup vs CSS for bidi).

2009-11-26T07:09:32Z

Actually the reality is worse. Below is your page drawn in Gecko (Firefox) on the left and Webkit (Safari) on the right:

There is a thread on this list started by Aharon from Google that talks about exactly theses sort of issues that has received too little discussion. The real problem is that the HTML standard is not explicit enough on what should happen so you will get different results on different browsers.

Your example is in a fuzzy area. As far as the markup is concerned there are three distinct paragraphs but for the user there is one sentence. According to the HTML standard, the elements should be ordered according to the Unicode bidi algorithm, however that algorithm has nothing to say about what to do when lines of a paragraph are drawn inline. I would personally say that the Gecko engine is doing the right thing in this case.

regards

Adil

On 25/11/2009 17:40, Najib Tounsi wrote:

Dear all, and bidi experts

When trying to localize [1] the new W3C homepage style [2], I came across something worth to note.

HTML markup (dir="rtl") doesn't have the same effect as CSS (direction: rtl;unicode-bidi: embed;)

Some time you want your block-element to display inline (e.g. for menu-like effect). However, by default this block elements flow from left to right. So to make them flow from right-to left, you want to use HTML markup (dir="rtl"). It doesn't work. You should use CSS properties
(direction: rtl; unicode-bidi: embed;) to get the desired effect.

with the following style:

<style type="text/css">
.a p {display:inline; direction: rtl; unicode-bidi: embed}
.b p {display:inline;}
</style>

the HTML code (case-1):

<div class="a">
<p>display</p>
<p>in</p>
<p>line</p>
</div>

results in
line in display

while (case-2):

<div class="b" dir="rtl">
<p>display</p>
<p>in</p>
<p>line</p>
</div>

will result in (right justified)
display in line

The point is: Why CSS 'direction: rtl; unicode-bidi: embed' is not the same as markup 'dir="rtl"'

Css vs markup FAQ [3] says (and I strongly agree):
"You should always use dedicated bidi markup to describe your content, where markup is available [...] because directionality is an integral part of the document structure." This rule seems violated in the above example.

Well... why change writing direction when content is all English?
But imagine one of the <p> contains a strong RTL char.

The two cases are still different. In the second case (dir="rtl"), the result is like if all <p>s are inline elements, i.e. all inner <p>s are removed.
Please try it: http://www.w3c.org.ma/Tests/displayInline.html

So, the rule seems to be (grossly paraphrased):
For inline elements, CSS direction property applies to the ordering of elements as well as to their content. On the other hand, markup dir attribute applies only to the content of these elements juxtaposed together.

Any opinion?

[1] http://www.w3c.org.ma/Tests/temp-ar-index.html
[2] http://www.w3.org/
[3] http://www.w3.org/International/questions/qa-bidi-css-markup

-----------------------------
Note incidently, that elements displayed inline and floated right, will flow (by side effect) from right to left, whatever direction is specified. Does float style (*cancel*) direction style?

Try it: http://www.w3c.org.ma/Tests/inlineFloat.html

Best regards,

Najib

From forum: w3.org - www-international

RE: More best practices for RTL scripts (markup vs CSS for bidi).

2009-11-25T15:14:06Z

Hi, I've always assumed that float overrode directionality--except that the directionality of the text within the block will not be changed by float alignment.

I hope this answers your question.

Sorry to right a hurried response.

I'll look over this in more detail hopefully over the holiday (holiday here anyway and one of my favorites).

Best wishes,

C. E. Whitehead
cewcathar@...

> Date: Wed, 25 Nov 2009 17:40:25 +0000
> From: ntounsi@...
> To: public-i18n-core@...; www-international@...
> Subject: More best practices for RTL scripts (markup vs CSS for bidi).
>
> Dear all, and bidi experts
>
> When trying to localize [1] the new W3C homepage style [2], I came
> across something worth to note.
>
>
> HTML markup (dir="rtl") doesn't have the same effect as CSS (direction:
> rtl;unicode-bidi: embed;)
>
> Some time you want your block-element to display inline (e.g. for
> menu-like effect). However, by default this block elements flow from
> left to right. So to make them flow from right-to left, you want to use
> HTML markup (dir="rtl"). It doesn't work. You should use CSS properties
> (direction: rtl; unicode-bidi: embed;) to get the desired effect.
>
> with the following style:
>
> <style type="text/css">
> .a p {display:inline; direction: rtl; unicode-bidi: embed}
> .b p {display:inline;}
> </style>
>
> the HTML code (case-1):
>
> <div class="a">
> <p>display</p>
> <p>in</p>
> <p>line</p>
> </div>
>
> results in
> line in display
>
> while (case-2):
>
> <div class="b" dir="rtl">
> <p>display</p>
> <p>in</p>
> <p>line</p>
> </div>
>
> will result in (right justified)
> display in line
>
>
> The point is: Why CSS 'direction: rtl; unicode-bidi: embed' is not the
> same as markup 'dir="rtl"'
>
> Css vs markup FAQ [3] says (and I strongly agree):
> "You should always use dedicated bidi markup to describe your content,
> where markup is available [...] because directionality is an integral
> part of the document structure." This rule seems violated in the above
> example.
>
> Well... why change writing direction when content is all English?
> But imagine one of the <p> contains a strong RTL char.
>
> The two cases are still different. In the second case (dir="rtl"), the
> result is like if all <p>s are inline elements, i.e. all inner <p>s are
> removed.
> Please try it: http://www.w3c.org.ma/Tests/displayInline.html
>
> So, the rule seems to be (grossly paraphrased):
> For inline elements, CSS direction property applies to the ordering of
> elements as well as to their content. On the other hand, markup dir
> attribute applies only to the content of these elements juxtaposed
> together.
>
> Any opinion?
>
> [1] http://www.w3c.org.ma/Tests/temp-ar-index.html
> [2] http://www.w3.org/
> [3] http://www.w3.org/International/questions/qa-bidi-css-markup
>
>
> -----------------------------
> Note incidently, that elements displayed inline and floated right, will
> flow (by side effect) from right to left, whatever direction is
> specified. Does float style (*cancel*) direction style?
>
> Try it: http://www.w3c.org.ma/Tests/inlineFloat.html
>
>
> Best regards,
>
> Najib
>
>
> --
> Najib TOUNSI (tounsi at w3.org)
> W3C Office in Morocco (http://www.w3c.org.ma/)
> Ecole Mohammadia d'Ingénieurs, BP. 765 Agdal-RABAT Morocco
> Phone : +212 (0) 537 68 71 50 Fax : +212 (0) 537 77 88 53
> Mobile: +212 (0) 661 22 00 30
>
>
>
>
>

From forum: w3.org - www-international

More best practices for RTL scripts (markup vs CSS for bidi).

2009-11-25T09:40:25Z

Dear all, and bidi experts

When trying to localize [1] the new W3C homepage style [2], I came
across something worth to note.

HTML markup (dir="rtl") doesn't have the same effect as CSS (direction:
rtl;unicode-bidi: embed;)

Some time you want your block-element to display inline (e.g. for
menu-like effect). However, by default this block elements flow from
left to right. So to make them flow from right-to left, you want to use
HTML markup (dir="rtl"). It doesn't work. You should use CSS properties
(direction: rtl; unicode-bidi: embed;) to get the desired effect.

with the following style:

<style type="text/css">
.a p {display:inline; direction: rtl; unicode-bidi: embed}
.b p {display:inline;}
</style>

the HTML code (case-1):

<div class="a">
<p>display</p>
<p>in</p>
<p>line</p>
</div>

results in
line in display

while (case-2):

<div class="b" dir="rtl">
<p>display</p>
<p>in</p>
<p>line</p>
</div>

will result in (right justified)
display in line

The point is: Why CSS 'direction: rtl; unicode-bidi: embed' is not the
same as markup 'dir="rtl"'

Css vs markup FAQ [3] says (and I strongly agree):
"You should always use dedicated bidi markup to describe your content,
where markup is available [...] because directionality is an integral
part of the document structure." This rule seems violated in the above
example.

Well... why change writing direction when content is all English?
But imagine one of the <p> contains a strong RTL char.

The two cases are still different. In the second case (dir="rtl"), the
result is like if all <p>s are inline elements, i.e. all inner <p>s are
removed.
Please try it: http://www.w3c.org.ma/Tests/displayInline.html

So, the rule seems to be (grossly paraphrased):
For inline elements, CSS direction property applies to the ordering of
elements as well as to their content. On the other hand, markup dir
attribute applies only to the content of these elements juxtaposed
together.

Any opinion?

[1] http://www.w3c.org.ma/Tests/temp-ar-index.html
[2] http://www.w3.org/
[3] http://www.w3.org/International/questions/qa-bidi-css-markup

-----------------------------
Note incidently, that elements displayed inline and floated right, will
flow (by side effect) from right to left, whatever direction is
specified. Does float style (*cancel*) direction style?

Try it: http://www.w3c.org.ma/Tests/inlineFloat.html

Best regards,

Najib

--
Najib TOUNSI (tounsi at w3.org)
W3C Office in Morocco (http://www.w3c.org.ma/)
Ecole Mohammadia d'Ingénieurs, BP. 765 Agdal-RABAT Morocco
Phone : +212 (0) 537 68 71 50 Fax : +212 (0) 537 77 88 53
Mobile: +212 (0) 661 22 00 30

From forum: w3.org - www-international

RE: Article for wide review: Choosing a language tag

2009-11-25T05:00:37Z

John,

Thanks for these comments. Notes below. Changes done with change marks at
http://www.w3.org/International/questions/qa-choosing-language-tags

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

> -----Original Message-----
> From: www-international-request@... [mailto:www-international-
> request@...] On Behalf Of John Cowan
> Sent: 10 October 2009 01:18
> To: www-international@...
> Subject: Re: Article for wide review: Choosing a language tag
>
> > http://www.w3.org/International/questions/qa-choosing-language-tags
> >
> > Comments are being sought on this article prior to final release. Please
> > send any comments to www-international@... (subscribe). We expect
> > to publish a final version in one to two weeks.
>
> In Decision 1, the section on macrolanguages should explain that
> macrolanguage subtags may be used in the same way, and with the same
> considerations, as collection subtags. This is quite apart from their
> use with extlang subtags.

Done. (And introduced Collections before, rather than after, to help with
that.)

>
> In Decision 2:
>
> a) It's a mistake to conflate "[p]rimary language subtags that can be
> used with extended language subtags" with macrolanguages. Only six
> ('ar', 'kok', 'ms', 'sw', 'uz', 'zh') of the 58 current macrolanguages,
> plus 'sgn', fall into this category. Find or invent another term to
> avoid confusion.

Hopefully this is now fixed.

>
> b) Explain clearly that the extlang tags are always identical to their
> primary language subtags, so "kok-gom" can be replaced by "gom" even if
> you don't know what 'kok' or 'gom' mean.

Done.

>
> In Decision 4, for "regional areas", which is vague, read "regions
> containing more than one country" or "multinational regions".

Done.

Cheers,
RI
>
> --
> And it was said that ever after, if any John Cowan
> man looked in that Stone, unless he had a cowan@...
> great strength of will to turn it to other
http://ccil.org/~cowan
> purpose, he saw only two aged hands withering
> in flame. --"The Pyre of Denethor"

From forum: w3.org - www-international

RE: Article for wide review: Choosing a language tag

2009-11-24T15:41:39Z

Hi. Sorry for my wordy comments; and yes, thanks for your search utility; it is fast.
> From: ishida@...

> To: cewcathar@...; www-international@...
> Date: Tue, 24 Nov 2009 21:00:00 +0000
> Subject: RE: Article for wide review: Choosing a language tag
>
> > -----Original Message-----
> > From: CE Whitehead [mailto:cewcathar@...]
> > Sent: 12 October 2009 19:53
> > To: ishida@...; www-international@...
> > Subject: RE: Article for wide review: Choosing a language tag
> >
> >
> >
> > Hi, I've read all but the last two sections (on private use and grandfathered
> > subtags) of "Choosing a Language Tag"
> >
> > ( http://www.w3.org/International/questions/qa-choosing-language-tags);
> >
> > most of my comments are on the English, although a few are on content:
> >
> >
> >
> >
> > * * *
> >
> >
> >
> >
> >
> > Answer to Question at top, "Which language tag is . . . ?", par 4
> > (ORDER/ORGANIZATION)
> >
> >
> >
> > "Particular thanks are due to Addison Phillips and Mark Davis, authors of BCP
> > 47, for help in producing this article."
> >
> >
> >
> > { COMMENT: this is not really part of the answer to the above question
> > although Mark Davis and Addison Phillips have worked hard on BP 47;
> > If Mark and Addison have worked hard on the whole article, this should be
> > moved to near the top of the article, immediately following the opening
> > paragraph, and before the first question is presented!}
> >
> >
> >
> > Answer to Question at top, "Which language tag is . . . ?" par 7, last sentence
> > (ENGLISH)
> >
> >
>
> Moved it rather than tried to explain why I put it there.

Sorry if I aggravated you here.

>
>
> >
> > "Your search will have matched against the Description field. Check that the
> > type of this record is language. What you are looking for is the value in the
> > Subtag field, ie. fr."
> >
> >
> > { COMMENT: I would have liked to have seen at least single quotation marks
> > around 'fr'.
>
> I prefer to keep with the current approach, used throughout the article.
>
> > Also, is it clear from the last sentence that 'fr' is going to be used in the
> > language tag??
>
> I think it is, if you read the earlier text.

I'll look at this again.

>
> > >= "The language tag is formed using the value in the subtag field, which is
> > 'fr'."
> > }
> >
> >
> >
> > Answer to Question at top, "Which language tag is . . . ?", par 8, sentence 1
> > (ENGLISH)
> >
> >
> >
> > "The rest of this article will provide advice for choosing primary language
> > and possibly other types of subtag. Note that not all the decisions about how
> > to create a language tag are straightforward. There are circumstances where
> > usage will dictate which of various possibilities you should follow."
> >
> >
> >
> > { COMMENT: Because there may be more than one subtag following the
> > primary language subtag in a language tag, I think "subtags" should be
> > plural;
> > also I think that "primary language subtag" might benefit from a definite
> > article since there is one primary language subtag"--thus it is in some sense
> > specific
> >
> >
> > >=
> > "The rest of this article will provide advice for choosing the primary language
> > and possibly other types of subtags."
> > }
>
> Changed to
> The rest of this article will provide advice for choosing primary language subtags and, where needed, other types of subtag.
>
> >
> >
> >
> > Answer to Question at top, "Which language tag is . . . ?", par 9 CONTENT
> >
> >
> > "There are tools available which provide additional help while searching the
> > registry, such as Richard Ishida's Language Subtag Lookup tool."
> >
> >
> > {COMMENT: this could be more specific (we just discussed these at ietf-
> > languages):
> >
> >
> >
> > for example,
> >
> > >= "There are tools which search through a copy of the registry for a
> > particular description, etc. . . . "
> >
> > You might even go on to say, "a reasonably up-to-date copy of the
> > registry. . ."
>
> My tool provides more help than just searching for a particular description
>

Yes, I love your tool because it is so fast to search; but it is not updated every night is it?
That's all I was saying. I realize that the size of the registry makes updating your copy of it the more cumbersome
(& I should not talk as I have a ton of updates to install on my computer--I'm going to update tonight though).

Best,

C. E. Whitehead
cewcathar@...

> >
> > }
> >
> >
> > * * *
> > Decision 1, par 2, first bullet CONTENT
> >
> >
> >
> > "'Often it is not clear which language identifier to use. For example, what
> > most people call Punjabi in Pakistan actually has the code 'lah', and formal
> > name 'Lahnda'.'"
> >
> >
> >
> > {COMMENTS:
> > ??? As you note in your utlity
> > http://rishida.net/utils/subtags/index.php?find=&lookup=lah&submit=Look+
> > up&list=0&check=
> >
> > 'lah' (lahnda) is a macrolanguage and punjabi as used in Pakistan can get a
> > more specific subtag!
> > ?? or am I confused; lahnda is used widely and not just in Pakistan; punjabi or
> > western panjabi is only used in Pakistan; several other varieties of lahnda are
> > used in Pakistan however but these are not called Punjabi? So is this the best
> > example??
> >
> > Another example might be Persian-Farsi-Dari: if you search for 'Persian,' you
> > want a specific language subtag, 'pes' probably (identified/described as
> > 'farsi'; I once thought that 'Western Persian' was going to be added as a
> > second description field for 'pes' but I guess this is a can of worms right now
> > and has already been discussed to the fullest extent possible at ietf-
> > languages.; see:
> >
> > http://www.alvestrand.no/pipermail/ietf-languages/2008-
> > December/008715.html
> >
> > }
> >
> >
> > * * *
> >
> >
> > Decision 1, par 2, first bullet, par 2 ENGLISH
> >
> >
> > "You could look up language information in the SIL Ethnologue and cross-
> > referencing with Wikipedia.
> >
> >
> > { COMMENTS:
> > ??? "cross-referencing" has no direct object here but should normally take
> > one; also it's not even clear whether it's the audience of this sentence
> > or SIL Ethnologue who will be doing the cross-referencing (that is the subject
> > antecedent is not clear)
> > perhaps because the two verbs ("look up" and "cross-referencing") are not
> > syntactically parallel--which they should be if 'you' is the subject for both!
> > >= "You could look up language information in the SIL Ethnologue and
> > cross-reference it with information in Wikipedia."
> > }
> >
>
> Fixed.
>
> >
> >
> > Decision 1, par 2, second bullet, par 2 PUNCTUATION
> >
> >
> >
> > "For example, ku (Kurdish) is a macrolanguage that encompasses ckb
> > (Central Kurdish), kmr (Northern Kurdish), and sdh (Southern Kurdish),"
> >
> >
> >
> > { COMMENT:
> >
> > There should be a full-stop, and not a comma, at the end of the above
> > paragraph.
> > }
> >
>
> Fixed.
>
> >
> >
> > Decision 1, par 2, third bullet, par 2 ENGLISH
> >
> >
> >
> > "You should look for a more specific subtag for the language you are
> > wanting to use. Unfortunately, the registry doesn't provide any pointers for
> > this."
> >
> >
> > { COMMENT: Awkward; why "you are wanting"? Why not just ""you wish"?
> > Also "use" sound vague to me; I prefer "specify" here. Also, what "registry"?
> > Do you mean "the language subtag registry"/BP 47 or do you mean this Q&A
> > article?
>
> ?? This article isn't a registry?
>
> >
> >
> >
> > >= "You should look for a more specific subtag for the language you wish to
> > specify. Unfortunately, this registry {???this article??? the language subtag
> > registry???} does not provide any pointers for doing so."
> > }
>
> Changed to
> You should look for a more specific subtag for the language you are interested in

>
> >
> >
> >
> > * * *
> >
> >
> >
> > Decision 5, par 4, first bullet, par 2 ENGLISH
> >
> >
> >
> > "If you have a good reason, you could use a variant subtag with different
> > subtags, eg. cmn-Latn-pinyin would be a legal to say Mandarin Chinese
> > written with pinyin."
> >
> >
> > { COMMENT: ?? "would be a legal to say ???" Where is the noun that must
> > follow an article such as 'a'?? I only see an adjective, 'legal;'
> > I suppose you mean 'legal way'??
> >
> > >= "would be a legal {or proper??} way to indicate Mandarin Chinese content
> > written using the pinyin romanization system."
> >
> >
> > Hope I did not get too wordy.
> > }
>
> Fixed.
>
>
> >
> >
> > Decision 5, par 4, first bullet, par 3 ENGLISH
> >
> >
> >
> > "Although zh, bo and Latn are specified, this is a minimum requirement. It is
> > also possible to include other subtags, such as a region subtag, in the
> > language tag (where appropriate), eg. zh-Latn-TW-pinyin."
> >
> >
> >
> > { COMMENT for clarity, I'd say (even though you may feel you have said this
> > above),
> > "Although either zh or bo followed by Latn are specified . .>"
> > }
>
> I'd rather leave as is.
>
>
>
> Thank you.
> RI
>
> >
> >
> >
> > Best,
> >
> >
> >
> > C. E. Whitehead
> >
> > cewcathar@...
> >
> > > From: ishida@...
> > > To: www-international@...
> > > Date: Fri, 9 Oct 2009 19:25:29 +0100
> > > Subject: Article for wide review: Choosing a language tag
> > >
> > >
> > > http://www.w3.org/International/questions/qa-choosing-language-tags
> > >
> > >
> > > Comments are being sought on this article prior to final release. Please
> > send any comments to www-international@... (subscribe). We expect to
> > publish a final version in one to two weeks.
> > >
> > >
> > >
> > >
> > >
> > > ============
> > > Richard Ishida
> > > Internationalization Lead
> > > W3C (World Wide Web Consortium)
> > >
> > > http://www.w3.org/International/
> > > http://rishida.net/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>

From forum: w3.org - www-international

RE: Article for wide review: Choosing a language tag

2009-11-24T13:00:00Z

> -----Original Message-----
> From: CE Whitehead [mailto:cewcathar@...]
> Sent: 12 October 2009 19:53
> To: ishida@...; www-international@...
> Subject: RE: Article for wide review: Choosing a language tag
>
>
>
> Hi, I've read all but the last two sections (on private use and grandfathered
> subtags) of "Choosing a Language Tag"
>
> ( http://www.w3.org/International/questions/qa-choosing-language-tags);
>
> most of my comments are on the English, although a few are on content:
>
>
>
>
> * * *
>
>
>
>
>
> Answer to Question at top, "Which language tag is . . . ?", par 4
> (ORDER/ORGANIZATION)
>
>
>
> "Particular thanks are due to Addison Phillips and Mark Davis, authors of BCP
> 47, for help in producing this article."
>
>
>
> { COMMENT: this is not really part of the answer to the above question
> although Mark Davis and Addison Phillips have worked hard on BP 47;
> If Mark and Addison have worked hard on the whole article, this should be
> moved to near the top of the article, immediately following the opening
> paragraph, and before the first question is presented!}
>
>
>
> Answer to Question at top, "Which language tag is . . . ?" par 7, last sentence
> (ENGLISH)
>
>

Moved it rather than tried to explain why I put it there.

>
> "Your search will have matched against the Description field. Check that the
> type of this record is language. What you are looking for is the value in the
> Subtag field, ie. fr."
>
>
> { COMMENT: I would have liked to have seen at least single quotation marks
> around 'fr'.

I prefer to keep with the current approach, used throughout the article.

> Also, is it clear from the last sentence that 'fr' is going to be used in the
> language tag??

I think it is, if you read the earlier text.

> >= "The language tag is formed using the value in the subtag field, which is
> 'fr'."
> }
>
>
>
> Answer to Question at top, "Which language tag is . . . ?", par 8, sentence 1
> (ENGLISH)
>
>
>
> "The rest of this article will provide advice for choosing primary language
> and possibly other types of subtag. Note that not all the decisions about how
> to create a language tag are straightforward. There are circumstances where
> usage will dictate which of various possibilities you should follow."
>
>
>
> { COMMENT: Because there may be more than one subtag following the
> primary language subtag in a language tag, I think "subtags" should be
> plural;
> also I think that "primary language subtag" might benefit from a definite
> article since there is one primary language subtag"--thus it is in some sense
> specific
>
>
> >=
> "The rest of this article will provide advice for choosing the primary language
> and possibly other types of subtags."
> }

Changed to
The rest of this article will provide advice for choosing primary language subtags and, where needed, other types of subtag.

>
>
>
> Answer to Question at top, "Which language tag is . . . ?", par 9 CONTENT
>
>
> "There are tools available which provide additional help while searching the
> registry, such as Richard Ishida's Language Subtag Lookup tool."
>
>
> {COMMENT: this could be more specific (we just discussed these at ietf-
> languages):
>
>
>
> for example,
>
> >= "There are tools which search through a copy of the registry for a
> particular description, etc. . . . "
>
> You might even go on to say, "a reasonably up-to-date copy of the
> registry. . ."

My tool provides more help than just searching for a particular description

>
> }
>
>
> * * *
> Decision 1, par 2, first bullet CONTENT
>
>
>
> "'Often it is not clear which language identifier to use. For example, what
> most people call Punjabi in Pakistan actually has the code 'lah', and formal
> name 'Lahnda'.'"
>
>
>
> {COMMENTS:
> ??? As you note in your utlity
> http://rishida.net/utils/subtags/index.php?find=&lookup=lah&submit=Look+
> up&list=0&check=
>
> 'lah' (lahnda) is a macrolanguage and punjabi as used in Pakistan can get a
> more specific subtag!
> ?? or am I confused; lahnda is used widely and not just in Pakistan; punjabi or
> western panjabi is only used in Pakistan; several other varieties of lahnda are
> used in Pakistan however but these are not called Punjabi? So is this the best
> example??
>
> Another example might be Persian-Farsi-Dari: if you search for 'Persian,' you
> want a specific language subtag, 'pes' probably (identified/described as
> 'farsi'; I once thought that 'Western Persian' was going to be added as a
> second description field for 'pes' but I guess this is a can of worms right now
> and has already been discussed to the fullest extent possible at ietf-
> languages.; see:
>
> http://www.alvestrand.no/pipermail/ietf-languages/2008-
> December/008715.html
>
> }
>
>
> * * *
>
>
> Decision 1, par 2, first bullet, par 2 ENGLISH
>
>
> "You could look up language information in the SIL Ethnologue and cross-
> referencing with Wikipedia.
>
>
> { COMMENTS:
> ??? "cross-referencing" has no direct object here but should normally take
> one; also it's not even clear whether it's the audience of this sentence
> or SIL Ethnologue who will be doing the cross-referencing (that is the subject
> antecedent is not clear)
> perhaps because the two verbs ("look up" and "cross-referencing") are not
> syntactically parallel--which they should be if 'you' is the subject for both!
> >= "You could look up language information in the SIL Ethnologue and
> cross-reference it with information in Wikipedia."
> }
>

Fixed.

>
>
> Decision 1, par 2, second bullet, par 2 PUNCTUATION
>
>
>
> "For example, ku (Kurdish) is a macrolanguage that encompasses ckb
> (Central Kurdish), kmr (Northern Kurdish), and sdh (Southern Kurdish),"
>
>
>
> { COMMENT:
>
> There should be a full-stop, and not a comma, at the end of the above
> paragraph.
> }
>

Fixed.

>
>
> Decision 1, par 2, third bullet, par 2 ENGLISH
>
>
>
> "You should look for a more specific subtag for the language you are
> wanting to use. Unfortunately, the registry doesn't provide any pointers for
> this."
>
>
> { COMMENT: Awkward; why "you are wanting"? Why not just ""you wish"?
> Also "use" sound vague to me; I prefer "specify" here. Also, what "registry"?
> Do you mean "the language subtag registry"/BP 47 or do you mean this Q&A
> article?

?? This article isn't a registry?

>
>
>
> >= "You should look for a more specific subtag for the language you wish to
> specify. Unfortunately, this registry {???this article??? the language subtag
> registry???} does not provide any pointers for doing so."
> }

Changed to
You should look for a more specific subtag for the language you are interested in

>
>
>
> * * *
>
>
>
> Decision 5, par 4, first bullet, par 2 ENGLISH
>
>
>
> "If you have a good reason, you could use a variant subtag with different
> subtags, eg. cmn-Latn-pinyin would be a legal to say Mandarin Chinese
> written with pinyin."
>
>
> { COMMENT: ?? "would be a legal to say ???" Where is the noun that must
> follow an article such as 'a'?? I only see an adjective, 'legal;'
> I suppose you mean 'legal way'??
>
> >= "would be a legal {or proper??} way to indicate Mandarin Chinese content
> written using the pinyin romanization system."
>
>
> Hope I did not get too wordy.
> }

Fixed.

>
>
> Decision 5, par 4, first bullet, par 3 ENGLISH
>
>
>
> "Although zh, bo and Latn are specified, this is a minimum requirement. It is
> also possible to include other subtags, such as a region subtag, in the
> language tag (where appropriate), eg. zh-Latn-TW-pinyin."
>
>
>
> { COMMENT for clarity, I'd say (even though you may feel you have said this
> above),
> "Although either zh or bo followed by Latn are specified . .>"
> }

I'd rather leave as is.

Thank you.
RI

>
>
>
> Best,
>
>
>
> C. E. Whitehead
>
> cewcathar@...
>
> > From: ishida@...
> > To: www-international@...
> > Date: Fri, 9 Oct 2009 19:25:29 +0100
> > Subject: Article for wide review: Choosing a language tag
> >
> >
> > http://www.w3.org/International/questions/qa-choosing-language-tags
> >
> >
> > Comments are being sought on this article prior to final release. Please
> send any comments to www-international@... (subscribe). We expect to
> publish a final version in one to two weeks.
> >
> >
> >
> >
> >
> > ============
> > Richard Ishida
> > Internationalization Lead
> > W3C (World Wide Web Consortium)
> >
> > http://www.w3.org/International/
> > http://rishida.net/
> >
> >
> >
> >
> >
> >
> >

From forum: w3.org - www-international

Character Collections

2009-11-14T17:39:15Z

Inspired by "A Notation for Character Collections for the WWW" (W3C Note),
JTC1 has developed 19757-7 Character Repertoire Description Language.

I do not know if 19757-7 will be publicly available. But an implementation
is already available at:

http://www.asahi-net.or.jp/~eb2m-mrt/crepdl/crepdl.zip

This works in Windows. I believe that it requires .Net framework 2.0.

This zip file contains an executable file and test schemas. Most of the
test schemas are borrowed from 19757-7, and they cover 8859-15, 8859-6,
Armenian, Malayalam, kyoiku1, and kyoiku2.

The syntax of the command is as follows:

CREPDL schemaURI textFileName

The textFileName may be followed by an encoding name of .Net. This
program reports either True, False, or Unknown.

Your feedback is very much welcome.

I am hoping that XSD, RELAX NG, OOXML, ODF, Schematron, and some W3C
specs (such as forms) use CREPDL for checking characters.

If you can read Japanese, the mail thread starting at :

http://www2.xml.gr.jp/log.html?MLID=xmlmoji&TID=1809&F=0&L=10&R=1

is useful.

Cheers,
Makoto

From forum: w3.org - www-international

Slides of IAB presentation on Protocol I18N at IETF Technical Plenary

2009-11-13T00:55:36Z

[I'm using bcc because I'm sending this to various lists that I think
should be interested.]

For those who didn't attended yesterday's IETF Technical Plenary (or
like me, listened to it on the audio feed), here is a link to the slides
from the IAB presentation on Protocol Internationalization and Character
Encoding:

http://www.ietf.org/proceedings/09nov/slides/plenaryt-1.pdf

Regards, Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...

From forum: w3.org - www-international

Proposed update to Styling using the Language Attribute article

2009-11-12T08:55:35Z

At

http://www.w3.org/International/questions/temp.php

I have made some proposed changes to the article "Styling using the Language Attribute" that include:

- removing the (out of date) information about which browsers support what, in favour of pointing to the latest test results

- adding a section "Using CSS selectors with xml:lang"

- several editorial simplifications of the text and updates of link pointers and further reading

All significant changes outside the new section are marked up.

Any comments before I replace the old version?

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

From forum: w3.org - www-international

Re: A Proposal for HTML Improvements for Bidi, Part 1: Bidi Aspects of Existing HTML Features

2009-11-05T17:20:07Z

Here are my comments on the proposal to improve bidi handling (at http://docs.google.com/Doc?id=dd6f586t_19dg4pkqqc):

1.1. <br>, <hr>, and embedded block elements should "reset" bidi state

I fully understand the motivation behind this but have some reservations.

a) I agree that browsers are inconsistent with the interpretation of the markup and this is a serious issue that must be addressed.

b) I think making <br> reset the bidi state will solve the majority of issues with bidi markup. But, (and this is a big "but") by redefining <br> as a bidi break we are removing the possibility from HTML for allowing an author to force a line break in markup without resetting the bidi state. I think this is wrong. There are cases (e.g. making a two line headline for a news article) where an author or automated software would want to insert a manual line break that will behave the same way as visual line break without resetting the bidi state. This case would be rarer than the current use of <br> but still possible.

Ideally, there should be two forms of <br> - one that resets bidi and one that does not. Speaking without any knowledge of past discussions - my own preference would be for HTML to have a new element that lets me break lines like <br> but would syntactically define a new paragraph. This element would reset the bidi state - and <br> would not. That would mirror the behavior of the Unicode characters - U+2028 Line Separator and U+2029 Paragraph Separator.

1.2. newline and other line-breaking characters should "reset" bidi state in <textarea>, <pre>

OK. except for U+2028 line separator which must be treated by bidi like a white space.

1.5. <option> should support the dir attribute, and be displayed that way in both the dropdown and after being chosen

I would also add the same comment for other grouped elements like <li>. Setting an opposing direction for <li> to its list causes unpredictable results. The picture below shows what happens in Webkit and Gecko for this markup:

<ol class="liststylesquare">
<li dir="rtl">Bullet for list element should be a square glyph</li>
<li>Bullet for list element should be a square glyph</li>
</ol>

regards

Adil

--------------------------------------------------
Adil Allawi
Technical Director
Diwan Software Ltd
37-39 Peckham Rd, London SE5 8UH,UK

Tel: +44 (0)20 7 2525 333
Fax: +44 (0)20 7 2525 444
Mobile: +44 7718 785850	
Adil@...
http://www.diwan.com/
--------------------------------------------------

From forum: w3.org - www-international

Re: what's the language of a document ?

2009-11-04T15:12:56Z

This subject is really periodic like the flu -:) and I hope the HTML5 does not make it worse.

The subject should be "languages" in plural as a document could be multilingual, the processing language must be singular; and both could be undefined.

It has been repeatedly discussed:

http://lists.w3.org/Archives/Public/www-international/2008JulSe/0138.html
http://lists.w3.org/Archives/Public/www-international/2008JulSep/0142.html
http://www.w3.org/TR/1998/NOTE-html-lan-19980313

Regards
Tomas

From forum: w3.org - www-international

RE: Article for wide review: Choosing a language tag

2009-11-04T14:52:51Z

Hi, I previously posted comments on "Choosing a Language Tag" (http://www.w3.org/International/questions/qa-choosing-language-tags
); my original post is at the following link:
http://lists.w3.org/Archives/Public/www-international/2009OctDec/0016.html
I'm sending these comments again; if you've already received them, please disregard this message! (I just thought that maybe they got lost in the shuffle; I realize people might not have had time to go through them!)
Thanks! If you've not yet received them, they are below:
RE: Article for wide review: Choosing a language tag
This message: [ Message body ] [ Respond ] [ More options ]
Related messages: [ Next message ] [ Previous message ] [ In reply to ]
From: CE Whitehead <cewcathar@...>
Date: Mon, 12 Oct 2009 14:52:51 -0400
Message-ID: <BLU109-W283D45AC2558DFF55F03DEB3C80@...>
To: <ishida@...>, <www-international@...>

Hi, I've read all but the last two sections (on private use and grandfathered subtags) of "Choosing a Language Tag"
( http://www.w3.org/International/questions/qa-choosing-language-tags);
most of my comments are on the English, although a few are on content:

* * *

Answer to Question at top, "Which language tag is . . . ?", par 4 (ORDER/ORGANIZATION)

"Particular thanks are due to Addison Phillips and Mark Davis, authors of BCP 47, for help in producing this article."

{ COMMENT: this is not really part of the answer to the above question although Mark Davis and Addison Phillips have worked hard on BP 47;
If Mark and Addison have worked hard on the whole article, this should be moved to near the top of the article, immediately following the opening paragraph, and before the first question is presented!}

Answer to Question at top, "Which language tag is . . . ?" par 7, last sentence (ENGLISH)

"Your search will have matched against the Description field. Check that the type of this record is language. What you are looking for is the value in the Subtag field, ie. fr."

{ COMMENT: I would have liked to have seen at least single quotation marks around 'fr'.
Also, is it clear from the last sentence that 'fr' is going to be used in the language tag??
>= "The language tag is formed using the value in the subtag field, which is 'fr'."
}

Answer to Question at top, "Which language tag is . . . ?", par 8, sentence 1 (ENGLISH)

"The rest of this article will provide advice for choosing primary language and possibly other types of subtag. Note that not all the decisions about how to create a language tag are straightforward. There are circumstances where usage will dictate which of various possibilities you should follow."

{ COMMENT: Because there may be more than one subtag following the primary language subtag in a language tag, I think "subtags" should be plural;
also I think that "primary language subtag" might benefit from a definite article since there is one primary language subtag"--thus it is in some sense specific

>=
"The rest of this article will provide advice for choosing the primary language and possibly other types of subtags."
}

Answer to Question at top, "Which language tag is . . . ?", par 9 CONTENT

"There are tools available which provide additional help while searching the registry, such as Richard Ishida's Language Subtag Lookup tool."

{COMMENT: this could be more specific (we just discussed these at ietf-languages):

for example,
>= "There are tools which search through a copy of the registry for a particular description, etc. . . . "
You might even go on to say, "a reasonably up-to-date copy of the registry. . ."
}

* * *
Decision 1, par 2, first bullet CONTENT

"'Often it is not clear which language identifier to use. For example, what most people call Punjabi in Pakistan actually has the code 'lah', and formal name 'Lahnda'.'"

{COMMENTS:
??? As you note in your utlity
http://rishida.net/utils/subtags/index.php?find=&lookup=lah&submit=Look+up&list=0&check=
'lah' (lahnda) is a macrolanguage and punjabi as used in Pakistan can get a more specific subtag!
?? or am I confused; lahnda is used widely and not just in Pakistan; punjabi or western panjabi is only used in Pakistan; several other varieties of lahnda are used in Pakistan however but these are not called Punjabi? So is this the best example??
Another example might be Persian-Farsi-Dari: if you search for 'Persian,' you want a specific language subtag, 'pes' probably (identified/described as 'farsi'; I once thought that 'Western Persian' was going to be added as a second description field for 'pes' but I guess this is a can of worms right now and has already been discussed to the fullest extent possible at ietf-languages.; see:
http://www.alvestrand.no/pipermail/ietf-languages/2008-December/008715.html
}

* * *

Decision 1, par 2, first bullet, par 2 ENGLISH

"You could look up language information in the SIL Ethnologue and cross-referencing with Wikipedia.

{ COMMENTS:
??? "cross-referencing" has no direct object here but should normally take one; also it's not even clear whether it's the audience of this sentence
or SIL Ethnologue who will be doing the cross-referencing (that is the subject antecedent is not clear)
perhaps because the two verbs ("look up" and "cross-referencing") are not syntactically parallel--which they should be if 'you' is the subject for both!
>= "You could look up language information in the SIL Ethnologue and cross-reference it with information in Wikipedia."
}

Decision 1, par 2, second bullet, par 2 PUNCTUATION

"For example, ku (Kurdish) is a macrolanguage that encompasses ckb (Central Kurdish), kmr (Northern Kurdish), and sdh (Southern Kurdish),"

{ COMMENT:
There should be a full-stop, and not a comma, at the end of the above paragraph.
}

Decision 1, par 2, third bullet, par 2 ENGLISH

"You should look for a more specific subtag for the language you are wanting to use. Unfortunately, the registry doesn't provide any pointers for this."

{ COMMENT: Awkward; why "you are wanting"? Why not just ""you wish"?
Also "use" sound vague to me; I prefer "specify" here. Also, what "registry"? Do you mean "the language subtag registry"/BP 47 or do you mean this Q&A article?

>= "You should look for a more specific subtag for the language you wish to specify. Unfortunately, this registry {???this article??? the language subtag registry???} does not provide any pointers for doing so."
}

* * *

Decision 5, par 4, first bullet, par 2 ENGLISH

"If you have a good reason, you could use a variant subtag with different subtags, eg. cmn-Latn-pinyin would be a legal to say Mandarin Chinese written with pinyin."

{ COMMENT: ?? "would be a legal to say ???" Where is the noun that must follow an article such as 'a'?? I only see an adjective, 'legal;'
I suppose you mean 'legal way'??
>= "would be a legal {or proper??} way to indicate Mandarin Chinese content written using the pinyin romanization system."

Hope I did not get too wordy.
}

Decision 5, par 4, first bullet, par 3 ENGLISH

"Although zh, bo and Latn are specified, this is a minimum requirement. It is also possible to include other subtags, such as a region subtag, in the language tag (where appropriate), eg. zh-Latn-TW-pinyin."

{ COMMENT for clarity, I'd say (even though you may feel you have said this above),
"Although either zh or bo followed by Latn are specified . .>"
}

Best,

C. E. Whitehead
cewcathar@...
> From: ishida@...

> To: www-international@...
> Date: Fri, 9 Oct 2009 19:25:29 +0100
> Subject: Article for wide review: Choosing a language tag
>
>
> http://www.w3.org/International/questions/qa-choosing-language-tags
>
>
> Comments are being sought on this article prior to final release. Please send any comments to www-international@... (subscribe). We expect to publish a final version in one to two weeks.
>
>
>
>
>
> ============
> Richard Ishida
> Internationalization Lead
> W3C (World Wide Web Consortium)
>
> http://www.w3.org/International/
> http://rishida.net/
>

From forum: w3.org - www-international

Hello

2009-11-03T16:09:21Z

Hi - I was prodded by a number of people to join this list after my last talk at the Unicode conference (slides are on my blog http://ironymark.diwan.com/). So here I am, just a quick hello and introduction - just to see if I am really subscribed.

I have been working with Arabic text on computers since 1982 and have implemented bidi support in probably every kind of computer software that you can imagine. I have also worked on Thai, the various Indic scripts, Chinese, Japanese, and German among other languages. I hope I can give some useful feedback to this list.

regards

Adil
--
--------------------------------------------------
Adil Allawi
Technical Director Diwan Software Ltd

From forum: w3.org - www-international

RE: what's the language of a document ?

2009-11-01T10:20:58Z

Hi.

From: textexin@...
To: ishida@...; ian@...
CC: simonp@...; divya.manian@...; martin.kliehm@...; cowan@...; public-html@...; www-international@...; duerst@...
Date: Sat, 31 Oct 2009 18:05:54 -0700
Subject: RE: what's the language of a document ?

>> [4] Establish the rule that multiple values in the place that has precedence equates to lang="".

> Why would you remove information that has been provided?

O.k., I hope that multiple values equate to the first value or ideally to all (in the http and meta content-language headers only for the latter). I think this is the point everyone has said is minor! Best, C. E. Whitehead cewcathar@...

From forum: w3.org - www-international

RE: what's the language of a document ?

2009-10-31T18:05:54Z

Re: [3] Establish the precedence between http vs meta.

I wish we could eliminate this nonsense altogether.

The description of the content of a document should be self-contained within the document and not in the protocol.

The protocol should only ever reflect what is in the document to enable routing and filters etc.

But documents should be self-declared.

[1] Explain clearly that declarations in the http header and the meta element refer to the document as an object, rather than the text in a

specific element (this is what makes the distinction between single and multiple values sensible).

This is contrived.

There is no reason an element cannot contain sub-elements that are in different languages, so why force a single language description.

There is value to letting a processing agent know which languages are included so it can use appropriate rendering rules and have the right resources loaded (eg fonts) as opposed to having it run into a new language and react dynamically.

It is fine to declare that one language is a primary to establish the overall treatment of the text, or to be the default for text without a language declaration, but there is no reason to pretend elements are monolingual when they are not.

[4] Establish the rule that multiple values in the place that has precedence equates to lang="".

Why would you remove information that has been provided?

-----Original Message-----
From: www-international-request@... [mailto:www-international-request@...] On Behalf Of Richard Ishida
Sent: Thursday, October 29, 2009 11:11 AM
To: 'Ian Hickson'
Cc: 'Simon Pieters'; 'Divya Manian'; 'Martin Kliehm'; 'John Cowan'; public-html@...; www-international@...; '"Martin J. Dürst"'
Subject: RE: what's the language of a document ?

Personally, I agree with Martin here. I have spent a long time trying

simplify explanations so that people can understand how to manage the

various different ways of declaring language in HTML (http vs meta vs lang;

html vs xhtml vs xml), and it really concerns me that I will now have to say

"But in html5 things are slightly different again". It's already hard

enough to get people to declare language, and I think that the changes that

come with the current text in html5 will only make things worse by causing

further confusion. On the other hand, I think there may be a way to satisfy

everyone.

We discussed this during the Internationalization WG telecon last night, and

I was actioned to put the following to you and the HTML group on behalf of

the i18n WG.

Our proposal is as follows and is based on the text of the following

sections:

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#d

ocument-wide-default-language

http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#th

e-lang-and-xml:lang-attributes

[1] Explain clearly that declarations in the http header and the meta

element refer to the document as an object, rather than the text in a

specific element (this is what makes the distinction between single and

multiple values sensible).

[2] Continue to recommend that the document-wide default language be defined

by a lang attribute on the html tag, but say that if the lang attribute is

missing and there is a language defined in the http or meta, then those

language declarations can be used to guess the language of the text, if they

contain a single value.

[3] Establish the precedence between http vs meta.

[4] Establish the rule that multiple values in the place that has precedence

equates to lang="".

This is very close to what we already have, but doesn't try to make the meta

declaration a different thing than the http declaration, or change it so

that multiple values are no longer valid. At the same time, it allows

either the http or the meta to provide language information for

text-processing, if the declaration is useable.

We also feel that the spec seems to restrict the use of the term

'document-wide default language' to refer only to a language declared using

the meta, and this is rather odd. We feel that in fact the lang attribute

on the html element also establishes a document-wide default language. (See

the text: "Until the pragma is successfully processed, there is no

document-wide default language.")

PS: I could suggest some changes to the wording, if that helps.

============

Richard Ishida

Internationalization Lead

W3C (World Wide Web Consortium)

http://www.w3.org/International/

http://rishida.net/

> -----Original Message-----

> From: www-international-request@... [mailto:www-international-

> request@...] On Behalf Of "Martin J. Dürst"

> Sent: 27 October 2009 11:09

> To: Ian Hickson

> Cc: Simon Pieters; Divya Manian; Martin Kliehm; John Cowan; <public-

> html@...>; www-international@...

> Subject: Re: what's the language of a document ?

> On 2009/10/27 19:37, Ian Hickson wrote:

> > On Tue, 27 Oct 2009, Simon Pieters wrote:

> >> This doesn't match what's specced for<meta http-equiv=content-

> language

> >> content=foo,bar>.

> >

> > That's intentional, and is based on data about how people actually use

> > that pragma.

> There's always a way to justify inconsistent choices (be it browser

> implementations, 'data' about how people (who?) use some feature (at

> what point in time?),...). But it would be way better to be consistent.

> And there is always a way to justify making choices that everybody

> except those knowing all the details of the spec don't understand. But

> it would be way better to make choices that are easy to understand (e.g.

> http-equiv actually meaning what it says, namely "equivalent to the

> corresponding HTTP header").

> There are lots of cases where over time, people have come to a better

> understanding of how things work. For stuff that authors/producers

> aren't supposed to produce, I don't mind too much that HTML5 is

> hopelessly complex and inconsistent. I can live without remembering it

> all, and can tell others to avoid it. However, for stuff like the above,

> which may be used even by very consciously clean developers, creating

> inconsistencies such the above is a heavy negative legacy.

> Regards, Martin.

> --

> #-# Martin J. Dürst, Professor, Aoyama Gakuin University

> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...

From forum: w3.org - www-international

RE: what's the language of a document ?

2009-10-31T12:45:39Z

Hi! I am sorry; I reread Richard Ishida's post and I finally, finally went to the URL he posted and read about the meta element and the http headers in html 5
(in http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv), and I do not have a disagreement with Richard Ishida's post so much as a question!

Currently, and priot to html 5, the meta element, when it is identified as http-equiv is equivalent to the http header. And is used the same way. But not otherwise.
It seems however that in html 5 that the meta element specification of content-language is being done away with in favor of the html lang= tag; is that right??:
"Conformance checkers will include a warning if this pragma is used. Authors are encouraged to use the lang attribute instead."
And further,
"This pragma is not exactly equivalent to the HTTP Content-Language header, for instance it only supports one language. [HTTP]"

If so, this is the second text is the text that I am objecting to; and perhaps both--for example, I'd prefer "Conformance Checkers" to simply warn people that the meta element is best used to specify the audience language not the text-processing language.
Sorry that I had not read the draft and that I did not make myself clear originally!
From: Martin J. Dürst <duerst@...>
Date: Fri, 30 Oct 2009 11:38:29 +0900
Message-ID: <4AEA51A5.3080801@...>
To: CE Whitehead <cewcathar@...>
CC: ishida@..., ian@..., simonp@..., divya.manian@..., martin.kliehm@..., cowan@..., public-html@..., www-international@...
On 2009/10/30 3:47, CE Whitehead wrote:
> I personally tend to agree with Roy Fielding, John Cowan, and Tex Texin actually, and not with Martin and Richard Ishida because I regulary create documents in two languages (French-English; French-Old French); following Richard Ishida's recommendations in "Specifying Languages in XHTML and HTML Content," I list all the languages in the meta content tag (when I have access to it; because my documents are generally served from a locale I don't control, I don't have access to the http headers). I still set the html language to one or the other when possible and then if I get time specify additional information in relevant elements).
I'm sorry, but can you please explain where Richard and I differ from
Roy/John/Tex?
Sorry!
the issue for me was Ian Hickson's comment (http://lists.w3.org/Archives/Public/www-international/2009OctDec/0023.html) that:
"I've updated the spec to say that when the higher-level protocol reports
multiple languages, they are all ignored in favour of the default
(unknown)."
I did reread Richard Ishida's post--and actually; he does not seem to say that we need to do away with all
differences between the http header, the meta content tag, and the html tag so I must have misread him the first time through--
in fact, there's nothing he said that I disagree with, so sorry.
>It could be that we have very minor differences of how we
>have expressed ourselves, but I think we all agree that HTML5 has to be
>changed to treat the Content-Language: HTTP response header and the
>corresponding <meta> "pragma" the same way.
Agreed
>> I think there will always be cases where people will not tag a document correctly; if a tag is needed it makes no sense to eliminate it because someone cannot yet use it properly.
>I have to say that I slightly prefer ignoring multiple values in
>Content-Language: or the corresponding "pragma" to taking the first
>value for the default language, but that's a minor issue.
Fine, if it's a minor issue . . . and it's all up to the applications in the end anyway how they will handle things!
> And I think that Tex makes a point too--someone might specify a document language as fr-FR and fr-LU but not fr-CA and it makes no sense to default to unknown.
> . . .
> As for the "fr-FR and fr-LU but not fr-CA" example, using "fr" as a
> default may seem obvious to some, but then that would include "fr-CA",
> which the author actually didn't include. So just using "fr" would
> actually be wrong.
Agreed, Canadian French is unique.
--C. E. Whitehead
cewcathar@...
> Regards, Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp duerst@...
Received on Friday, 30 October 2009 02:39:

From forum: w3.org - www-international

CONFIRM u657211431

2009-10-31T07:05:10Z

Unsubscribe!

--
Ryan Hayes | aim: ryguillian | http://anynoisry.blogspot.com

From forum: w3.org - www-i18n-comments

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T20:39:09Z

> If you happen to want to interpret
them as UTF-16, you are free to do so, but there is not and never will
be any guarantee that all strings are well-formed UTF-16.

You never have that guarantee, any more than you have the guarantee that a source purporting to be UTF-8 is in fact well formed. All conscientious recipients need to check the data -- if they are sensitive to ill-formed text. Luckily, the impact of ill-formed UTF-16 is vastly less than that of ill-formed UTF-8.

Mark

On Fri, Oct 30, 2009 at 17:47, John Cowan <cowan@...> wrote:

Phillips, Addison scripsit:

> ECMAScript's "firm commitment" to a 16-bit character model (i.e. UTF-16)

If only.

JavaScript and JSON strings aren't sequences of characters, they are
sequences of 16-bit unsigned integers. If you happen to want to interpret
them as UTF-16, you are free to do so, but there is not and never will
be any guarantee that all strings are well-formed UTF-16. What's more,
the built-in JSON serializer provided by ECMAScript 5th edition does
not generate escape sequences for isolated surrogate codepoints, so that
some strings will be written out in CESU-8 rather than UTF-8.

Worse yet, the JSON RFC is self-contradictory, with the result that it's
not even clear that CESU-8-encoded JSON is illegal.

--
Let's face it: software is crap. Feature-laden and bloated, written under
tremendous time-pressure, often by incapable coders, using dangerous
languages and inadequate tools, trying to connect to heaps of broken or
obsolete protocols, implemented equally insufficiently, running on
unpredictable hardware -- we are all more than used to brokenness.
--Felix Winkelmann

From forum: w3.org - www-international

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T17:47:38Z

Phillips, Addison scripsit:

> ECMAScript's "firm commitment" to a 16-bit character model (i.e. UTF-16)

If only.

JavaScript and JSON strings aren't sequences of characters, they are
sequences of 16-bit unsigned integers. If you happen to want to interpret
them as UTF-16, you are free to do so, but there is not and never will
be any guarantee that all strings are well-formed UTF-16. What's more,
the built-in JSON serializer provided by ECMAScript 5th edition does
not generate escape sequences for isolated surrogate codepoints, so that
some strings will be written out in CESU-8 rather than UTF-8.

Worse yet, the JSON RFC is self-contradictory, with the result that it's
not even clear that CESU-8-encoded JSON is illegal.

--
Let's face it: software is crap. Feature-laden and bloated, written under
tremendous time-pressure, often by incapable coders, using dangerous
languages and inadequate tools, trying to connect to heaps of broken or
obsolete protocols, implemented equally insufficiently, running on
unpredictable hardware -- we are all more than used to brokenness.
--Felix Winkelmann

From forum: w3.org - www-international

RE: Changes to DOM3 Events Key Identifiers

2009-10-30T14:11:34Z

> Doug Schepers scripsit:
>
> > 1) DOM3 Events implementations also update their Javascript
> engines to
> > be able to process the additional escape sequence (e.g. one of
> the ones
> > you mention above) in the same way they process the "\u" escape
> > sequence. This is the better long-term solution, and I'd hope
> ECMA TC39
> > could be persuaded to add this to future ECMAScript specs.
>
> I doubt it, given that such escapes are usually programmatically
> generated.
> In any case, ECMAScript is firmly committed to a 16-bit character
> model.
>

ECMAScript's "firm commitment" to a 16-bit character model (i.e. UTF-16) is not the problem. Lack of support for supplementary characters (that is, those above 0xFFFF in Unicode), however, is a very real problem. No UTF-16 process can escape the fact that, even if one applies a short-sighted limit to BMP characters, a character may require more than one code point to encode. As long as it is clear that DOM3 Events key identifiers are a string containing possibly more than one code point (and potentially more than one character), the escaping syntax is just a detail of the language.

Addison

From forum: w3.org - www-international

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T14:10:01Z

Mark Davis �?? scripsit:

> Java is committed to 16-bit code units as well, but a relatively small
> number of additions enabled effective handling of UTF-16 text.

Good luck getting any such additions into JavaScript, except as a library.

--
They tried to pierce your heart John Cowan
with a Morgul-knife that remains in the http://www.ccil.org/~cowan
wound. If they had succeeded, you would
become a wraith under the domination of the Dark Lord. --Gandalf

From forum: w3.org - www-international

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T14:04:59Z

Java is committed to 16-bit code units as well, but a relatively small number of additions enabled effective handling of UTF-16 text.

Mark

On Fri, Oct 30, 2009 at 13:42, John Cowan <cowan@...> wrote:

Doug Schepers scripsit:

> 1) DOM3 Events implementations also update their Javascript engines to
> be able to process the additional escape sequence (e.g. one of the ones
> you mention above) in the same way they process the "\u" escape
> sequence. This is the better long-term solution, and I'd hope ECMA TC39
> could be persuaded to add this to future ECMAScript specs.

I doubt it, given that such escapes are usually programmatically generated.
In any case, ECMAScript is firmly committed to a 16-bit character model.

--
A rabbi whose congregation doesn't want John Cowan
to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan
and a rabbi who lets them do it cowan@...
isn't a man. --Jewish saying

From forum: w3.org - www-international

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T13:42:59Z

Doug Schepers scripsit:

> 1) DOM3 Events implementations also update their Javascript engines to
> be able to process the additional escape sequence (e.g. one of the ones
> you mention above) in the same way they process the "\u" escape
> sequence. This is the better long-term solution, and I'd hope ECMA TC39
> could be persuaded to add this to future ECMAScript specs.

I doubt it, given that such escapes are usually programmatically generated.
In any case, ECMAScript is firmly committed to a 16-bit character model.

--
A rabbi whose congregation doesn't want John Cowan
to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan
and a rabbi who lets them do it cowan@...
isn't a man. --Jewish saying

From forum: w3.org - www-international

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T11:41:24Z

If the target of this is JavaScript, then the alternative (which Java has also chosen) is to use the UTF16 representation, wherein a pair of \u characters represents each supplementary character (above FFFF). It just needs to be carefully documented.

Mark

On Fri, Oct 30, 2009 at 11:38, Doug Schepers <schepers@...> wrote:

Hi, Mark-

Mark Davis ☕ wrote (on 10/30/09 12:22 PM):

I want to point out that Unicode code points can go up to hex 10FFFF.
The standard for \u is exactly 4 digits, so that one can intermix with
characters and know where it terminates. There are a couple of schemes
that are used to extend this to up to 6 digits, and still know where to
terminate.

\UXXXXXXXX - C++, ICU
\UXXXXXX - C#
\u{xxxxxx} - Ruby

There needs to be some mechanism for extending to 6 digits. It would be
best to use one of the above rather than a new one. (My personal
favorite is Ruby's.)

The reason the "\u" escaped character sequence was chosen was that it is the native ECMAScript escape notation, which is easy for browser-based applications to use directly (i.e. they can inject it directly into the markup as a character).

But, yes, this does have the cap of 4 digits, and I personally would prefer to use a different escape mechanism... but only if one or both of these 2 conditions obtains:

1) DOM3 Events implementations also update their Javascript engines to be able to process the additional escape sequence (e.g. one of the ones you mention above) in the same way they process the "\u" escape sequence. This is the better long-term solution, and I'd hope ECMA TC39 could be persuaded to add this to future ECMAScript specs.

2) Script authors could use a normalizing method (c.f. convertKeyValue) to "dumb down" the 6-digit escape sequence into the 4-digit format (by converting to surrogate pairs when necessary).

Javascript is becoming increasingly important, and so is the need for internationalized and localized language support. With the new font-linking enablers (including my favorite, WOFF [1]), and i18n domain extension policy [2], we're going to see more use of languages I have no chance of ever understanding, and I want DOM3 Events and ECMAScript to be part of that. I'd rather not introduce a not-very-good solution (UTF-16) that we know would not meet all the needs of the world community, just because of a (temporary?) circumstance with a vagary of Javascript.

But, I also want this spec interoperably implemented... so, any solution needs the buy-in of the implementers. Any arguments on either side of the coin would help make a more informed decision.

BTW, you stated a preference for the Ruby-style delimited escaped characters... could you say why you prefer that?

[1] http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html
[2] http://www.icann.org/en/announcements/announcement-30oct09-en.htm

Regards-
-Doug Schepers

W3C Team Contact, SVG and WebApps WGs

From forum: w3.org - www-international

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T11:38:35Z

Hi, Mark-

Mark Davis ☕ wrote (on 10/30/09 12:22 PM):

> I want to point out that Unicode code points can go up to hex 10FFFF.
> The standard for \u is exactly 4 digits, so that one can intermix with
> characters and know where it terminates. There are a couple of schemes
> that are used to extend this to up to 6 digits, and still know where to
> terminate.
>
> \UXXXXXXXX - C++, ICU
> \UXXXXXX - C#
> \u{xxxxxx} - Ruby
>
> There needs to be some mechanism for extending to 6 digits. It would be
> best to use one of the above rather than a new one. (My personal
> favorite is Ruby's.)

The reason the "\u" escaped character sequence was chosen was that it is
the native ECMAScript escape notation, which is easy for browser-based
applications to use directly (i.e. they can inject it directly into the
markup as a character).

But, yes, this does have the cap of 4 digits, and I personally would
prefer to use a different escape mechanism... but only if one or both of
these 2 conditions obtains:

1) DOM3 Events implementations also update their Javascript engines to
be able to process the additional escape sequence (e.g. one of the ones
you mention above) in the same way they process the "\u" escape
sequence. This is the better long-term solution, and I'd hope ECMA TC39
could be persuaded to add this to future ECMAScript specs.

2) Script authors could use a normalizing method (c.f. convertKeyValue)
to "dumb down" the 6-digit escape sequence into the 4-digit format (by
converting to surrogate pairs when necessary).

Javascript is becoming increasingly important, and so is the need for
internationalized and localized language support. With the new
font-linking enablers (including my favorite, WOFF [1]), and i18n domain
extension policy [2], we're going to see more use of languages I have no
chance of ever understanding, and I want DOM3 Events and ECMAScript to
be part of that. I'd rather not introduce a not-very-good solution
(UTF-16) that we know would not meet all the needs of the world
community, just because of a (temporary?) circumstance with a vagary of
Javascript.

But, I also want this spec interoperably implemented... so, any solution
needs the buy-in of the implementers. Any arguments on either side of
the coin would help make a more informed decision.

BTW, you stated a preference for the Ruby-style delimited escaped
characters... could you say why you prefer that?

[1] http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html
[2] http://www.icann.org/en/announcements/announcement-30oct09-en.htm

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

From forum: w3.org - www-international

Re: Changes to DOM3 Events Key Identifiers

2009-10-30T09:22:52Z

I want to point out that Unicode code points can go up to hex 10FFFF. The standard for \u is exactly 4 digits, so that one can intermix with characters and know where it terminates. There are a couple of schemes that are used to extend this to up to 6 digits, and still know where to terminate.

\UXXXXXXXX - C++, ICU
\UXXXXXX - C#
\u{xxxxxx} - Ruby

There needs to be some mechanism for extending to 6 digits. It would be best to use one of the above rather than a new one. (My personal favorite is Ruby's.)

Mark

On Fri, Oct 30, 2009 at 00:32, Doug Schepers <schepers@...> wrote:

Hi, Folks-

(BCC to potentially affected groups: w3c-html-cg, public-webapps, public-i18n-core, wai-xtech, www-svg, public-forms, public-xhtml2, public-html@..., www-voice... please forward on to any relevant groups or individuals I may have missed, especially outside W3C.)

As editor of the DOM3 Events specification, I made what some may consider to be drastic changes in the most recent drafts:
* I changed the syntax of the key identifier strings from "U+xxxx" (a plain string representing the Unicode code point) to "\uxxxx" (an escaped UTF-16 character string), based on content author and implementer feedback.
* I renamed the "key identifier(s)" feature to "key value(s)".

I've mentioned these ideas before in DOM3 Events telcons, and finally decided to do it, after first consulting with the I18n WG, who generally approved of the scheme (though not without some comments about details that will need to be addressed and resolved).

The new string format should be easier to deal with for developers, and the new name reflects some confusion I've encountered when explaining what "key identifiers" are... the work "identifier" seems to evoke the concept of a unique identifier for a key, when in fact what the feature does is provides the most appropriate value given the state of keyboard modifiers and modes. I have tried also to clarify this in the prose of the spec.

We are aware that there may already be implementations and specifications that rely on the previous string format and name (as well as links), back from when this was a W3C Note, and we do not make this decision lightly, but we do believe this is the right decision for a stable and internationalized keyboard interface going forward. For those implementations and specifications that need the previous functionality and name, you may be able to reference the SVG Tiny 1.2 specification [2] instead, which does include the old Key Identifiers feature more or less intact from the previous definition, and is a stable W3C Recommendation.

You can review the changes in the most recent Editor's Draft [1]. The WebApps WG welcomes your feedback to the www-dom@... list. This specification is still a work in progress, though we do hope to go to Last Call soon, so we are open to suggestions. (Note that the spec is mostly feature-complete, so new event types and other changes may have to wait for the next version, but send them on anyway.)

[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset
[2] http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet

Regards-
-Doug Schepers, on behalf of the WebApps WG
Editor, DOM Level 3 Events
W3C Team Contact, SVG and WebApps WGs

From forum: w3.org - www-international