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

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

From: Christian Stockwell <cstock@microsoft.com>
Date: Wed, 16 Mar 2011 02:43:53 +0000
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <2B4FAE26EDC5A14CAD4376398DC6DFBE649685BF@TK5EX14MBXC126.redmond.corp.microsoft.com>
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

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.

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.

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

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 completely within the
control of the author.

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?

Christian Stockwell
(Internet Explorer Program Manager)

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of fantasai
Sent: Monday, March 14, 2011 2:33 PM
To: www-style@w3.org
Subject: [CSSWG] Minutes and Resolutions F2F Mountain View March 2011 Day 3: CSS3 Text

   - Reviewed CSS3 Text draft.
   - RESOLVED: drop unrestricted value from text-wrap
   - RESOLVED: use 'inter-character' instead of 'bopomofo' for ruby-position
   - RESOLVED: add 'hyphenate', don't add 'none', to 'word-wrap'
   - RESOLVED: Make percentages on hyphenation-limit-zone relative to line box
   - RESOLVED: rename white-space-collapsing to bikeshedding

.... [Remainder of notes not included]
Received on Wednesday, 16 March 2011 02:47:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:57 UTC