Re: CSS3 Text and UAX14

Asmus Freytag wrote:
> 
> On 2/20/2007 5:11 PM, fantasai wrote:
>> 
>> 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.

Well, no, it wouldn't because ZW mustn't be automatically inserted in
this case:

    <p>Line feeds (<code>U+000A</code>) are...</p>

>> 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.

I think that if you merely recommend the currently-specified behavior
and specify it as the default, but allow breaks within whitespace
sequences as a tailoring, then it is reasonable to trust that the
implementor or higher-level protocol will do what is most appropriate
for its application. That would certainly solve the problem for CSS
'pre'.

> 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.

Excellent. :)

> 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.

"should" and "is recommended" are equivalent in RFC2119, and carry
the same basic meaning in English as well. If you add it as alternative
wording for recommendations in your conformance section, there's no
problem with using it. The thing to be careful about is, as with
"must", to only use it in contexts that are recommending a behavior
for the implementation ("the UA should treat Q as Z in some languages",
or "Q should be treated as Z in some languages").

> 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.

Ok. I'll take a closer look and see if I find any more examples of
this problem.

>> 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.

Ok. Is there any reason why SP's membership cannot be augmented?

~fantasai

Received on Wednesday, 21 February 2007 06:38:15 UTC