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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 29 Mar 2011 18:02:13 -0700
Message-ID: <4D928115.40705@inkedblade.net>
To: Christian Stockwell <cstock@microsoft.com>
CC: "www-style@w3.org" <www-style@w3.org>
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.

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

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

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

> 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
Received on Wednesday, 30 March 2011 01:02:49 GMT

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