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

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

From: Christian Stockwell <cstock@microsoft.com>
Date: Fri, 18 Mar 2011 17:15:52 +0000
To: Brad Kemper <brad.kemper@gmail.com>, Christoph Päper <christoph.paeper@crissov.de>
CC: "www-style@w3.org list" <www-style@w3.org>
Message-ID: <2B4FAE26EDC5A14CAD4376398DC6DFBE6496B155@TK5EX14MBXC126.redmond.corp.microsoft.com>

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Brad Kemper
> Sent: Friday, March 18, 2011 9:10 AM
> To: Christoph Päper
> Cc: www-style@w3.org list
> Subject: Re: [css3-text] Proposed pruning & scoping of hyphenation
> properties
> On Mar 18, 2011, at 6:26 AM, Christoph Päper wrote:
> > Christian Stockwell:
> 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.
One other concern I have with supporting word-wrap: hyphenate is that we 
would then also decide how these types of hyphens should interact with
the hyphenation control properties (e.g. what if I have a limit of 2 
consecutive hyphenated lines, have two lines that end with hyphenation,
and my third line requires emergency word wrapping). This feels like a 
can of worms that we should keep closed given the real world benefit of
this value is very, very small.

> >
> >> 2. In a similar vein, I don't see a use case for the "none" value for
> "hyphens".
> >
> > People should use U+2011 (non-breaking hyphen) and similar characters
> for different scripts in those cases, but when they don’t this value could repair
> some of it. Not a strong use case, though. Furthermore, with ‘hyphenate-limit-
> before’ set to a value greater 1, my personal major use case for non-
> breaking hyphens (i.e. “e-mail” etc.) vanishes.
I see your point, but to me most such examples feel like specific examples
where we expect naïve hyphenation dictionaries to have trouble. I think most
authors will simply set hyphens to "auto", and if the dictionary is smart enough
it should detect that "e-mail" shouldn't be hyphenated. I can't think of a case
that feels like a distinct category beyond of the more general problem of 
having a "smart enough" hyphenation dictionary.

>> 3. Is there a use case that requires us to make the hyphenate properties apply to all elements?

>  p       {hyphens: auto;   display: block;}
>  name    {hyphens: manual; display: inline;}
>  acronym {hyphens: none;   display: inline;}

> I frequently disable (automatic) hyphenation for certain text templates in text processors.
Hard to argue with real world usage. This still feels like a less likely use case than
applying hyphenation on block level elements, but I agree that designers may want 
this level of flexibility.

> 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...
Given the comments from Christoph and Brad I feel that removing this clause is even more 
Important. I think some of the examples they're raising (e.g. e-mail) are a problem
specifically because we've tried to require higher priority treatment for explicit hyphens.

> > [...]
> >> 5. … the hyphenate-limit-* properties should only apply when hyphens is
> set to "auto"
> >
> > That made sense for me at first, but consider “e-mail”: I wouldn’t want a
> linebreak in there neither with ‘manual’ nor with ‘auto’, therefore I would set
> the limit to 2 or 3 characters (and I really should use a non-breaking hyphen,
> if I can control the data).
Again, this feels like an example that is only a problem if we expect hyphenation
dictionaries to be incredibly naïve. Even if we accept that they may not be 
advanced enough to correctly resolve  the "e-mail" problem, as you correctly
note authors already have a mechanism to mitigate many problematic cases.

> >
> >> conditional hyphens are already completely within the control of the
> author.
> >
> > Content author and style author need not be the same person.
> That last point is an important one. Even when they are the same person, I
> suspect there are a limited number of authors who could tell you how to type
> a conditional hyphen or non-breaking hyphen. Ideally these would be set by
> choosing the right character, but CSS could help with this a lot.
> In the case of "none" for "hyphens", there are some additional cases. For
> instance, disambiguation of words such as "recreation" (fun or sport) and
> "re‑creation" (the act of creating again), or in company names where you
> want to make it clear that the dash is part of the name, or the dash in a
> phone number (people usually use a hyphen instead of an en-dash or
> something else more appropriate). But these are also places where, if
> hyphenate-limit-* is insufficient, then a span in the source might be needed to
> fix it anyway, at which point you might as well just use a non-breaking hyphen
> in the source (if you can figure out how to type it).
I hate to sound like a broken record, but the "re-creation" example once again
feels like a problem best left to the hyphenation dictionary. I think there are 
even more complex cases that we should expect the dictionaries to handle, 
like the disparate/dispara-te case in Portuguese 
(http://www.unicode.org/reports/tr14/#Hyphen). In your other cases I tend to
agree that if neither the hyphenation dictionary nor the
hyphenation control properties are sufficient then you'd likely need to change
the source. Once you're changing the source other mechanisms are already 
available to address the problem.

Received on Friday, 18 March 2011 17:17:18 UTC

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