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

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

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Fri, 31 Dec 2010 00:54:06 -0500
To: Christoph Päper <christoph.paeper@crissov.de>, www-style list <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AA8B1C0AD@MAILR001.mail.lan>
Thank you Christoph for one more vote to "loose". I like "loose" too because it is probably the easiest to remember for who doesn't have much English vocabulary like me.

I saw some arguments not liking "loose", but from the discussion, I can't find any good candidates to replace it where all can agree upon. Is it strong enough to continue looking for more candidates?

For your last question:
> 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.

The key is the paragraph before the list in the spec[1]:
> The precise set of rules in effect for the strict and loose levels
> is up to the UA and should follow language conventions.
> However, this specification does recommend that
You're right that most Japanese typographers would want to allow the other side, but we just give recommendations of *differences* between levels, and what else to be included are up to the UA. So, whether to allow the other side or not is up to the UA.

[1] http://dev.w3.org/csswg/css3-text/#line-break

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Christoph Paper
Sent: Thursday, December 30, 2010 10:31 PM
To: www-style list
Subject: Re: [css3-text] alternate name for line-break: newspaper

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 Friday, 31 December 2010 05:52:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:35 GMT