Re: CSS3 Text and UAX14

On 2/20/2007 5:11 PM, fantasai wrote:
> Asmus Freytag wrote:
>>
>> On 2/20/2007 3:55 AM, Paul Nelson (ATC) wrote:
>>>
>>> The only place where I see problems with the SP definition are in 
>>> the PRE situation where we are keeping the widths of all spaces 
>>> explicitly. In this case are we really tailoring the line breaking 
>>> class of the character?   
>>
>> I think PRE is not an issue. The only time you get an issue is when 
>> you use "CRT-style" line breaking at a fixed column so that SP can 
>> get wrapped to the head of a new line. CRT-style line breaking is 
>> clearly not UAX-14 compliant, and should therefore be labeled as such 
>> (an non-UAX14 compliant mode with special behavior)
>
> Well, SP can get wrapped to the head of a new line in the following
> case as well:
>
>   <p>Some <code> </code> <code> </code> text with spaces.</p>
>
> where
>   code { white-space: pre; }
>
> In this case the spaces in <code> can get wrapped to the front of
> the line.
In bidi, we allow an 'out' for higher level protocols so that they may 
apply the bidi algorithm in sections. Doing so for linebreak on a 
general principle would allow such behavior. On the other hand, it would 
throw into doubt whether a ZW or WJ character added in a document is 
actually effective, if it winds up at the boundary between two runs.

For CSS you could assert that at any place where your whitespace 
handling changes in the middle of a run of spaces, that is equivalent to 
an invisible ZW being present. I think that would address this 
particular problem, but I can conceive of better solutions in principle.

Either way, it's worth continuing this dialog to see whether we can find 
the correct balance in what the CSS text contains and what UAX#14 will 
contain in 5.0.1, so that you can base your description off of UAX#14 in 
confidence. Perhaps Paul has one of his inspired solutions?
>
> Also, I think UAX14 should allow wrapping within space sequences
> generally: it can be useful in some editing contexts to wrap spaces
> that don't fit so that the author is aware of them and can delete
> excess spaces if necessary. If they disappear off the end of the
> line, then it's hard to notice that they're there.
In my view, the default model should not allow that kind of behavior, so 
that users can rely on spaces not carrying over the end of a line. (Most 
of the impetus for our getting involved in linebreak specification stems 
from a need to give users firm guidelines as to when they should insert 
a particular character into their text).

If you allow it in the standard algorithm for specific editing modes, 
even only as tailoring, then the problem is one of knowing when this 
behavior is enabled or disabled. Therefore, I wonder whether it is 
usefule to ask special editing modes to be conformant to begin with.

This also is not the last word and needs some more thought.
>
>> The descriptions in UAX#14 of how the *width* of SPACE characters is 
>> handled are informative material on line-layout, not specifications 
>> of line-breaking.
>
> Yes, but, as I said before, there is no clear distinction between
> normative requirements and informative statements in UAX14. This
> makes me very hesitant to include anything more than normative
> references to specific parts of UAX 14 that I can be sure won't
> cause problems.
These issues are eminently fixable and I appreciate your having taken 
the time
to lay them out.  Unicode in its specifications does not use the 
technique of
reserved words in all caps. However, that doesn't mean that the language
cannot be improved.

As a first pass, I've gone over the existing text and replaced the use of
"must" where it was used as ordinary language, usually by 'needs be',
or other, less normative sounding statements.

I've taken a hard look at the "should"s and replaced many of them
by "is recommended", because that's what most of them were used
as.

The 'descriptive statement' issue is of course a bit trickier to track
down. I've strengthened the language in the introduction to section5
to clarify that much of the material is informative.
> Another problem I've noticed: SP is specified as not tailorable, but it
> is left out of the list of non-tailorable character classes in the list
> at the top of 6.1. What is the intent of the spec? Can membership in SP
> be tailored or not?
It looks like the list at the head of 6.1 is in error (It's marked 
non-tailorable
in both Table 1 and Section 5 and the intent is to only have non-tailorable
classes participating in the rules in Section 6.1). That's an erratum.

A./
>
> ~fantasai
>
>

Received on Wednesday, 21 February 2007 03:15:09 UTC