Re: [css3-text] spacing limits are not interoperable

On 12/4/12 4:58 PM, "John Daggett" <jdaggett@mozilla.com> wrote:

>
>Hi Alan,
>
>> >As I mentioned previously at the San Diego F2F [3], I don't think
>> >it makes sense to define fine-grained parameters like this without
>> >also specifying normatively the justification algorithm with which
>> >they are used.
>> 
>> I don't think it makes sense to have a single justification
>> algorithm. We don't specify a line breaking algorithm as
>> specifically as you appear to be requiring for a justification
>> algorithm. People expect to see slightly different line breaks in
>> different browsers, and so they should also expect to see slightly
>> different justification results in different browsers
>
>I am by no means arguing for a single, grand unified justification
>algorithm.  But I don't think fine-grained spacing controls make sense
>as settings that apply to *all* algorithms, in particular to ones that
>are relatively crude (e.g. line local algorithms).

Line local algorithms might actually get more use out of spacing controls
than sophisticated paragraph-level composers. As John Hudson noted, good
hyphenation with paragraph-level justification often (but not always)
obviates the need for spacing controls. In that best case, the word and
letter spacing deviates only slightly from the desired setting. A line
local algorithm will result in worse line breaks (with or without good
hyphenation), so deviations from the desired spacing will occur more
often. If you only have one spacing value, then the only adjustment that
can be made is to loosen spacing. If you have a min/desired/max setting,
even a line local algorithm can pick a line break with very slightly
tighter spacing in order to avoid blowing out the maximum altogether.

>
>> >In an implementation which implements a "better" justification
>> >algorithm (e.g. a paragraph global algorithm rather than a line local
>> >one) this might lead to suboptimal results which would discourage the
>> >use of improved algorithms.
>> 
>> Is this concern stemming from this set of steps?
>> 
>> 1. Set spacing controls
>> 2. Look at the results in a simple justification algorithm
>> 3. Tweak the content based on specific line endings to
>>    look good in a specific browser
>> 4. Now the tweaks applied in step 3 make the content in
>>    a different browser look worse
>> 
>> I agree that step 3 is bad, but it's a bad thing to do even without
>> spacing controls. I don't see how shuffling between steps 1 and 2
>> until it looks good in one browser would make a different browser
>> look worse (unless you're changing min/max settings to absurd values
>> in a browser whose justification algorithm ignores them).
>> 
>> What is your scenario where improved algorithms are discouraged?
>
>Yes, this is precisely my concern, that authors will perform step (3)
>in a browser with a justification algorithm optimized primarily for
>speed rather than quality such that when those same parameters are
>used within a higher quality implementation, the results will be
>crippled.
>
>To put it another way, hopefully a quality implementation with good
>hyphenation obviates the need to use spacing controls.  Spacing
>controls could easily end up as simply be a way for authors to try and
>make up for inadequacies in lower quality implementations, to the
>detriment of the display in higher quality implementations.
>
>I think there are good reasons to (1) wait on specifying spacing
>controls and and (2) restrict these controls to justification
>algorithms with some minimum level of sophistication to minimize their
>use as a way of making up for inadequate implementation quality.

I don't agree that spacing controls should be limited to more
sophisticated justification algorithms. That's why I support the current
draft text that attempts to allow different justification algorithms to
use them.

Thanks,

Alan

Received on Wednesday, 5 December 2012 01:17:28 UTC