W3C home > Mailing lists > Public > www-style@w3.org > March 2011

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

From: Christian Stockwell <cstock@microsoft.com>
Date: Wed, 30 Mar 2011 04:21:39 +0000
To: fantasai <fantasai.lists@inkedblade.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <2B4FAE26EDC5A14CAD4376398DC6DFBE6498D410@TK5EX14MBXC122.redmond.corp.microsoft.com>

> -----Original Message-----
> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> Sent: Tuesday, March 29, 2011 8:43 PM
> To: Christian Stockwell
> Cc: www-style@w3.org
> Subject: Re: [css3-text] Proposed pruning & scoping of hyphenation
> properties
> 
> On 03/29/2011 08:15 PM, Christian Stockwell wrote:
> >
> >>> 1. I think that adding "hyphenate" to "word-wrap" is a mistake.
> >>> I expect that real world usage of word-wrap is low and the use case
> >>> for word-wrap: hyphenate is-at best-narrow. Since we're already in
> >>> the realm of linguistic incorrectness we should just keep it simple
> >>> rather than add new speculative values to the standard.
> >>
> >> What makes you say that word-wrap: hyphenate is in the realm of
> >> linguistic incorrectness? It was proposed precisely to preserve
> >> linguistic correctness while avoiding overflow.
> >
> > I think that in the context of the English language there are levels
> > of linguistic correctness in the context of hyphenation. If that were
> > not the case then there would be no need for a hyphenation resource at
> > all, as we'd consider "append", "a-ppend", and "ap-pend" to be equally
> > acceptable.
> >
> > The reality is that those two hyphenated versions of "append" are not
> > equal.. Most readers would not give the latter version a passing
> > glance if encountered at the end of a line, whereas the former would
> > likely cause a reader to stumble. ...
> 
> Isn't the hyphenation dictionary supposed to take care of that?
I don't follow. What is the hyphenation dictionary supposed to take care of here? Perhaps it would help to describe an expected use case for "word-wrap: hyphenate" and how it would relate to usage of "hyphens".

> 
> >>> 4. For "hyphens: auto" we should remove the clause specifying that
> >>> explicit hyphenation should take priority over automatic resources.
> >>> This clause is problematic for a few reasons, not least of which is
> >>> that "takes priority" is going to be difficult to define well, or-if
> >>> defined simply-will likely be ignored if UAs implement the Optimal
> >>> Paragraph algorithm. Let the UA decide which hyphenation opportunity
> >>> to use...
> >>
> >> I very strongly disagree with this here. The purpose of the soft
> >> hyphen is to allow the author control over the exact hyphenation of
> >> this instance of this word.
> >
> > The draft and the Unicode standard distinguish conditional from
> > explicit hyphens (section 6.1, example IV). I absolutely agree that
> > soft (conditional) hyphens should be given priority for precisely the
> > reason you state. The clause that I think we should change, however,
> applies to explicit hyphens.
> > Explicit hyphens do not generally capture author intent.
> 
> Ah, I see. Fixed. (Changed "Explicit" to "Conditional".)
> 
> > One concern I have is that I don't know of another place in CSS that
> > we resolve % in this way? Are there other places where we resolve a %
> > against the line box? If not, is there any cause for concern?
> 
> I don't think so. We're not resolving the percentage as a computed value for
> some property to be exposed elsewhere, just resolving it during the layout of
> that particular line.
> 
> > Any thoughts regarding my #5?
> >
> > 5. After thinking about hyphenation some more I think the
> > hyphenate-limit-* properties should only apply when hyphens is set to
> > "auto", and be ignored otherwise. The reason why the hyphenate control
> > properties exist is because authors need some mechanism to influence
> > how UAs balance the linguistic "badness" of hyphenation against visual
> > impact (e.g. how much whitespace there is in a block of text). In the
> > case of "manual" it does not make much sense to balance "badness"
> > since explicit hyphens are linguistically neutral (since they're part
> > of the language) and conditional hyphens are already treated as
> exceptions (assuming that accept my proposal in #4).
> 
> I think my answer to this falls under the content vs. style distinction Brad was
> talking about. (Also this would only make sense for the character limits, not
> the other limits.) 
> 
> ~fantasai

(Adding one point that I just noticed)
7. 5 of the "control" properties are specified as optional:
The following author controls are not required to be supported for the UA to claim conformance to CSS Text Level 3: 
*'hyphenate-limit-zone' 
*'hyphenate-limit-chars' 
*'hyphenate-limit-lines' 
*'hyphenate-resources' 
*'@hyphenate-resource'

It seems like hyphenate-limit-last should be included in that list, but is not. Was it omitted in error?

Christian
Received on Wednesday, 30 March 2011 04:22:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT