- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 Mar 2011 20:43:00 -0700
- 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 UTC