Re: [css3-text] Splitting CSS Text into Level 3 and Level 4

On Wed, 23 Nov 2011 17:14:43 +0100, Alan Stearns <stearns@adobe.com> wrote:

> On 11/23/11 7:47 AM, "Florian Rivoal" <florianr@opera.com> wrote:
>
>>> But I think we can have tests that check that text-justify:inter-word
>>> only changes word spacing and leaves inter-character spacing alone.
>>
>> That test would be wrong. text-justify:inter-word does not require that
>> you only change
>> spaces between words. Only that you *primarily* change space between
>> words. You are free to
>> also change inter-character spacing, as long as you don't change it  
>> nearly
>> as much as
>> inter word spacing.
>
> You are correct. I was thinking of an example where a minor adjustment to
> word spacing would be sufficient, and where I would expect no changes to
> inter-character spacing. But that's not required in the spec. A UA could
> interpret the spec's priority levels for inter-word by adding 5x word
> spacing and 1x character spacing until the content filled the line box.  
> That
> would be a bad algorithm for Roman text, but I'm not reading anything in  
> the
> spec text that disallows that strategy.
>
> I'm not sure that we would gain anything by getting more specific,  
> though.
> There are valid choices to make that will differ between implementations.
> Perhaps the test cases could check that the spacing changes at each  
> priority
> level are roughly equivalent, and that higher priority changes are larger
> than lower-priority changes.

This is essentially my problem with this. If we're too specific, we make
prevent UA implementers from picking a number of good solutions. If we're
not very specific, the behavior is so loosely defined that it allows for  
some
terrible implementations to be considered conforming, and authors don't get
much insurance that what looked good on a conforming UA will look  
reasonably
similar on another conforming UA.

Again, I don't have a better solution, but so far, I've seen versions of  
this
that are too strict to allow good implementations, or too loose to  
guarantee
meaningful interoperability. I don't know if we can solve this problem by
tweaking the proposed property a little bit, or if we need to find a  
different
approach.

  - Florian

Received on Wednesday, 23 November 2011 16:27:16 UTC