- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 May 2019 19:49:35 +0000
- To: public-css-archive@w3.org
> Well, it's not just "a way of interpreting", it's literally how the text explains break-all Fair point. :) > I'm not sure why not? AFAICS, the kind of differences the spec describes between strict, normal and loose can similarly be handled by overriding the line breaking classes Some of them... I'm not so sure about handling the breaks between inseparable characters, or the variants of Thai dictionary breaking. > white-space isn't really comparable to word-break and line-break. It's about white space processing (collapse, preserve, ...) rather than about identifying soft break opportunities between characters. It also controls whether breaking is allowed within the element or not, though. So although it does control white space collapsing as well, it is also a line-breaking control and is frequently used as such. > [A soft wrap opportunity] occurs at the boundary but is defined as a consequence of the line-breaking classes of the characters on each side of the boundary. Right, but it's a consequence of the pairing. E.g. you can't break between two horizontal ellipsis characters, or between two alphabetic characters, or between an alphabetic character followed by a horizontal ellipsis; but you can break between a horizontal ellipsis followed by an alphabetic character. Creating a break opportunity is not a fundamental characteristic of the horizontal ellipsis or the alphabetic character; but some of their pairings will allow breaks. Pairing … and … together isn't allowed to break under `strict` but can under `loose`. If one is wrapped in `strict` and the other in `loose`, is the break allowed or not? An implementation based on reclassifying UAX14 classes might come up with a particular answer, but from the typographer's point of view how do you answer that question? -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3897#issuecomment-491041315 using your GitHub account
Received on Thursday, 9 May 2019 19:49:37 UTC