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

~fantasai
Received on Wednesday, 30 March 2011 03:43:48 GMT

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