Re: [csswg-drafts] [css-text-3] Audit details of break-spaces value against use cases

The Working Group just discussed `Audit details of break-spaces value against use cases`, and agreed to the following resolutions:

* `RESOLVED: Spaces don't hang when break-spaces is specified`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael_> Topic: Audit details of break-spaces value against use cases<br>
&lt;dael_> github: https://github.com/w3c/csswg-drafts/issues/2465<br>
&lt;dael_> astearns: These are things we're rounding back to.<br>
&lt;dael_> astearns: This issue needs to be address to unblock something<br>
&lt;dael_> flackr: Igalia is about to impl and needs this closed.<br>
&lt;dael_> fantasai: There's several slight details. This is about break-spaces. Goal on some property is thre's a mode where editing says when you're tyuping a space<br>
&lt;dael_> fantasai: We want carat to move forward, spaces to not overflow as long as it' smore then 1em wide box so spaces don't hang.<br>
&lt;dael_> fantasai: There's currently a break spaces value on overflow wrap, but right now spaces are defined as can hang at end of line.<br>
&lt;dael_> fantasai: There's side effects of this. When you have a word at the end of the line and it fits but the space doesn't, even though you're breaking spaces it doens't move to next line but it does overflow. If you want things to wrap it's a problem this space overflows.<br>
&lt;dael_> fantasai: Related issue is that when you're trying to define intrinisic size of this box if the space is hanging it's not counted but if you want it visible you want to count it.<br>
&lt;dael_> fantasai: Seems to me if we want the space to behave like normal visible character, it should also effect size and not be hanging.<br>
&lt;dael_> fantasai: This means if the word fits and you type a space if the word fits it will wrap and we measure the space when measuring intrinisic size<br>
&lt;dael_> frWe fixed an issue in edge when people expect content:editible and not to wrap at same places because they use it for underlines. They use it as a rendering of the text.<br>
&lt;dael_> florian: So rendering should be same either way even if the reason is because when it's editable you wouldn't want anything else.<br>
&lt;dael_> florian: We're not proposing a difference, we're proposing both modes are same but when you're in editing the new behavior is sane, not almost sane.<br>
&lt;dael_> fremy: WE did the reverse.<br>
&lt;dael_> fremy: We made it so that when layout not taking space<br>
&lt;dael_> fantasai: fremy fix where you made them match that's good and if they want spaces to show and say break-spaces the spaces take up space.<br>
&lt;dael_> florian: But why align editable and not to not take space.<br>
&lt;dael_> fremy: Most content web is spaces not so we changed to that case.<br>
&lt;dael_> florian: It's hanging but it's there.<br>
&lt;dael_> fantasai: Edge behavior is in the spec now as most recommended as I recell<br>
&lt;dael_> fantasai: Change is that spaces don't hang when break-spaces is specified.<br>
&lt;dael_> florian: Rest is consiquences of that.<br>
&lt;dael_> fremy: Sounds good.<br>
&lt;fantasai> s/consiq/conseq/<br>
&lt;dael_> astearns: Obj to Spaces don't hang when break-spaces is specified?<br>
&lt;dael_> RESOLVED: Spaces don't hang when break-spaces is specified<br>
</details>


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

Received on Thursday, 12 April 2018 12:57:22 UTC