Re: [csswg-drafts] [css-text] Clarify whether soft breaks exist at boundaries of an inline element with `word-break:break-all` (#3897)

The CSS Working Group just discussed `Breaking Rules at inline element boundaries`, and agreed to the following:

* `RESOLVED: It's undefined`
* `RESOLVED: i.e., the presence of soft break opportunities between spans which change soft breaking opportunities is undefined`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Breaking Rules at inline element boundaries<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/3897<br>
&lt;heycam> fantasai: there was an issue raised about what happens when you have two inline elements that have different ine breaking rules<br>
&lt;heycam> ... 3 props control this.  white-space, word-break, line-break<br>
&lt;heycam> ... looking at an example (in the GitHub issue)<br>
&lt;heycam> ... at the boundaries of the span, which line breaking rules applies when it has a different word-break prop value to the rest of the text<br>
&lt;heycam> ... for white-space, the nearest common ancestor is used<br>
&lt;heycam> ... the complication for word-break and line-break is that the determining rules for where you're allowed to break requires running an analysis on a lot of text<br>
&lt;heycam> ... and every time that value changes you have to do another run, so impl wise it's a bit awkward<br>
&lt;heycam> ... there's been some discussion about what's the best behavior here<br>
&lt;heycam> ... I wanted to ask i18n if you have feedback on this issue<br>
&lt;heycam> ... and ask the WG if this proposal to leave this undefined for L3, give impl time to experiment<br>
&lt;heycam> ... doesn't seem to be a terribly high importance case to solve at the moment<br>
&lt;heycam> florian: I think one of the more interesting cases -- and I suppose making it undefined -- is if the aprent div allows a break between every latter, and two spans next to each other which don't<br>
&lt;heycam> ... can you break between the spans or not<br>
&lt;heycam> ... current spec says yes, but it's hard-ish to implement<br>
&lt;heycam> .. if we need time to think about this, undefine it for a while, seems reasonable<br>
&lt;heycam> ... but that's the kind of case this brings to the surface<br>
&lt;heycam> Rossen: any objections to leaving it undefined?<br>
&lt;heycam> r12a: we should look at it as a group offline<br>
&lt;heycam> ... it's quite a long thread. I seem to remember someone brought up an example that didn't work<br>
&lt;heycam> nmccully: are there layout engines working on this that would benefit from the extra time?<br>
&lt;heycam> fantasai: part of the issue is part of the ICU APIs make it awkward for the rules to change in the middle of the line<br>
&lt;heycam> ... so impl wise it's awkward<br>
&lt;heycam> ... could be factorial if you're changing it every other letter in the line<br>
&lt;heycam> ... so there's some hesistancy to impl that given the current infrastructure<br>
&lt;heycam> ... but there doesn't seem to be great solutions<br>
&lt;heycam> ... some of the behaviours you'd get from doing an easy thing would be non-symmetrics<br>
&lt;heycam> ... you'd be switching slightly less if you use the current rule in the spec<br>
&lt;heycam> ... there's not a high pressure to solve this and get interop<br>
&lt;heycam> ... look at it again in L4<br>
&lt;heycam> myles: tangential comment, the general thing we're discussin is styling element boundaries<br>
&lt;heycam> ... this is something letter-spacing also does<br>
&lt;heycam> ... the spec says something that all browsers diagree ith<br>
&lt;heycam> ... with we do come up with a good way to describe boundary behavior, we should try to use this system to describe letter-spacing too<br>
&lt;heycam> fantasai: I think the spec is right on letter-spacing<br>
&lt;heycam> ???: I think it would be good to have a general way to handle this<br>
&lt;heycam> florian: we have a current generalized rule, that is general, and does the right thing, and is painful to impl<br>
&lt;fantasai> s/???/nigel/<br>
&lt;heycam> RESOLVED: It's undefined<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/3481<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/337<br>
&lt;heycam> RESOLVED: i.e., the presence of soft break opportunities between spans which change soft breaking opportunities is undefined<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3897#issuecomment-532057510 using your GitHub account

Received on Tuesday, 17 September 2019 04:50:45 UTC