W3C home > Mailing lists > Public > www-style@w3.org > December 2010

Re: [css3-text] alternate name for line-break: newspaper

From: Christoph Päper <christoph.paeper@crissov.de>
Date: Thu, 30 Dec 2010 14:30:49 +0100
Message-Id: <4289205E-2039-4BBF-9F75-B7A82C71B5E5@crissov.de>
To: www-style list <www-style@w3.org>
Koji Ishii:

> It looks like it's not easy to reach consensus even for native English speakers.

As always.

I agree that it’s not good practice to have some keyword express a sample application (‘newspaper’) while others give a level of strictness (‘normal’, ‘strict’, also ‘auto’) and another one describes the method employed (‘keep-all’) – that last one is listed in the property table but is not described further in the current ED (unlike the WD).

For strictness, the sequence ‘loose’, ‘normal’, ‘strict’ seems quite natural to me, disregarding the valid point that “lose” is often misspelled “loose” and probably vice versa. I could live with ‘lenient’, too, and I don’t share the objection that ‘basic’ implys the same level as ‘normal’.

CSS should continue to use comparatives (‘looser’, ‘stricter’) only in a relative, not in an absolute meaning, cf. ‘font-weight’. You could use elatives (‘very-loose’, ‘very-strict’) or superlatives (‘loosest’, ‘strictest’) of course. It seems, though, that several lexemic alternatives have been proposed, i.e. ‘free’/‘minimal’ (= ‘loosest’) and  ‘relaxed’ (= ‘loose’ with that becoming loosest), of which one is probably as good as the other.

If you can come up with good sample applications, like ‘newspaper’, ‘magazine’, ‘book’, ‘letter’ or the like, you could also settle on them, but that’s not really what CSS does elsewhere. (I think XSL and SVG did it once or twice.) “Newspaper” also implies multiple, narrow columns, so maybe that charateristic is a more appropriate source for a keyword.

JFTR: I dislike language- and script-specific properties or descriptions thereof. ‘line-break’ as currently written seems like one, although its name doesn’t hint at it.

> Should we move on to numbers as David Singer suggested?

Absolutely no, that’s very unCSSy. 

The only counter-example I can think of from the top of my head, ‘font-weight’, is based upon implementation details of another format (Truetype, I think), is hardly used in the wild and should have aliases for not some but all its nine number values anyhow. (I proposed and described a system in <http://lists.w3.org/Archives/Public/www-style/2010Sep/0463.html> for the font descriptor of the same name, but that could be used for the property as well.)

The suggested numbers here are completely arbitrary, i.e. they don’t relate to the restrictions described in the section at all, because there is no scale of any kind.

The ED currently says (slightly rephrased) that line breaks are (suggested to be) …

… allowed in ‘loose’, ‘normal’ and ‘strict’
 - at white space or other word divider
   (Are visible word dividers removed at line breaks?)

… allowed in ‘loose’ and ‘normal’, forbidden in ‘strict’:
 - before small kana
   (What about after sokuon (small TU)?)
 - before kana prolonged sound mark (tyôonpu)
 - before hyphens, if Chinese or Japanese

… allowed in ‘loose’, forbidden in ‘normal’ and ‘strict’:
 - before iteration marks
 - between inseparable characters
 - before middle dots, if Chinese or Japanese
 - before dividing punctuation marks, if Chinese or Japanese
 - before postfixes, if Chinese or Japanese
 - after prefixes, if Chinese or Japanese

In table format:
                                 ‘loose’    ‘normal’   ‘strict’  
 small kana                    |  before     before        –
 kana prolonged sound mark     |  before     before        –
 hyphens (zh, ja)              |  before     before        –
 hyphens (else)                |     –          –          –
 iteration marks               |  before        –          –
 inseparable characters        |  between       –          –
 middle dots (zh, ja)          |  before        –          –
 middle dots (else)            |     –          –          –
 dividing punctuation (zh, ja) |  before        –          –
 dividing punctuation (else)   |     –          –          –
 postfixes (zh, ja)            |  before        –          –
 postfixes (else)              |     –          –          –
 prefixes (zh, ja)             |  after         –          –
 prefixes (else)               |     –          –          –

I suppose most of those rules imply that the other side of the character (usually “after”) is an allowed line break point even in ‘strict’. This is not clear from the current text, though.
Received on Thursday, 30 December 2010 13:31:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:41 UTC