- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 21:44:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-text] Preventing too-short final lines of blocks (Last Line Minimum Length)`, and agreed to the following: * `RESOLVED: Add a control that is either a property or a value that causes UAs to make the last line longer than it would've originally done unless that was a bad idea` <details><summary>The full IRC log of that discussion</summary> <fantasai> myles: this is a small issue ....<br> <fantasai> myles: We have had many requests throughout the years where typographers and designers have come to us and show us a paragraph on the web page<br> <fantasai> myles: they'll point to last line and say, 'this last line is tooooo narrow"<br> <fantasai> myles: this has a name, it's called orphans and widows<br> <fantasai> myles: also term has two meanings<br> <fantasai> myles: CSS has support for the other meaning (pagination)<br> <fantasai> myles: but for this one, doesn't<br> <fantasai> myles: this is one of our highest requested text-related features<br> <fantasai> myles: so it would be cool if CSS could solve<br> <fantasai> myles: problem here is that last line is too narrow, so get wide paragraph and maybe one word on last line. Looks bad<br> <fantasai> myles: more nuance, but what I will say is, I think there's two potential solutions<br> <fantasai> myles: one is a new property, and one is a change to value space of `text-wrap: pretty`<br> <Rossen_> q?<br> <fantasai> myles: so could invent a new property or add a thing that when you do pretty, try to focus on the last line<br> <Rossen_> ack emilio<br> <fremy> lol<br> <florian> q+<br> <iank_> q+<br> <fantasai> florian: text-wrap: pretty solves this and more, and is expensive<br> <fantasai> florian: and that's important<br> <fantasai> florian: if it wasn't expensive, just using pretty would be fine<br> <fantasai> florian: there are terrible solutions to this problem<br> <fantasai> florian: if you implement one that is "good enough"<br> <Rossen_> ack florian<br> <fantasai> florian: is there enough perf difference with pretty that it's worth a separate control<br> <fantasai> hober: very significant perf difference<br> <fantasai> myles: naive implementation of pretty is exponentially bad perf<br> <fantasai> myles: whereas an algorithm that just focuses on this problem would be at worst linear, but almost constant time<br> <nicole> q+<br> <Rossen_> ack iank_<br> <fantasai> iank_: yes, expensive, but we might have different perspectives on how expensive we're willing to tolerate for pretty<br> <fantasai> iank_: lot of nuance there, let's not get into it now<br> <fantasai> iank_: from our perspective, if there is a control, it would be nice if it could also control pretty<br> <fantasai> iank_: fundamentally, pretty does have a lot of knobs like "how much to bias for x consideration"<br> <fantasai> myles: if independent control for last line and pretty, browser could see and modify pretty to focus on last line<br> <fantasai> iank_: potentially<br> <fantasai> myles: that sounds great<br> <Rossen_> ack nicole<br> <fantasai> nicole: I wanted to ask, how many lines would be impacted by that<br> <fantasai> myles: I think we're flexible here, not super clear what the spec should say<br> <astearns> -1 to only stealing words from one line<br> <fantasai> myles: if we were to implement this, first version would start at 1 line and then iterate from there and see if need to increase<br> <fantasai> nicole: similar to headline balancing?<br> <fantasai> iank_: not really<br> <florian> q+<br> <fantasai> hober: taking a first pass would only use one line, but I can imagine empiricially discovering that we can tolerate 3-4 and might have a spec, but let's not prematurely decide<br> <Rossen_> ack florian<br> <fantasai> florian: are you aiming for a yes/no property or are you thinking of giving author control like at least 3em or at least 30%<br> <fantasai> myles: flexible<br> <fantasai> myles: Firstly, we now using words is long<br> <fantasai> myles: not clear, in i18n context, what exactly a word is<br> <astearns> s/long/wrong/<br> <fantasai> myles: from implementation perspective, can make a boolean<br> <fantasai> myles: if authors need more control, can add<br> <fantasai> myles: when authors request this, they usually request a percentage<br> <fantasai> myles: e.g. at least 15%<br> <florian> q?<br> <Rossen_> s/15%/50%/<br> <fantasai> iank_: is that what they actually want, or think that's the tool that indesign provides...<br> <fantasai> myles: I don't know, but my proposal is a boolean switch<br> <florian> q+<br> <astearns> q+<br> <fantasai> myles: and as implementations progress, we can see if that makes sense or not<br> <florian> q- later<br> <fantasai> smfr: should we just resolve on adding a property without specifying if boolean or not?<br> <Rossen_> ack astearns<br> <fantasai> astearns: for a prperty that does only this one thing<br> <fantasai> astearns: I would advocate strongly for just a boolean switch<br> <fantasai> astearns: anything more finely grained is really going to have to be weighed against other line-breaking considerations<br> <fantasai> astearns: and needs to modify results of pretty<br> <fantasai> astearns: if we're separating the two, then the simple thing, should just be a boolean<br> <fremy> q+<br> <Rossen_> ack florian<br> <fantasai> florian: I think I support this because of the perf difference<br> <fantasai> florian: but even then it does feel like it's a variant of pretty, you've decided what you care about<br> <fantasai> florian: so is it really separate from pretty?<br> <fremy> wanted to say the same thing<br> <fremy> q-<br> <emilio> fantasai: There are a lot of knobs that factor into pretty and a lot of them are already separate knobs<br> <fremy> q+<br> <emilio> ... In level 4 or some other we had word-spacing and letter-spacing give you the optimal value but we also give you a range for the line-breaker to play with<br> <iank_> q+<br> <emilio> ... that's a factor into the line breaker<br> <emilio> ... same for hyphenation controls<br> <emilio> ... these are already split out into multiple controls<br> <emilio> ... turning on pretty shouldn't need to redeclare your controls<br> <emilio> ... so should cascade separately<br> <emilio> ... I agree with myles, we should have this tweak<br> <florian> [Florian is convinced]<br> <emilio> ... I'd like something that can be applied to the html spec and not spin for 10 minutes<br> <emilio> ... I also agree with astearns that you have to look a more than one line<br> <nicole> q+<br> <emilio> ... A boolean switch is fine but we should define this thinking of extending it to percentages too<br> <myles> sooooo `minimum-last-line-length: normal | auto [maybe more in the future]`<br> <emilio> fantasai: If we spec it out we need to pick a name that's gonna work for both<br> <emilio> ack fantasai<br> <florian> q+<br> <fantasai> fremy: I have a similar thought, that just looking at one line doesn't cut it<br> <Rossen_> ack fremy<br> <fantasai> fremy: you will end up with a triangle. If you have only two lines it's fine, if you have three, you'll have a long first line, then a smaller second line, and even smaller third line. Very strange<br> <fantasai> fremy: so in a way I'm struggling, if you have elements with more than two line, oh an implementation can produce good results without balancing lines from where it's stealing the words<br> <fantasai> fremy: I don't think I can see how to make it different from pretty<br> <fantasai> fremy: if you're doing that you're back with pretty<br> <fantasai> astearns: I am convinced that there is a faster linebreaking algorithm that would only do this and not look at the full "pretty" penalty values<br> <fantasai> astearns: it doesn't have to be as expensive as the full pretty implementation to do just this one thing<br> <fantasai> iank_: but you can bias the pretty implementation<br> <emilio> `text-balance: pretty-fast` :-)<br> <Rossen_> ack iank_<br> <fantasai> iank_: One thing on controls, it's not clear how this control would apply to `text-wrap: balance`<br> <fantasai> fantasai: it wouldn't<br> <astearns> but I absolutely agree that we should avoid introducing the line wrap triangle shapes that fremy described<br> <fantasai> myles: `balance` will win. it handles last line by itself<br> <fantasai> iank_: it feels to me that we have at least 3 line-wrapping algorithms, might have others in the future<br> <fantasai> iank_: this control wouldn't affect balance<br> <fantasai> fantasai: it also doesn't affect nowrap<br> <fantasai> iank_: sure<br> <hober> qq+<br> <fantasai> iank_: I somewhat agree with fremy that you might be getting into pretty territory<br> <ntim> q+<br> <fantasai> iank_: I'm not convinced by the global control argument<br> <fantasai> hober: if setting balance means it doesn't apply, then you aren't setitng whatever this is<br> <ntim> +1 to what hober said<br> <fantasai> hober: you're not setting it if you're not setting `text-wrap: balance`<br> <Rossen_> ack hober<br> <Zakim> hober, you wanted to react to iank_<br> <Rossen_> ack nicole<br> <fantasai> nicole: does anyone want orphans? is anyone like "I want to turn off nice ending to my text"<br> <fantasai> astearns: yes, because you will get faster text composition<br> <Rossen_> ack florian<br> <fantasai> florian: I suspect we all agree, but will say explicitly, when that is turned on it is a request for the browser to *attempt* to make the last line not terrible<br> <fantasai> florian: but if can only do this by making some other line terrible, shouldn't do it<br> <fantasai> [agreed]<br> <fantasai> florian: also agreeing with Tess that it's also a text wrap value<br> <fantasai> florian: and can have it as an additional keyword<br> <fantasai> myles: requested resolution isn't any particular grammar<br> <fantasai> ntim: I want to echo what tess said, it feels like text-wrap extension<br> <SebastianZ> q+<br> <Rossen_> ack ntim<br> <Rossen_> ack fantasai<br> <astearns> fantasai: so all of this is why I did not want this in text-wrap<br> <ntim> q+<br> <astearns> fantasai: whether and how you are wrapping should be separate<br> <emilio> fantasai: because it needs to cascade separately<br> <florian> +1<br> <emilio> ... you want to set the controls in a single place in your stylesheet<br> <myles> q+<br> <astearns> and if we want this to be extensible as a text-wrap: pretty control it needs to be separate<br> <emilio> ... this needs to be a separate thing and honestly I think `pretty` should have as well<br> <emilio> ... I think this gets into how we're wrapping and that should only set once<br> <florian> q?<br> <ntim> q-<br> <fantasai> This is why I was against "text-wrap: pretty" as a syntax in the first place<br> <emilio> Rossen_: let's pause for a second. There's a clear proposal for a clear problem<br> <emilio> ... There are also ideas about how to do it performantly...<br> <emilio> ... we have plenty of engineers on the room, and we're getting into how to solve the issue, let's not do that<br> <emilio> ... let's go through the queue if you want to discuss syntax or how to solve it<br> <emilio> fantasai: what's the proposed solution?<br> <emilio> Rossen_: to have a property or a value that solves this problem in a more performant way to pretty<br> <Rossen_> ack SebastianZ<br> <emilio> SebastianZ: iterating on nicole's question<br> <emilio> ... if the algo can be made pretty fast, why can't it be the default?<br> <emilio> ... we also have text-decoration skip-ink<br> <emilio> ... but it was worthwhile having as a standard<br> <florian> [I think think we should open a separate issue to move "balance | stable | pretty" out of text-wrap, and probably add "avoid-orphans" there]<br> <emilio> Rossen_: let's close that bridge when we get to it<br> <Rossen_> ack myles<br> <emilio> PROPOSED: Add a control that is either a property or a value that causes UAs to make the last line longer than it would've originally done unless that was a bad idea<br> <emilio> RESOLVED: Add a control that is either a property or a value that causes UAs to make the last line longer than it would've originally done unless that was a bad idea<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3473#issuecomment-1646267487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 21:44:30 UTC