On Fri, Jun 23, 2023 at 12:59 PM fantasai <fantasai.li...@inkedblade.net> wrote:
> >> Avoiding a short single word on the last line (typographic orphans) is > one > of the most visible advantages of the paragraph-level algorithm. > > What does it mean to “avoid a short single word” in quantitative terms > (and > across languages)? > What does "in quantitative terms" mean? Are you asking the exact logic, not from common cases? If so, the logic at this point is when the last line is equal to or less than 1/3 of the available width, and has no break opportunities. Please refer to the "Performance Considerations <https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yTsvg8IuAq7oFrNQxPeqI/edit?pli=1#bookmark=id.3de3lx39sjmr>" for more details. If not, appreciate it if you can explain your question better. > >> Following are the limitations as of ToT/WIP. The list may change in > future. > > Can you confirm that this table means that the “pretty” algorithm is > disabled, > rather than the feature listed being disabled in favor of “pretty”? :) > Yes, updated the description. Thank you for pointing out this possible misleading text. > [snip] So I agree largely agree with Alan Stearns's comments, and in the context > of > those comments, I want to ask, if the primary goal is to avoid short last > lines, is “text-wrap: pretty” the right approach, or should we be > considering > a proposal that allows more configuration? > As in Alan's comment and in the "Overview <https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yTsvg8IuAq7oFrNQxPeqI/edit?usp=sharing>" of the design doc, the initial implementation includes avoiding typographic orphans, but the primary goal is to add more to improve typography incrementally. It's not easy to ship every possible idea at once, primarily due to the performance concern. The algorithms included in this Intent to Ship is about ~10% addition to the layout performance, while doing all I prototyped costs ~200%, and we're not sure "3 times slower" is acceptable for web developers at this point. We'd like to start small, then we're looking forward to developer feedback on which typographic improvements are more important for them and how much performance cost is acceptable. For example, there have been in the past a proposals for a property like > last-line-length: <length-percentage> > which is discussed in the issue you linked to: > https://github.com/w3c/csswg-drafts/issues/3473 Yes, I agree this is a possible good idea too. I'm looking for if a) authors want to enable only this without other typographic improvements, b) authors want this even when we have higher-level control (`pretty`) enabled across browsers, and c) authors want to distinguish e.g., 33% vs 50%, but I need more research to get answers. I agree with Alan that starting from higher-level control looks like the right first step. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKzeSiEm4eNmw1cpJh61Buvy2TTrgsrRvEE66yhwYp12w%40mail.gmail.com.
