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

[css3-text] line-break (was RE: [css3-text] Splitting CSS Text into Level 3 and Level 4

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Fri, 25 Nov 2011 02:20:08 -0500
To: Florian Rivoal <florianr@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0D24150A6A@MAILR001.mail.lan>
> >>> * line-break
> >>
> >> I am still not a big fan of this one. With the tweaks made to it
> >> [snip]
> >
> > It is also implemented, unprefixed, in IE.
> It is. Does it do in IE exactly what the spec says? The syntax is the same, but what about
> the semantics? Is it used much? I think the answer to these questions is no, so I don't really
> see what difference it makes for IE's to have it already, since we're not documenting
> existing behavior that is being relied on by existing content.
> IE can have its property without the WG specifying it, as they already do.
> If we want this to work interoperably, we should specify it, but if nobody is asking for this,
> I don't see why we should bother.

Search by "CSS Kinsoku (line-breaking-rule in Japanese)"[1] (Japanese results, I hope you can read them :) hits 45K results, and most are:
* IE doesn't break Japanese lines correctly, because some people believes break before small kana must be prohibited but IE defaults to "normal", and recommends IE-specific property "line-break: strict".
* IE sometimes break lines before closing parenthesis, and "line-break: strict" can fix the issue. I suppose it's a bug.
* Chrome/Safari doesn't break Japanese lines correctly, but "word-break: normal; word-wrap: break-work;" can fix the problem for punctuation cases. I have no idea how it can fix the issue, and also note that recent WebKit has improved its default behavior very much.

This concludes me that Web authors want consistent line breaking rule, and the most desired switch is between "normal" and "strict" (small kana changes behavior between the two values.) There should be an interoperable way to do this for Web.

Another use case is for web apps. For desktop apps, all word processors, presentation apps, and even spreadsheets support line breaking rules, but web apps can't do that today.

> I acknowledge that for EPUB purposes, some control over line breaks is desired, but I am
> not convinced that what is currently proposed addresses the EPUB use cases. If it doesn't,
> that may leave us without anybody interested in the current proposal.
> Which is why I am asking: Does anyone other than EPUB care about this? If not, is this good
> enough to address EPUB's needs?

As you pointed out, EPUB wants more. Fantasai and I talked with several publishers and all of them said they want per-character control. You're right about that.

But when we asked to choose between: 1) nothing in level 3 but a precise control in level 4, and 2) preset choices in level 3 and consider more in level 4, all of them preferred having presets.

I think the current proposal matches to the web requirements, and also to the minimum requirements for EPUB. We could extend more in future levels if the desire expands, but it suffices the minimum requirements for both players.

[1] http://www.google.co.jp/search?hl=ja&q=css+%E7%A6%81%E5%89%87 [Japanese]

Received on Friday, 25 November 2011 07:21:51 UTC

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