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 03:15:47 +0000
To: "www-style@w3.org" <www-style@w3.org>
CC: fantasai <fantasai.lists@inkedblade.net>
Message-ID: <2B4FAE26EDC5A14CAD4376398DC6DFBE6498D35B@TK5EX14MBXC122.redmond.corp.microsoft.com>
> -----Original Message-----
> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> Sent: Tuesday, March 29, 2011 6:02 PM
> To: Christian Stockwell
> Cc: www-style@w3.org
> Subject: Re: [css3-text] Proposed pruning & scoping of hyphenation
> properties
> On 03/15/2011 07:43 PM, Christian Stockwell wrote:
> > Some feedback after reading through the hyphenation discussion in the
> > latest F2F transcript:
> >
> > 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. I'm referring to this stumble as an indication of linguistic incorrectness, although that is perhaps not the most appropriate term (note: I'm not a linguist). 

If readers are already going to stumble whether a word is broken with "hyphenate" or with "break-word", then let's avoid complicating the spec and the lives of authors (who would now have to understand how this "hyphenate" relates to all the other "hyphens/hyphenate" properties). At the end of the day this is a case that authors will want to avoid at all costs because of the dire implications for readability (in either solution). 

> > 2. In a similar vein, I don't see a use case for the "none"
> > value for "hyphens". All browsers now seem to implement the equivalent
> > of "manual", and I haven't ever seen a request to disable that
> > behaviour. I think we should eliminate the value unless/until there's
> > a strong use case for it.
> If the author wants no hyphenation in a paragraph, then there should be a
> way to prevent soft hyphens from breaking. I think this control does make
> sense. See also Brad's comment about the separation of content and style.

I suspect that we'll never encounter this in practice, but I'll acquiesce on this point as supporting "none" does seem to match the spirit of CSS.

> > 3. Is there a use case that requires us to make the hyphenate
> > properties apply to all elements? Unless there's a use case I'd like
> > to make them apply only to block level elements.
> I think the ability to tweak hyphenation settings on an inline element is useful.
> Some of the controls do not make sense on inlines (and they are
> appropriately set to apply only to block containers), but 'hyphens' itself and
> the word limits do.

I believe Brad replied earlier here and I agree that there are valid use cases for inline elements.

> > 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.

> > 6. It looks like we resolved to make "hyphenate-limit-zone"
> > be relative to the line box. Is there any reason why that's
> > preferable? From a design perspective it still seems like the intent
> > behind hyphenation is to achieve a visual effect across a block of
> > text rather than a per-line basis. Doesn't resolving % zone against
> > the line box make it more difficult to deliver on that intent?
> Generally (but not always) hyphenation is used in conjunction with justification.
> Its purpose is to reduce the amount of space that the text has to soak up.. If a
> particular line is shortened, e.g.
> due to a float, then even if it is soaking up the exact same amount of space
> as the full-length line above it, it will be much more stretched-out, due to the
> lesser amount of text available to soak up the space.
> ~fantasai

I just realized that I was wrong here (and why). I agree that to achieve the desired text density it is most appropriate to resolve the % against the line box. 

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?

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).

Received on Wednesday, 30 March 2011 03:18:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:57 UTC