Re: [csswg-drafts] [css-text-3] Switch line-breaking handling of atomic inlines (#4949)

The CSS Working Group just discussed `Break`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> Topic: Break<br>
&lt;fantasai> I was thinking 'wrap-as: break-all | normal'<br>
&lt;fantasai> with break-all as the initial value<br>
&lt;fantasai> or something like that I guess it's not clear it only applies to objects<br>
&lt;fantasai> :/<br>
&lt;myles> i disagree with these names<br>
&lt;myles> we can discuss it in github i guess<br>
&lt;fantasai> myles, basically I think we should be clear with the initial value that it breaks everything<br>
&lt;fantasai> and that the other value is treating it as text-like<br>
&lt;myles> fantasai: how about `break-all | ideographic`<br>
&lt;fantasai> I don't like using ideographic because it sounds like the wrong thing to use for most people who will want it<br>
&lt;fantasai> It sounds like only CJK will want to use that value, but in fact it's useful in many more contexts...<br>
&lt;myles> i expect most people will want to use the break-all value<br>
&lt;fantasai> we didn't choose to emulate ID because of CJK, we chose to emulate ID because it happened to have the correct line-breaking behavior<br>
&lt;fantasai> myles, I don't think so<br>
&lt;fantasai> break-all is the default, but it doesn't give sensible behavior in running text<br>
&lt;fantasai> it breaks against nbsp<br>
&lt;fantasai> it breaks against )<br>
&lt;fantasai> it results in very awkward breaks if you actually use it in running text<br>
&lt;myles> right, most images are images. most images don't look like inline text<br>
&lt;myles> they should break on both sides by default<br>
&lt;jfkthame> advantage of `ideographic` is the clear mapping to the unicode line-break algorithm<br>
&lt;fantasai> jfkthame, yes, but that's helpful to implementers not to users :)<br>
&lt;jfkthame> we could use `ID` if you don't want it to sound so clearly CJK-ish<br>
&lt;myles> i think it's helpful to users. it tells them "what kind of text this image should behave as"<br>
&lt;fantasai> myles, most images aren't used as inline-level content in effect<br>
&lt;fantasai> myles, most people don't know about line-breaking rules for languages other than their own<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4949<br>
&lt;fantasai> myles, ideographic is extremely cryptic<br>
&lt;jfkthame> in the event we add more values (e.g. like closing-punctuation, opening-punct, etc) we'll care about that mapping being clear<br>
&lt;myles> we may want to add "alphabetic" one day, and having it be `break-all | normal | alphabetic` doesn't make any sense<br>
&lt;fantasai> myles, to the extent that images are mixed just with other images, they will continue to break<br>
&lt;myles> right, and that's not a bug<br>
&lt;jfkthame> i fear that if we try to do something other than follow the unicode classes we may paint ourselves into an awkward corner<br>
&lt;fantasai> myles, to the extent that they're mixed with punctuation, they should follow kinsoku rules<br>
&lt;fantasai> myles, treating as ID does both of these things<br>
&lt;myles> only if they're supposed to be texty<br>
&lt;fantasai> myles, breaking "([image])" inside the parens is never ok<br>
&lt;myles> disagree<br>
&lt;TabAtkins> ScribeNick: TabAtkins<br>
&lt;myles> if the image is a picture of a tree<br>
&lt;myles> then i want it to break on both sides<br>
&lt;fantasai> why????<br>
&lt;TabAtkins> don't break the forest for the trees<br>
&lt;fantasai> that makes no sense<br>
&lt;myles> cause it doesn't look like text<br>
&lt;fantasai> you put it in parens<br>
&lt;fantasai> don't care what it looks like, I can't imagine anyone wanting that to break<br>
&lt;myles> that is how all browsers behave on all content today. hard to argue it isn't a sensible default<br>
&lt;fantasai> if you didn't put it in parens, whatever.<br>
&lt;TabAtkins> Yeah, having a ( at the end of a line, then the tree and ) at the start of the next line, seems like it woudlo be broke-looking<br>
</details>


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

Received on Wednesday, 6 May 2020 15:16:06 UTC