- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 May 2019 17:26:11 +0000
- To: public-css-archive@w3.org
- Wrt @kojiishi's https://github.com/w3c/csswg-drafts/issues/3897#issuecomment-490397810 ; yes, the spec text Florian quotes says line-breaking between two characters—where the line break opportunity is created by the pairing, not the individual character (as by a word-separator character)—is by the nearest common ancestor, so Chrome's rendering in the OP would be correct. This behavior seems reasonable to me. - Afaict @jfkthame's intuition is that `word-break` is applied to characters not to break opportunities, e.g. it effectively reclassifies AL as ID or vice versa, and behavior at boundaries falls out of that reclassification. This seems like a reasonable alternate way of interpreting `word-break`. - However, per-character logic is not one that transfers well to `line-break`, and is definitely not something we can apply to `white-space`, consider `<nobr>中文</nobr><nobr>中文</nobr>`. It would maybe be ideal to be consistent in how we consider all line-breaking properties at an element boundary, as these are confusing enough already. - I think Florian's examples in https://github.com/w3c/csswg-drafts/issues/3897#issuecomment-490847382 are fairly compelling... although 1 and 2 could also be done with `white-space: nowrap`. It might be interesting to compare use cases if @jfkthame's preferred behavior helps some others. - It's important to me that behavior be symmetric. WebKit's behavior (interpreting the boundary one way at the start, and a different way at the end, of the inline) is imho unacceptable. Altogether, I'd conclude the current spec behavior is best; but might be convinced otherwise if there are compelling use cases to change. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3897#issuecomment-490993571 using your GitHub account
Received on Thursday, 9 May 2019 17:26:12 UTC