Closed
Bug 151395
Opened 22 years ago
Closed 6 years ago
Bidi: Use the "lang" attribute to determine whether to use Arabic number ordering in ambiguous context (UAX #9 section 4.3, HL2)
Categories
(Core :: Layout: Text and Fonts, enhancement)
Core
Layout: Text and Fonts
Tracking
()
RESOLVED
INVALID
People
(Reporter: kyae-young.kim, Unassigned)
References
Details
(Whiteboard: [oracle-nls])
Attachments
(2 files)
Env. : Mozilla 1.0, Windows 2000, locale is Arabic[Egypt]
Des. : Date Format for RTL direction is not correct.
Reproducible step:
1) Load the test case
2) LTR direction is displayed correctly but RTL test case
should be displayed "2002/06/08"
Test case is
<HTML DIR=RTL LANG=AR>
<HEAD>
<meta charset="UTF-8">
</HEAD>
<BODY>
<B>Date Format for RTL</B><BR>
<INPUT TYPE="text" VALUE="28/06/2002"><BR>
<BR>
<B>Date Format for LTR</B><BR>
<INPUT TYPE="text" DIR=LTR VALUE="28/06/2002">
</BODY>
</HTML
Comment 1•22 years ago
|
||
I am really unsure about this case. First of all, I want to note that it's not
100% true that the date should be displayed as 2002/06/28 in RTL direction. This
is only the case in Arabic, not in Hebrew, and this distinction is part of the
rules for weak types in the Unicode Bidi Algorithm, starting at
http://www.unicode.org/unicode/reports/tr9/#W1
Mozilla does indeed display the date as 2002/06/28 in an unambiguous Arabic
context (try entering an Arabic character before the date in the input control),
but should a text input control with no alphabetical characters of any kind,
inside a document with LANG=AR, be considered as in an Arabic context by default?
The HTML standard says (http://www.w3.org/TR/html401/struct/dirlang.html#h-8.2):
"User agents must not use the lang attribute to determine text directionality"
but I'm not sure that that covers this situation.
The Unicode Bidi Algorithm says
(http://www.unicode.org/unicode/reports/tr9/#Bidirectional_Conformance): "The
following are permissible ways for systems to apply higher-level protocols to
the ordering of bidirectional text ... Override the number handling to use
information provided by a broader context.
For example, information from other paragraphs in a document could be used to
conclude that the document was fundamentally Arabic, and that EN should
generally be converted to AN."
That sounds to me as if our current behaviour complies to the body of the
standard, and this bug report is an RFE that we implement that particular
"permissible" behaviour, using the lang attribute as the "information from other
paragraphs in the document". Kyae-Young, are you happy with that assessment?
cc-ing Hixie and Roozbeh
Comment 2•22 years ago
|
||
Using xml:lang="" and <html:* lang=""> attributes to determine the language
context of an element seems reaonable to me. Make sure you use the language
context of the element in which you find the numbers, though, not the element on
which the direction is set or the root element or anything arbitrary like that.
Comment 3•22 years ago
|
||
Simon: thanks for cc'ing me, btw
Comment 4•22 years ago
|
||
>Make sure you use the language
>context of the element in which you find the numbers, though, not the element on
>which the direction is set or the root element or anything arbitrary like that.
Wait a minute -- the lang attribute inherits, right? So in the test case here
doesn't that mean that *both* dates should appear as 2002/06/28?
Comment 5•22 years ago
|
||
Comment 6•22 years ago
|
||
I don't really understand bidi rules, so I don't know really, sorry!
Reporter | ||
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•20 years ago
|
Whiteboard: [oracle-nls]
Comment 7•20 years ago
|
||
Unicode 4.0.1 changed the classification of the SOLIDUS (slash) character from
"European Separator" to "Common Separator". Mozilla is apparently now following
the newer standard, resulting in all dates on the attached testcase to appear as
28/06/2002.
However, everything said above is still relevant if you replace the slash with a
hyphen (-), which is still a ES in the newer standard. I'll attach a modified
testcase soon.
Comment 8•20 years ago
|
||
This is the same as the original testcase, except:
1. The slashes are replaced by hyphens, to achieve with Mozilla versions
supporting Unicode >=4.0.1 the same behaviour the original testcase used to
display with Mozilla versions implementating older versions of the standard.
2. The dates are given as regular text, in addition to being the contents of
input controls, to demonstrate that the issue is not specific to input
controls.
Comment 9•20 years ago
|
||
*** Bug 270914 has been marked as a duplicate of this bug. ***
Comment 11•19 years ago
|
||
More descriptive summary, and change severity to RFE, per comment #1.
Severity: normal → enhancement
Summary: Bidi : Date Format for RTL direction is not correct. → Bidi: Use the "lang" attribute to determine whether to use Arabic number ordering in ambiguous context (UAX #9 section 4.3, HL2)
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
Updated•13 years ago
|
Assignee: mozilla → nobody
Comment 12•6 years ago
|
||
I'm closing this as INVALID because the HTML Standard doesn't allow using the lang attribute in this way.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•