RE: [css3-text] Proposed pruning & scoping of hyphenation properties

> -----Original Message-----
> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> Sent: Tuesday, March 29, 2011 11:45 PM
> To: Christian Stockwell
> Cc: Alex Danilo; www-style@w3.org
> Subject: Re: [css3-text] Proposed pruning & scoping of hyphenation
> properties
> 
> On 03/29/2011 10:23 PM, Christian Stockwell wrote:
> >
> > I think I may be misunderstanding the intent of word-wrap: hyphenate.
> > My understanding was that word-wrap: hyphenate would be similar to
> > word-wrap: break-word in that an arbitrary spot in the text would be
> selected for hyphenation as to minimize whitespace.
> > What you're describing is that  word-wrap: hyphenate is actually an
> > alternative mechanism to opt into the equivalent of "hyphens: auto" for a
> single word.
> >
> > If that's the case, it seems like we've already solved this problem
> > through the use of the hyphenation-limit-zone property (e.g. set the
> > hyphenation zone width to be 99% and authors may have a solution to this
> corner case).
> 
> That's an interesting hack. :) We'll have to ask the working group if they
> prefer that.

I disagree with the assertion that this is a hack--it is the logical limit of a property we've defined, used precisely as specified. In the "99%" or "100%" case the designer is simply saying that she wants hyphenation to occur only if a word begins at the very beginning of the line and does not fit on the line (which is exactly the behaviour we want, and exactly what she would expect based on the description of hyphenation-limit-zone).

The additional benefit of this approach is then a designer can combine hyphenation with word-wrap: break-word to prioritize hyphenation, but if no hyphenation exists wrap the word to avoid overflow. (e.g. p { hyphens: auto; hyphenate-limit-zone: 99%; word-wrap: break-word; }). In contrast, if "hyphenate" is a value for word-wrap, then she has no mechanism to instruct UAs to give preference to hyphenation for emergency wrapping, but to fall back to arbitrary word wrapping as a last resort to avoid overflow.
 
> 
> > If this corner case problem is adequately solved by hyphenation zone
> > we can avoid getting embroiled in specifying exactly what it means to
> > "influence" word breaks without "controlling" them (as used in the editor's
> draft).
> 
> It says "influencing" without "forbidding", not "influencing" without
> "controlling".
> 
> Here's the example: 'hyphenate-limit-chars' could say that the word is not
> allowed to break within the first or last 3 characters. If we had a word that
> was 8 characters long, and 2 characters overflowed, we'd therefore prefer a
> break somewhere in the middle if the word rather than towards the end. But
> if the word was 5 characters long and the only break blocked by hyphenate-
> limit-chars, we'd break there anyway because otherwise we'd overflow. You
> try to honor the limits if you can, but you break the rules before you give up
> and overflow.
> 
> ~fantasai

I think we need to resolve this problem within the hyphenation properties themselves anyway. For example, suppose an author specifies a set of properties that are mutually exclusive--for example, a very narrow hyphenate-limit-zone (requiring that UAs try to hyphenate a word at the end of the line) and a very large hyphenate-limit-word--throwing out all possible hyphenation opportunities. In the end only one of those requirements can be respected. All of these properties should be clearly identified as requests to which the UA should attempt to adhere, but may be overridden to resolve conflicts or produce optimal line layouts.

Received on Wednesday, 30 March 2011 17:23:30 UTC