- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Apr 2018 16:02:16 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Allow for paragraph-level line breaking`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Allow for paragraph-level line breaking<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/672#issuecomment-379723234<br> <dael> fantasai: astearns added a new feature and there was limited discussion. I feel we should have more check in with the group.<br> <dael> astearns: Issue is pretty long.<br> <astearns> https://drafts.csswg.org/css-text-4/#text-wrap<br> <dael> fantasai: Discussion was from myles asking to opt into more expensive line breaking algo with better results. Discussion landing on adding a switch. text-wrap property in L4 is a longhand of white space that only controls wrapping. Has values to say wrap, don't wrap, try to balance lines for same length. Proposal was add a value called multi-line that does one of these more expensive algos.<br> <dael> fantasai: We've talked about fancy wrapping algorithms before.<br> <dael> eae: It's not that we don't want to impl, it's not a priority.<br> <dael> astearns: I added it to the spec as a this would be nice to have.<br> <dael> fantasai: Alternative is you do it anyways and you don't need an opt in.<br> <dael> eae: Opt in is nice since it's quite a bit mroe costly.<br> <dael> myles: You can't have this on by default.<br> <dael> myles: THis will be way slower.<br> <dael> fantasai: If concern is about perf we might want a note to say if someone impl and discovers no perf issues.<br> <dael> florian: If you want to do it and have made it fast you can apply to both.<br> <dael> astearns: When I added the value the defualt says you may consider multi lines and the UA may optimize for speed. And for multiline algo should counsider multiiple lines and should bias for layout over speed.<br> <dael> RIck: UA could descide this is giant and we won't do it anyway?<br> <dael> myles: Yes. There's 100 criteria for a beautiful paragraph and it's impossible to do all. Browsers should be free to pick and choose.<br> <dael> fantasai: Sounds like what you want is text-wrap:expensive<br> <dael> fantasai: If that's what it's conveying let's convey that. There are lots of other thigns to consider.<br> <dael> myles: But balance is also expensive. Different algo for different reasons.<br> <dael> fantasai: Wrapa nd multiline are trying for the same effect.<br> <dael> florian: You're not asking for slow. You're asking for pretty even if it's slow.<br> <dbaron> high-quality-wrap?<br> <dael> myles: It isn't one spectrum, there are different algo with different purpose<br> <dael> jpamental: As a designer there's many things to optimize on. I'd like the pretty to have everything laid out, but I also recognize that's hard. Maybe target which things you want to prioritize but that's a different solution. Assigning priority to the thing you want to address.<br> <dael> myles: WE could make it more complicated but there's 0 impl so simple would be good.<br> <dael> astearns: Concerns with leaving this prospective value in?<br> <dael> fantasai: If it's not clear waht we're aiming at I don't know if it makes sense to have a keyword. If someone wants to impl a fancy line wrapping algo they can come back and ask for a switch and what they optimize for and then we can deiscss waht switch we want.<br> <dael> astearns: I think it's a case that a shared characteristic is that it considers more then one line at a time. A multiline value that can encompass a range os strat is appropriate. I feel that deciding on this is the pretty strategy for the web and getting everyone to agree on a algo won't happen. I wanted to leave it a little open so people can experiement with what they'd trade.<br> <dael> fantasai: I think multiline isn't clear.<br> <dael> myles: Let's call it pretty<br> <dael> fantasai: Sure.<br> <dael> florian: We started with paragraph and we shifted to multiline because it doesn't always consider the whole paragrpah.<br> <dael> myles: maybe not pretty because titles don't want this.<br> <dael> astearns: I'm happy to bikeshed on name. multiline is pretty well known by the breed of people that use indesign.<br> <dael> florian: There was a thing for a switch...for editing purposes you don't want the algo.<br> <dael> astearns: Separate issue for that.<br> <dael> fantasai: In taht case you want stable and something else.<br> <dael> astearns: And there's a note at the end of the section on that problem.<br> <dael> myles: If we were to impl we prob would make multiline same as wrap.<br> <dael> florian: We're pretyt much repeating this issue and the issue says we don't want a sep property from wrap but wrap-sable and wrap-pretty.<br> <dael> fantasai: I like it as a modifier.<br> <dael> dbaron: Agree wrap should be in the same.<br> <dael> myles: Should balance also have wrap?<br> <dael> Rick: multi-line line breaks would be just fine<br> <dael> florian: If you say wrap UA must not consider multiple lines. If you call for stable and you don't want regiggle you shouldn't consider. If you turn of the editing you want stable.<br> <dael> astearns: We're at time. I've got some of this discussed. Do you want a resolution fantasai ?<br> <dael> fantasai: I think we agree it's a modifier on wrap not a sep keyword.<br> <dael> astearns: I believe there is a sep issue on editing and multi line<br> <dael> astearns: Resolution that we shoudl change value to wrap-nice, wrap-better...something?<br> <dael> astearns: Issue is open we can bikeshed there.<br> <dael> fantasai: We can make it a modified on wrap.<br> <dael> koji: If multiline is modifier balance should be one too.<br> <dael> astearns: We're at time. I don't hear consenses and I would object to putting wrap as a modifier on all of the properties.<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-380505989 using your GitHub account
Received on Wednesday, 11 April 2018 16:02:20 UTC