RE: CSS Writing Modes, bidi tests

These are my comments on the tests in http://www.w3.org/International/tests/repository/css3-writing-modes/bidi/results-bidi

1) About the 2 tests "direction/unicode-bidi: element as directional character with unicode-bidi embed, rtl" (bidi-embed-005) and "direction/unicode-bidi: element as directional character with unicode-bidi embed, ltr" (bidi-embed-006):
IMHO, these tests do not prove their point. The sequence of runs is <RTL> <RTL> <RTL> within RTL text direction in the first, <LTR> <LTR> <LTR> within LTR text direction in the second. If the externally-perceived direction of the middle run (the span) was changed in any of those 2 tests, the ordering of the runs would not change, only the  ordering within the middle run could change.
A better test would be IMHO to have the div and the span with opposite directions, and to have 2 similar spans one after the other, like follows (by modifying the rtl test):
<div class="test"><div dir="rtl">a > <span dir="ltr">&#x5d0; > &#x5d1;</span> > <span dir="ltr">&#x5d2; > &#x5d3;</span> > d</div>
                  <div dir="rtl">a > <span dir="ltr">b > c</span> > <span dir="ltr">d >e</span> > f</div>
                  </div>

2) Test "direction/unicode-bidi: direction alone and inherited, unicode-bidi embed" (bidi-embed-011):
I am not sure why the displayed result (the ref) looks as showed. The span has an inherited RTL direction but does not seem to affect the surrounding text as would an RTL character. Is that correct?

3) Test "direction/unicode-bidi: element isolation and unicode-bidi unset, rtl + number" (bidi-unset-007) and "direction/unicode-bidi: element isolation and unicode-bidi unset, ltr + number" (bidi-unset-008), also bidi-unset-009 and bidi-unset-010:
It seems to me that unicode-bidi IS set in the source code.

4) Tests bidi-override-007 and 008: the assertion is "If unicode-bidi:bidi-override is applied to an inline element, the text in that element will NOT be directionally isolated from surrounding text".
The non-isolation is not between the "text in that element" and the surrounding text but between the bidi-override considered as a strong character with direction according to the dir attribute and the surrounding text. This would be better demonstrated if the characters within the override had a natural direction opposite to the dir value of the override element.

5) Same comment for bidi-override-009 and 010.

6) Test bidi-override-011: although it is the default, I would like to see "unicode-bidi: normal" specified for .test b, so that the lack of effect of its dir attribute (=rtl) be more easily understood.

7) Test bidi-override-012: instead of the assertion "When no direction is set, bidi-override will apply ltr ordering to text it surrounds" I suggest "When no direction is set, bidi-override will apply ltr ordering to text within its scope".

8) Test bidi-isolate-override-012: instead of the assertion "When no direction is set, isolate-override will apply ltr ordering to text it surrounds" I suggest "When no direction is set, isoalte-override will apply ltr ordering to text within its scope".

9) Test bidi-plaintext-010: the assertion should say "WILL" instead of "will NOT".

10) block-plaintext-001 and 002: the first test contains a <span> while the second does not. Is that intentional?

<end of comments>

--
Shalom (Regards),  Mati

-----Original Message-----
From: Richard Ishida [mailto:ishida@w3.org] 
Sent: Monday, June 23, 2014 10:14 PM
To: www International
Subject: CSS Writing Modes, bidi tests

I updated and significantly extended the old tests we used to have for CSS bidi.  You can see the 96 new tests at http://www.w3.org/International/tests/repository/css3-writing-modes/bidi/results-bidi

I plan to upload the tests to github and send the CSS test suite folks a pull request in a few days.

In the meantime, I'd be grateful if you would take a look at the tests and let me know if there are any bugs.

If one uses  -moz and -webkit prefixes (which these tests don't) pretty well all the tests pass, so assuming that that means it will be easy to provide non-prefixed versions of the properties, it looks like we're in a good way wrt support of these features.

Cheers,
RI

Received on Tuesday, 1 July 2014 20:28:55 UTC