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 20:43:00 -0700
Message-ID: <4D92A6C4.70007@inkedblade.net>
To: Christian Stockwell <cstock@microsoft.com>
CC: "www-style@w3.org" <www-style@w3.org>
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?

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

Received on Wednesday, 30 March 2011 03:43:48 UTC

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