W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-text][css-conditional] language specific support for hyphenation and justification

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 17 Jun 2015 17:06:15 +0200
Cc: www-style list <www-style@w3.org>, www International <www-international@w3.org>
Message-Id: <62ED7374-C046-436D-9E13-683E74FE8545@rivoal.net>
To: Peter Moulder <pjrm@mail.internode.on.net>

> On 17 Jun 2015, at 15:51, Peter Moulder <pjrm@mail.internode.on.net> wrote:
> On Tue, Jun 16, 2015 at 03:40:30PM +0200, Florian Rivoal wrote:
>>> On 16 Jun 2015, at 15:29, Alan Stearns <stearns@adobe.com> wrote:
>>> While hyphenation is often necessary for nice justification, it isn’t the
>>> only thing that can contribute. There are also features that browsers
>>> don’t support yet like min/max word spacing and multi-line justification
>>> algorithms. Using nice-justification for just the list above would be
>>> premature, I think.
>> I agree, but then it gets tricky, as different people have different thresholds for what's nice enough. Maybe nice-justification() needs a bunch of flags so that you can indicate what you consider necessary. But agreeing on the list of flags is going to be an interesting exercise...
>> So maybe just deferring to the browser's opinion of it's own ability to justify 'nicely' in a language would be good enough in the general case, and if you're really picky about justification with specific criteria over what you want in a specific language, then you can go explicitly check over the individual features.
> A few other comments:
>  - Somewhat related to the CJK or Arabic cases is that some languages allow
>    more letter-spacing in justification than english does: I think this is
>    true of the Khmer family of languages, for example, and I think that Thai
>    is often justified without hyphenation.

Right. And it would be good for a stylesheet author to be able to turn on justification in these languages since the browser can do it well, without knowing about the requirements for these languages.

>  - I know of only one or two CSS UAs that consider more than just the
>    current line when doing line breaking, and it seems that neither has a
>    high priority on supporting @supports.  (E.g. a couple of web searches
>    didn't turn up any requests for @supports in Prince's forums.)

Typically, price users don't care about @supports or @media because they often write price-specific stylesheets anyway.

>  - Would a property-specific solution be any more likely to be implemented?
>    (E.g. "text-align: justify or start".  Apart from any objections to that
>    suggested syntax, note that this approach doesn't allow setting any other
>    property, such as 'hyphens', based on the same condition.)

In addition to the downside you mentioned, the other problem is that the criteria for switching between justify and start is then implicit, which doesn't make it particularly intuitive. Is it the hyphenation-language criteria, or the nice-justification criteria, or something else?

>  - Florian didn't explicitly say, but his pseudo-class suggestion is equally
>    applicable to his "nice justification" suggestion (":nice-justification").

Indeed, that's just the mechanism. The question of what criteria to expose remains.
Should we have :supports-hyphen and :supports-kashida and :doesnt-need-anything-fancy-to-justify-properly, or should we have the more subjective :-nice-justification, or all of the above, or can we find some more sensible things to expose?

Just brainstorming, but how about :nice-justification (still to be bikesheded of course) with optional a feature list if you know what you want, or without if you want to let the UA decide?

p { text-align: left; }

p:lang(ar):nice-justification(kashida or hyphen),
p:lang(en,fr,de):nice-justification(hyphen and multi-line-line-breaking),
p:not(:lang(ar,en,fr,de)):nice-justification() { 
  text-align: justify;
  hyphens: auto; /*presumed to be harmless in languages that don't need it*/

 - Florian
Received on Wednesday, 17 June 2015 15:06:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC