Re: [csswg-drafts] [css-text-4] Allow for paragraph-level line breaking (#672)

The CSS Working Group just discussed `text-wrap: multi-line`, and agreed to the following:

* `RESOLVED: Add the value back in`
* `RESOLVED: add the stable value`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: text-wrap: multi-line<br>
&lt;emilio> github-: https://github.com/w3c/csswg-drafts/issues/672<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/672<br>
&lt;emilio> myles__: Similar to houdini, there are lots of different ways to do line-breaking, houdini solves some of them, other ways people want to do line breaking are some fancy book-like line-breaking<br>
&lt;emilio> myles__: line-breaking on the web is greedy, and doing something slower but higher quality is a longstanding request<br>
&lt;emilio> myles__: I proposed a value for this, which got to the spec and then got removed because of lack of consensus<br>
&lt;florian> q+<br>
&lt;dauwhe> q+<br>
&lt;xfq> zakim, open the queue<br>
&lt;Zakim> ok, xfq, the speaker queue is open<br>
&lt;dauwhe> q+<br>
&lt;emilio> myles__: I'd like to see which  opinions for this<br>
&lt;eae> q+<br>
&lt;emilio> myles__: it's a very high-level switch<br>
&lt;emilio> florian: I want to know which one is the author value<br>
&lt;emilio> florian: I want one of the values to be stable when you type<br>
&lt;astearns> default is 'wrap' which is stable<br>
&lt;heycam> q+<br>
&lt;emilio> myles__: right now the default is stable in every browser<br>
&lt;emilio> florian: not for print<br>
&lt;emilio> myles__: you don't type in print preview<br>
&lt;emilio> myles__: I don't think you need another value, we already have it<br>
&lt;emilio> florian: I think there should be a stable value<br>
&lt;emilio> myles__: I think reflecting reality and saying that auto should be stable is fine<br>
&lt;emilio> fantasai: I think the initial value should allow the UA to do whatever<br>
&lt;xfq> ack dauwhe<br>
&lt;Rossen> q?<br>
&lt;emilio> dauwhe: If the property is added to iBooks I'll add it everywhere<br>
&lt;emilio> dauwhe: I think you want to change it in existing books too<br>
&lt;fantasai> fantasai: I think iBooks should just add it to its default UA<br>
&lt;xfq> ack eae<br>
&lt;emilio> dauwhe: having the text break better is just going to be a win<br>
&lt;emilio> eae: I think this is a great idea, I'm a bit concerned that if we don't define what pretty does we'd get interop issue, so we should try to explain what pretty would do<br>
&lt;emilio> myles__: in the issue I listed a dozen different criteria<br>
&lt;emilio> myles__: so describe it explicitly is probably not realistic, do you think agreeing on the goals is fine?<br>
&lt;dauwhe> q?<br>
&lt;emilio> eae: yeah, I think that's ok<br>
&lt;dauwhe> q+<br>
&lt;emilio> fantasai: dauwhe: myles__: I think it's important to _not_ get compat<br>
&lt;AmeliaBR> There will always be perf trade-offs, so that it makes sense that a print book will get prettier `pretty` results than a browser on a low-CPU device.<br>
&lt;fantasai> s/fantasai: dauwhe: myles__:/fantasai, dauwhe, myles:/<br>
&lt;emilio> heycam: I was going to make eae's point, though maybe I'm a bit more worried about the compat impact, I don't we can change the default algorithm because of compat, why wouldn't that happen with `pretty`?<br>
&lt;emilio> astearns: the current algorithm is not that interoperable<br>
&lt;emilio> myles__: also, this is an opt-in<br>
&lt;Rossen> ack heycam<br>
&lt;emilio> heycam: once we have this, why would we not expect authors to just use it all the time. Why would they not do that?<br>
&lt;emilio> myles__: it's the same answer for text-rendering: optimizespeed vs. optimizelegibility<br>
&lt;emilio> fremy: it's mostly useless<br>
&lt;emilio> myles__: AmeliaBR: it's not<br>
&lt;emilio> heycam: I don't think people will think about speed, and many people will just use it without thinking about it, having a perf impact<br>
&lt;emilio> astearns: I think that's a reason for the auto value<br>
&lt;emilio> astearns: so that the ua can change it<br>
&lt;emilio> heycam: I'm skeptic about changing line-breaking<br>
&lt;emilio> (by default)<br>
&lt;xfq> ack dauwhe<br>
&lt;emilio> myles__: I'd like to keep the discussion less about the existence of auto<br>
&lt;emilio> dauwhe: I think there are a lot of tradeoffs. Browsers are optimized for speed right now, and taking any step to opt in to better systems is going to be great regardless of interop<br>
&lt;emilio> dauwhe: text layout is so sensitive that there's never going to be interop<br>
&lt;emilio> myles__: I want to resolve to put this value back in<br>
&lt;emilio> Rossen: objections?<br>
&lt;fantasai> ScribeNick: florian<br>
&lt;fantasai> florian: I want to make sure we have the three values, including stable.<br>
&lt;dbaron> ScribeNick: fantasai<br>
&lt;emilio> ScribeNick: emilio<br>
&lt;emilio> fantasai: I think we should rename it, but no objection<br>
&lt;emilio> fantasai: I'm a bit concerned that we are going to add another switch that does nothing<br>
&lt;emilio> fantasai: but if people feel strongly I won't object<br>
&lt;emilio> fremy: not an objection either but we need a better definition on what it does<br>
&lt;emilio> RESOLVED: Add the value back in<br>
&lt;emilio> fantasai: are we adding stable?<br>
&lt;AmeliaBR> scribeNick:<br>
&lt;AmeliaBR> scribeNick: AmeliaBR<br>
&lt;emilio> myles_: there are three values: auto, balance and this new thing<br>
&lt;emilio> fantasai: I object to the multi-line name<br>
&lt;AmeliaBR> scribeNick: emilio<br>
&lt;emilio> myles_: proposals?<br>
&lt;emilio> fantasai: pretty sounds good to me<br>
&lt;emilio> fantasai: it's what we used to discuss it here<br>
&lt;emilio> RESOLVED: add the stable value<br>
</details>


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

Received on Wednesday, 27 February 2019 23:16:05 UTC