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

> -----Original Message-----
> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> Sent: Wednesday, March 30, 2011 10:29 AM
> To: Christian Stockwell
> Cc: Alex Danilo; www-style@w3.org
> Subject: Re: [css3-text] Proposed pruning & scoping of hyphenation
> properties
> 
> On 03/30/2011 10:03 AM, Christian Stockwell wrote:
> >
> >>> 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).
> 
> 100%, ok, but 99% is a hack because it only works as expected if there is no
> breakpoint in that last 1%.


(Addressed below)

> 
> > 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.
> 
> The syntax definition of 'word-wrap' is
>    word-wrap: normal | [ break-word || hyphenate ] which means you can write
>    word-wrap: hyphenate break-word;
> 
> So this isn't particularly a concern.

Got it. Didn't notice the relevant clause in 7.2. Thanks for clarifying.

> 
> > 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.
> 
> If the author specifies limits that result in no allowed hyphenation points, then
> I expect they get no hyphenation.
> 
> ~fantasai

Except that that's not quite the case, because what we're now saying is that there's another property (word-wrap) that may mean that they do in fact get hyphenation even if no hyphenation points are allowed. 

Since we seem to agree that hyphenate-limit-zone set to 100% appears to be sufficient for the use case that motivated the introduction of word-wrap: hyphenate, here's what I propose we do:

1. Remove word-wrap: hyphenate.

2. Specify that control properties can be relaxed by the UA, in particular to avoid emergency word-wrap. It's worth noting that stringently requiring adherence to these control properties would prohibit a UA from following the spec and also implementing more optimal text layout algorithms like TEX-style line layout, which seems like a great reason to relax the requirement. Relaxing these rules also removes part of the need to have word-wrap: hyphenate.

3. Specify that control properties can be also ignored to give preference to explicit hyphens and soft hyphens. For example, suppose an author specifies that no less than 5 characters must follow a hyphen, because she does not want the hyphenation dictionary to begin broadly hyphenating words that produce a negative visual effect on her page. Given the word twenty-two, it is however very unlikely that the author would prefer to hyphenate "twenty" rather than use the explicit hyphenation opportunity, so UAs should be granted the leeway to give precedence to these explicit hyphenation opportunities in some cases even where they conflict with the control properties. 

Together what this would mean for the spec is that we'd maintain a consistent story around how to enable hyphenation (you must set "hyphens" to "auto" or "manual"), consolidate in a single set of clearly-identifiable properties the complete set of hyphenation behaviour defined by CSS (e.g. all properties that begin with "hyphenate-", and avoid adding a new value to a property that we already admit is poorly named for legacy reasons. 

I don't see any downside.

Received on Wednesday, 30 March 2011 19:51:13 UTC