- From: Peter Moulder <pjrm@mail.internode.on.net>
- Date: Wed, 17 Jun 2015 23:51:13 +1000
- To: www-style list <www-style@w3.org>
- Cc: www International <www-international@w3.org>
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. - Use of ­ in the text is in theory another important criterion, or more generally how many break opportunities there are per line; though in practice, it's a bit messy to make use of this criterion when there are multiple paragraphs that should use the same alignment choice. - A number of classes of books in english often use justification without hyphenation, so having a multi-line line-breaking algorithm might be considered more important than hyphenation even for english. (The article cited at the start of this thread also suggests avoiding justification when using the "rudimentary" justification engines typical of today's web browsers and word processors. Though as with the previous comment on hyphenation, the advice might not apply as much to japanese languages as to english.) - 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.) - 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 favour of a "nice justification" query rather than a "supports hyphenation" query: we've said that UA hyphenation support is of questionable importance for justification in some Arabic-like languages, CJK and a number of other common languages that rarely hyphenate, Khmer family, and arguably even english-like languages (from the points about ­ and greater importance of good line breaking etc.). For some languages, quality of available hyphenations might also tilt the balance away from relying on querying UA support of hyphenation for that language. (I'm not certain that the following are examples of where a "nice justification" query would work better in practice than a "supports hyphenation" query, I'm thinking of the hyphenation patterns floating around for a some indic languages that rarely hyphenate, or cases like malayalam where the UA uses the wrong hyphenation symbol, or cases where syllable-based hyphenation often gets the wrong answer, such as german and other scandinavian languages.) - Florian didn't explicitly say, but his pseudo-class suggestion is equally applicable to his "nice justification" suggestion (":nice-justification"). pjrm.
Received on Wednesday, 17 June 2015 13:51:42 UTC