Re: New tests: Line breaks in CSS3 Text

On Fri, Sep 14, 2012 at 10:14 PM, Richard Ishida <ishida@w3.org> wrote:

> On 01/09/2012 04:28, Glenn Adams wrote:
>
>> On Fri, Aug 31, 2012 at 12:53 AM, Richard Ishida <ishida@w3.org
>> <mailto:ishida@w3.org>> wrote:
>>
>>     Several sets of tests are now available related to line breaks, word
>>     breaks and hyphenation in CSS3 Text and Unicode Standard Annex #14
>>     (Line Breaking Properties). Some of the tests are rewrites of
>>     previous tests in the Internationalization Activity test suite.
>>     There are also many new tests.
>>
>>
>> (1) all of the Conditional Japanese Starter (CJ) test sets are missing
>> U+FF70, recently added in the latest ED [1][2];
>>
>
> See http://www.w3.org/**International/tests/html-css/**
> line-break-ja-zh/results-ja<http://www.w3.org/International/tests/html-css/line-break-ja-zh/results-ja>
>
> Now added to the test suite.
>
>
>
>> [1] http://dev.w3.org/csswg/css3-**text/#line-break<http://dev.w3.org/csswg/css3-text/#line-break>
>> [2] http://lists.w3.org/Archives/**Public/www-style/2012Aug/0860.**html<http://lists.w3.org/Archives/Public/www-style/2012Aug/0860.html>
>>
>> (2) the tests listed under Conditional Japanese Starter (CJ) for
>> line-break: normal [3] are incorrect since CSS3 Text states that for
>> *normal* and *loose*, that breaks before small kana and prolonged sound
>>
>> marks are permitted (not forbidden); these tests currently treat
>> according to *strict* semantics (forbidden), which is wrong (according
>>
>> to spec);
>>
>> [3]
>> http://www.w3.org/**International/tests/html-css/**
>> line-break-ja-zh/results-ja#**normal<http://www.w3.org/International/tests/html-css/line-break-ja-zh/results-ja#normal>
>>
>>
>> (3) the tests for U+301C (WAVE DASH) and U+30A0 (KATAKANA-HIRAGABNA
>> DOUBLE HYPHEN) listed under (Non-starter) NS for line-break: normal [3]
>> are incorrect since CSS3 Text states that for *normal* and *loose*, that
>>
>> breaks before these characters are permitted (not forbidden); these
>> tests currently treat according to *strict* semantics (forbidden), which
>>
>> is wrong (according to spec);
>>
>> (4) the tests for iteration marks {U+3005, U+303B, U+309D, U+309E,
>> U+30FD, U+30FE} and also exclamation/question marks {U+203C, U+2047,
>> U+2048, U+2049} listed under Non-starter (NS) for line-break: normal [3]
>> are incorrect since CSS3 Text states that for *normal* and *strict*,
>>
>> that breaks before these characters are forbidden (not permitted); these
>> tests currently treat according to *loose* semantics (permitted), which
>>
>> is wrong (according to spec);
>>
>> (5) the tests for U+2010 (HYPHEN) and U+2013 (EN DASH) listed under
>> under Break After (BA) for line-break: normal [3] are incorrect since
>> CSS3 Text states that for *normal* and *loose*, that breaks before these
>>
>> characters are permitted (not forbidden); these tests currently treat
>> according to *strict* semantics (forbidden), which is wrong (according
>>
>> to spec);
>>
>> (6) the tests for exclamation/question marks {U+0021, U+003F, U+FF1F}
>> listed under Exclamation (EX) for line-break: normal [3] are incorrect
>> since CSS3 Text states that for *normal* and *strict*, that breaks
>>
>> before these characters are forbidden (not permitted); these tests
>> currently treat according to *loose* semantics (permitted), which is
>>
>> wrong (according to spec);
>>
>> (7) the tests for U+003A (COLON) and U+003B (SEMICOLON) listed under
>> under Infix Numeric Separator (IS) for line-break: normal [3] are
>> incorrect since CSS3 Text states that for *normal* and *strict*, that
>>
>> breaks before these characters are forbidden (not permitted); these
>> tests currently treat according to *loose* semantics (permitted), which
>>
>> is wrong (according to spec);
>>
>> (8) the tests for postfix characters {U+0025, U+00A2, U+00B0, U+2030,
>> U+2032, U+2033, U+2103, U+FF05, U+FFE0} listed under Postfix Numeric
>> (XB) for line-break: normal [3] are incorrect since CSS3 Text states
>> that for *normal* and *strict*, that breaks before these characters are
>>
>> forbidden (not permitted); these tests currently treat according to
>> *loose* semantics (permitted), which is wrong (according to spec);
>>
>
> I don't know what I was smoking when I created those normal tests, but all
> the above should now be fixed.
>
>
>
>
>> (9) for each of the strict, normal, loose test sets, there seems to be a
>> redundant test for U+0025 PERCENT SIGN, cf.,
>> line-break-ja-zh-{050,053}, line-break-ja-zh-{150,153},
>> line-break-ja-zh-{250,253};
>>
>
> Removed.
>
>
>
>
>> (10) for each of the strict, normal, loose test sets, there are no tests
>> for the prefix characters {U+0024, U+00A3, U+00A5, U+20AC, U+2116,
>> U+FF04, U+FFE1, U+FFE5} which are assigned specific break semantics by
>> CSS3 Text;
>>
>
> Yes. I ran out of time to add those.
>
>
>
>
>> (11) some of the CSS3 Text line-break rules are not sensitive to content
>> language, e.g., small kana, prolonged sound marks, iteration marks, and
>> inseparables; the current tests do not test that the specified rules are
>> applied when content language is not ja or zh for these rules;
>>
>
> True. Again, I ran out of time.
>
>
>
>> (12) similarly, the other CSS3 Text line-break rules are applied only if
>> content language is ja or zh; there are no tests that these rules are
>> not applied when content language is not ja or zh;
>>
>
> ditto
>
>
>
>> As an FYI, I'm in the processing of addressing a WebKit bug against the
>> line-break feature [4]. To this end, I've prepared some preliminary wiki
>> documentation on this subject that may be of interest [5][6]. I would be
>> interested in receiving any comments or corrections to this material.
>>
>> [4] http://bugs.webkit.org/show_**bug.cgi?id=89235<http://bugs.webkit.org/show_bug.cgi?id=89235>
>> [5] http://trac.webkit.org/wiki/**LineBreaking<http://trac.webkit.org/wiki/LineBreaking>
>> [6] http://trac.webkit.org/wiki/**LineBreakingCSS3Mapping<http://trac.webkit.org/wiki/LineBreakingCSS3Mapping>
>>
>
Thanks! BTW, a couple of additional comments:

(1) it would be nice if these tests accounted for the fact that the CSS WG
has not yet approved a non-prefixed version of CSS3 Text properties; until
that happens, testing use of 'line-break' as opposed to, say,
'-webkit-line-break', won't be very useful;

(2) the fact that these tests rely on manual resizing and visual inspection
make it unlikely they will be used by UA vendors for normal automated
testing; I recently submitted at [1] a set of tests that make use of fixed
width of containing element to force break behavior at a likely position;

[1] https://bugs.webkit.org/attachment.cgi?id=164031&action=prettypatch