From: Phillips, Addison (addison@amazon.com)
Date: Thu Mar 11 2010 - 19:38:32 CST
Hi,
Your (and other’s) comments on this Working Group document are quite welcome. However, we do kindly ask that comments be directed to public-i18n-bidi@w3.org<mailto:public-i18n-bidi@w3.org>. If you need to subscribe to our list, there is a link on the archive page (here):
http://lists.w3.org/Archives/Public/public-i18n-bidi/
Addison
Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG
Internationalization is not a feature.
It is an architecture.
From: www-international-request@w3.org [mailto:www-international-request@w3.org] On Behalf Of CE Whitehead
Sent: Thursday, March 11, 2010 5:24 PM
To: ishida@w3.org; www-international@w3.org; unicode@unicode.org
Subject: New First Public Working Draft: Additional Requirements for Bidi in HTML
Hi, actually at this moment I have a few comments on section 3.3 of the working draft; other than that I have questions about why IE 7 does not treat a block with all characters in English or neutral as having a directionality separate from an rtl page.
Thanks.
> everybody: The actual location of the Working Draft is
> http://www.w3.org/TR/2010/WD-html-bidi-20100304/, it's generic address
> is http://www.w3.org/TR/html-bidi/.
* * *
2.1
The problem
par 3
"Arbitrary-direction entities also don't cause a problem when they are displayed as a separate block element (which is treated as a separate "paragraph" in UBA terms)."
{COMMENT: see my attached file; there is a problem it seems in IE 7 if you have an rtl page with a paragraph that should run ltr but where the directionality is not explicitly set then the closing neutral characters don't stick as they should even though the only directionality in that block is ltr--unless of course you explicitly declare the directionality. For the attached file, the only thing I want is to fix is the English text displayh; I understand why the forward slash can't be turned around in an rtl context . . . }
* * *
3.3
"Different browsers treat embedded block elements differently. Just as with <br>, in Firefox and Opera, an embedded block element provides no bidi separation between the text preceding and following it, while IE and WebKit treat it as a UBA paragraph break. See Section 3.1 for examples where this discrepancy makes a difference; just replace <br> with <hr>. "
{COMMENT: As noted above I think I am having problems with ie 7 in this regard--it does not seem to treat my paragraph in English as a separate bidi run, so that neutral characters do not display properly without additional markup; again, see attached!}
* * *
3.3
"Include among them the paragraph element, <p>. It seems reasonable to expect the insertion of a paragraph to break the text before it and the text after it into two UBA paragraphs.
" . . .
"Proposed solution
"Elements with block display should be specified as introducing a UBA paragraph break between the text preceding and following them."
{ COMMENT: I think that anything surrounded by markup is separate by default--and agree with Richard Ishida that "bidi=yes" is the best default solution for any inline element; however since paragraphs can be embedded in other paragraphs and divs, I do not agree that the text before is by default a separate run from the text after--not unless there is some evidence that it is (that is, unless strong directionality characters are present in one run that are not present in another or something; I am not sure what the criteria should be here; maybe it should be initial characters in the run following the block differing from final characters in the run preceding the block element or a significant difference in the amount of characters of one type in the two runs).}
* * *
"The text inside an elements with inline-block display should constitute a UBA paragraph, but probably should not introduce a UBA paragraph break. Instead, it can default to bdi="yes". This and the other types of display should be given more thorough investigation. "
{COMMENT: yes; this is the best solution for this; this is the best default for embedded inline elements too if there is an rtl attribute set; this is the solution for embedded block elements except when there is some reason to change the directionality of the text following the block from that preceding the block.
But there's a typo; see below.}
* * *
Proofreading--3.3. only
3.3
"Proposed solution"
par 2
" in accordince with "
{COMMENT: spelling}
=> "in accordance with"
* * *
3.3
"Proposed solution"
par 3
"The text inside an elements "
{COMMENT: agreement error}
=> "an element"
* * *
{I'll get to the rest of R.I.'s article afterwards--sorry I only have this at the moment!}
Best,
--C. E. Whitehead
cewcathar@hotmail.com<mailto:cewcathar@hotmail.com>
This archive was generated by hypermail 2.1.5 : Thu Mar 11 2010 - 19:40:26 CST