New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-text-4] Allow for paragraph-level line breaking #672

Open
litherum opened this Issue Nov 2, 2016 · 37 comments

Comments

Projects
None yet
@litherum
Contributor

litherum commented Nov 2, 2016

There are a few algorithms which attempt to choose line breaks within a paragraph in order to maximize the beauty of the paragraph as a whole. Such algorithms try to do some subset of:

  • Minimize hyphenation
  • Minimize extra space at the end of each line (or between words for justified text)
  • Minimize rivers
  • Minimize widows/orphans
  • Minimize two hyphenated lines in a row
  • Minimize visual differences between adjacent lines
  • Minimize single-syllable or single-word last lines
  • For paginated media, minimize single lines at the beginning or end of pages
  • More?

Obviously, it is impossible to satisfy all these desires simultaneously for arbitrary paragraphs. The exact algorithm should not be specced for these reasons:

  • Browsers should be allowed to innovate with heuristics of deciding how hard to try to solve one item at the expense of the other items
  • Browsers should be allowed to teach and improve their implementations about new typographical conventions as time goes by
  • Criteria for beautiful paragraphs are locale- and language-specific
  • Different user agents may wish to provide different thresholds of participation (e.g. only consider a sliding window of n lines, or bail after x milliseconds of compute time, etc.)

Instead, there should be a way for a web author to opt-in to paragraph-level layout for beautiful paragraphs.

I'm not sure what the best mechanism for this is. Perhaps a new value to the text-wrap property? Perhaps a new property? Perhaps something else?

@litherum litherum added the css-text-4 label Nov 2, 2016

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 2, 2016

Do you think there is anything in the specification currently preventing browsers from implementing paragraph-level layout already? I know they don't, but if they could, maybe we don't need an opt in at all, and any browser willing to go through the necessary implementation complexity can just turn it on by default.

@kojiishi

This comment has been minimized.

Contributor

kojiishi commented Nov 2, 2016

I think he meant it to be an opt-in, since turning this on will hit the performance quite severely. Adobe InDesign has a concept of pluggable composer, and provide 4 different composers; combinations of English/Japanese and line/paragraph levels. AFAIU, the composer in InDesign provides line breaker and justification algorithm.

I like the idea, and I hope @astearns as well. I prefer a separate property, something like text-rendering, but I'm open to other ideas too.

@eaenet

This comment has been minimized.

eaenet commented Nov 2, 2016

This is exciting and something I'd be very supportive of. Given the performance concerns though it'll likely have to be opt-in as suggested by both @litherum and @kojiishi.
It might also be possible to implement support of this on top of custom layout to allow for custom pluggable composers.

@litherum

This comment has been minimized.

Contributor

litherum commented Nov 2, 2016

Do you think there is anything in the specification currently preventing browsers from implementing paragraph-level layout already?

@kojiishi is correct. It would be incorrect to do this automatically for both performance and correctness. Opting everything in automatically would be a performance regression, and the web would be upset if we just start changing every line break on every page to be dramatically different.

@astearns

This comment has been minimized.

Member

astearns commented Nov 2, 2016

Line breaks aren't controlled directly by CSS anyway - line breaks change browser to browser and platform to platform and that's OK. So I think it would be fine for browsers to incrementally improve their line breaking without an opt-in.

But I agree that the performance characteristics of full-paragraph composers are likely to require an opt-in. InDesign doesn't actually go full-paragraph, it only does a set number of lines at a time. I think browsers should be able to experiment with composers, and even disagree about what works best. So an opt-in would probably need to be pretty generic, perhaps a single-line composer as a default and a multi-line composer as the opt-in.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 3, 2016

Point taken about performance. However I think if we introduce a switch, it should be between auto and on, not between off and on: CSS UAs generally do greedy line breaking as the default, and that's ok, but if an implementer wants to provide a better default (e.g. it is a print UA not concerned with performance, or it has a not-great-but-better-than-greedy algorithm that performs fine...), that should be allowed.

With that in mind:

  • Do we want that switch at all, or should it be left to houdini? I think this should be baked in CSS. Certainly houdini APIs should be capable of supporting this, but doing it right in an i18n context is hard and tedious, and I don't think putting that burden on authors is reasonable.
  • Do we want auto | on or auto | on | off, where off explicitly requires greedy line breaking? I don't think off is needed, but I could be wrong. Authors do not know enough about the performance tradeoff that this implies to make an informed decision (other than by assuming a particular version of a particular browser), and if they need to depend on a certain wrapping behavior, there's white-space: pre
  • Do we want to be able to switch between multiple forms of smart line breaking? If the answer is “yes, but not until a later level”, does that still influence how we design the property?
@litherum

This comment has been minimized.

Contributor

litherum commented Nov 3, 2016

Houdini should not be required to have beautiful paragraphs.

I also don't see a use case for off. Making auto the initial value is a good idea so browsers can improve their line breaking over time.

Eventually, adopting more customizability for smart paragraph breaking is totally reasonable in a later level. However, it's too early to spec something like that in this level. However, the keyword "on" is compatible because, in later levels, we could list additional keywords which would appear after the "on" value.

It sounds like Florian is leaning toward a new property. Therefore, the current proposal is:

paragraph-layout: auto | on
initial value: auto

Obviously we can bike-shed the name too.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 3, 2016

Right, that's kind of what I have in mind. At the same time, you suggestion to use text-wrap is quite reasonable also, as it seems the separate property would not do anything when text-wrap is nowrap or balance. so we could have a new value along the lines of text-wrap: smart or text-wrap: smart-wrap or text-wrap: contextual-wrap text-wrap: paragraph-wrap...

So, to decided if we need more values to the existing property or a new one:

  • Which one gives the better fallback behavior when the new value/property is not supported, or when additional values are later added? Looks the same to me, in both case, you can use the cascade to provide your favorite fallback, and if you don't it falls back onto the default greedy approach
  • Any compat constraint? I don't think so. AFAIK text-wrap is not implemented.
  • Does the decision to wrap or not and the way to wrap look like separate decisions, that you may want to cascade separately? Maybe: you could decide to switch a the whole page to smart wrapping for any element that wraps, and pick between wrap and nowrap at a fine grained level. that would push for separate properties, but not that strongly, since text-wrap is inherited. You can still do :root { text-wrap: smart;} and selectively apply nowrap where it belongs.

All in all, I think I could go either way, but I now lean a bit more towards a value to text-wrap. And given that text-wrap has not been implemented anywhere yet I think, we can bikeshed the property name and existing values if needed to make everything fit better together.

@kojiishi

This comment has been minimized.

Contributor

kojiishi commented Nov 15, 2016

I'd like to take my comments above "prefer a separate property" part back; i.e., I'm fine with a new value to text-wrap.

I see @litherum already expressed that either is fine with him, @frivoal @astearns do you have preference?

I admit I had wrong understanding on how text-wrap is defined currently, but now I understand it already behaves differently for inline and block.

So the block-level text-wrap chose line breaker while inline-level text-wrap turns on/off wrapping looks reasonable to me.

And given @astearns's suggestion above, keyword should be multiline rather than paragraph? Or do we prefer even more generic name, such as smart as suggested by @frivoal?

@kojiishi

This comment has been minimized.

Contributor

kojiishi commented Nov 15, 2016

I missed the last paragraph of @frivoal so he already prefers a new value to text-wrap, so we're all good?

@litherum

This comment has been minimized.

Contributor

litherum commented Nov 28, 2016

I think we're all good.

"Smart" is not a good name because it doesn't have any semantic meaning. I like Koji's "multi-line" idea because it is more accurate than "paragraph" (because I expect most implementations will do this in a sliding window rather than for the entire paragraph)

So the new proposal is:
text-wrap: wrap | nowrap | balance | multi-line
initial: wrap
where "multi-line" is a synonym for "wrap" when applied to inline elements.
Similar to "balance," the exact algorithm is UA-defined.

The conceptual difference between "balance" and "multi-line" is that "balance" is intended for titles where "multi-line" is intended for body text.

@litherum litherum added the Agenda+ label Nov 28, 2016

@astearns

This comment has been minimized.

Member

astearns commented Nov 29, 2016

I don't think we need conf call time on this - I'll just edit the value in

@astearns astearns added Needs Edits and removed Agenda+ labels Nov 29, 2016

@astearns astearns self-assigned this Nov 29, 2016

@fantasai

This comment has been minimized.

Contributor

fantasai commented Nov 29, 2016

Alan, I think this does need a WG resolution to add. It's not a bugfix, and it's not a trivial feature, either.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 29, 2016

The proposal sounds sane to me. I’d like also to make it clear that browsers should be allowed (but not required to) make wrap do the same kind of multi-line processing as multi-line. The alternative being requiring that wrap invokes the greedy line breaking behavior, which I don’t think would be good.

Basically, I think that the two values should have the following meeting:

  • wrap: lines do wrap, algorithm is UA defined, UA may take multiple lines into account, UA may bias for speed over good layout
  • multi-line: lines do wrap, algorithm is UA defined, UA should take multiple lines into account, UA should bias for good layout over speed
@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 29, 2016

And I agree with @fantasai that adding new values is typically something we should ask the WG about, even though this is an early draft. The WG might not yet need to discuss all the details, but it should be in the loop.

@Crissov

This comment has been minimized.

Contributor

Crissov commented Nov 29, 2016

@frivoal To properly support multi-line, implementations must consider multiple lines. If they do not support the value they will fall back to wrap anyway.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 29, 2016

Well, to do anything useful, sure, but since the value implies a UA defined algorithm, they can do whatever they want anyway, and we cannot test the difference. So putting must on a non testable statement isn't doing very much.

If an implementation does not support the value, it will fall back to whatever the cascade says it should fallback to, which may or may not be wrap depending on how the stylesheet is written.

Allowing implementations to support multi-line while not doing anything smart (but recommending that they do something smart) may provide a more robust fallback story: when a browser knows the value, even if it doesn't have any particular smart line-breaking logic, it falls back on something that wraps, rather than on whatever the cascade says.

@astearns

This comment has been minimized.

Member

astearns commented Nov 29, 2016

It will probably be possible to come up with a very basic test - given a width constraint of about ten characters and some content that looks like:

a a a a a
bbb
ccccccccc

a multi-line composer is going to choose to break before the last 'a' in order to avoid the short second line length.

@astearns

This comment has been minimized.

Member

astearns commented Nov 29, 2016

And I disagree that we need to get a resolution on a conference call to add something to a working draft. I see enough consensus in this thread to make the change. Informing those in the group not following this thread that there's something new is worthwhile, but that's best done with the edits in place. Asking anyone to resolve on something that's not yet written down isn't fair.
If there is anyone following this thread who would object to the edit on technical merits, please speak up.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 29, 2016

It will probably be possible to come up with a very basic test [...]

It ought to, but this particular situation might cause a heuristic fluke. I suppose if we mark that test and similar ones as "should", that's alright.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 29, 2016

Informing those in the group not following this thread that there's something new is worthwhile, but that's best done with the edits in place.

Fair enough, I can buy into that.

@liamquin

This comment has been minimized.

liamquin commented Nov 29, 2016

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 30, 2016

One was to say whether you expect text to be editable in the future. The reason for this is that some line-breaking algorithms are not suitable for interactive use. They might be slow, or, worse, adding a word might affect the position of the insertion point, moving it backwards or forawrds by one ore more (horizontal or vertical) lines.

If we want to follow through with this, we either need to define the initial value (wrap) to be that value, or to have 3 values:

  • one that's guaranteed stable and fast (wrap?)
  • one that promises nice layout (multi-line?)
  • an initial value that lets the browser pick where it wants to be on the stability-performance-niceness spectrum (auto?)

My own research in the past has suggested the best compromise in many circumstances is a modified first-fit that operates on an n-line window. This works massively better than Knuth-Plass for unattended operation because it doesn't have the poor edge-case behaviours of Knuth-Plass found e.g. in TeX.

That's for the multi-line case where we're trying to get the nicest result, right? This sounds like an area where we should allow browsers to do whatever innovative thing they want, but we could still define this as a non normative suggestion of how to implement it.

For the fast-and-stable case, should we just leave it up to browsers, or require a particular approach, or or leave it up to browsers and suggest particular approach? If we suggest/require something, should it be greedy line breaking, or some variant of greedy line-breaking that allows for prioritization of soft wrap opportunities, or something else?

I don't have yet a strong opinion on what the best answer is, but I'm leaning toward auto | wrap | multi-line (or wrap [fast | nice]? or wrap [stable | nice]? ):

  • auto (wrap in the alternative naming):
    • the UA may take multiple lines into account
    • the algorithm is UA defined. It can be anywhere on the stability-performance-niceness tradeoff spectrum. The UA may use different algorithms in different contexts (editable or not, based on the language, long vs short lines...)
  • wrap (or wrap fast or wrap stable in the alternative naming)
    • the UA must not take multiple lines into account (for speed and stability reasons)
    • the algorithm is greedy linebreaking with prioritized wrap opportunities: fill the line until it overflows, then backtrack to find a wrap opportunity. A simple implementation may wrap at the last wrap opportunity that fits, but within the limits imposed by hyphenate-size-limits or a similar property generalizing the concept, the UA may choose which of several wrap opportunities it wants to break on.
  • multi-line (or wrap nice in the alternative naming)
    • the UA should take multiple lines into account (should rather than must, because (1) I don't think the difference is enforceable, and (2) there are situations such as single line paragraphs where not taking several lines into account is reasonable)
    • the algorithm is UA defined. It should bias towards nice layout, if necessary at the expense of speed and stability. Liam's favorite suggestion is offered in a note as one reasonable approach to do that.
@liamquin

This comment has been minimized.

liamquin commented Nov 30, 2016

@frivoal

This comment has been minimized.

Contributor

frivoal commented Dec 1, 2016

Hmmm. I'm a bit confused. What you're saying seem to be arguments supporting what I proposed (“leaning toward[...]”) or something close, but I can't really tell if you are indeed supporting it or explaining why you think we need something else.

(1) authors can demand a stable algorithm for an element/subtree so that starting to edit doesn't cause a reflow;

that'd be text-wrap: wrap, for which we'd require greedy line breaking

(2) page authors/designers can express that good line-breaking is important

That'd be text-wrap: multi-line, for which we'd recommend the algo you're suggesting, but also allow UAs to do other stuff (Knuth-Plass or what have you).

As Fantasai said when it was discussed before, authors should not have to opt in to higher quality.

That'd be text-wrap: auto, the initial value, which would the UA could do anything, but we could suggest doing the same as text-wrap: wrap on editable elements and the same as text-wrap: multi-line` elsewhere.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Dec 1, 2016

[...] because of Houdini [...]
&
people can experiment with algorithms (e.g. polyfills, prefixed values) until we learn better what works

What I suggested doesn't really do anything specific about that, but it seems perfectly compatible with doing that via Houdini.

@astearns

This comment has been minimized.

Member

astearns commented Dec 8, 2016

I've added multi-line with a note on intent and another on the need to solve the editing issue. I'm closing this issue, but please add new issues as needed if there's anything I've missed from this thread or any problems with what I added.

@astearns astearns closed this Dec 8, 2016

@astearns astearns removed the Needs Edits label Dec 8, 2016

@frivoal

This comment has been minimized.

Contributor

frivoal commented Dec 12, 2016

@astearns I have two issues with your edit. It seems to ignore the part of the discussion after Liam chimed in.

  • You did not include an informative note giving Liam's concrete suggestion of a better algorithm for multi-line. I think this would increase the likelyhood of implementation by giving a starting point to implementers who're willing to give it a shot without being experts on the topic, so it’s worth including.

  • The discussion above suggested that explicitly opting into stable layout was desirable. I proposed doing that by switching the initial value to auto, and requiring a stable algo for wrap. The way you specified it does not include that (and would prevent us from doing it later, since you have the same value with different semantics), so I suppose you disagree. I know you have a note, but if anyone implements the spec as it is now, that only leaves the possibility of a new property open, not the one of a different set of values.

Unfortunately, you haven't replied to the comments proposing these, so it is difficult to know from what angle to argue.

I can open new issues and repeat the argument there if you want, but at the same time, the context is here, so it seems easier to discuss here.

@astearns

This comment has been minimized.

Member

astearns commented Dec 12, 2016

I agree with Liam that "future-editability should probably not be conflated with wrapping," and more strongly that editability concerns should not constrain wrapping choices. In some cases you want to edit with stable upstream line breaks, and in other cases you want to edit with the best line breaks over all the content. So a separate property expressing editing preferences is warranted. It should be possible to satisfy both text-wrap:multiline and an edit preference set to stable by starting an n-line window with the line just above the cursor.

I didn't consider adding a note with algorithm suggestions. I expect that Liam's n-line optimization is the right suggestion, but maybe someone can come up with something better. Perhaps a separate issue would help?

@frivoal

This comment has been minimized.

Contributor

frivoal commented Dec 14, 2016

In some cases you want to edit with stable upstream line breaks, and in other cases you want to edit with the best line breaks over all the content.

I agree.

So a separate property expressing editing preferences is warranted.

I don't see how this follows from that. A separate value would do as well.

I didn't consider adding a note with algorithm suggestions. I expect that Liam's n-line optimization is the right suggestion, but maybe someone can come up with something better. Perhaps a separate issue would help?

#803

@fantasai

This comment has been minimized.

Contributor

fantasai commented Apr 9, 2018

Reopening for discussion. I stand by the position that new values here should get WG discussion and consensus. Consensus in an issue is enough only if the only people who care are paying attention in the issue, and I don't believe that's the case here and it usually isn't for adding new features.

@fantasai fantasai reopened this Apr 9, 2018

@fantasai fantasai added the Agenda+ F2F label Apr 9, 2018

@clagnut

This comment has been minimized.

clagnut commented Apr 10, 2018

I'm trying to get my head around where/when/if text-wrap interacts with text-align and text-justify, and hyphenation for that matter. Let's say a browser is capable of implementing something like Knuth–Plass multi-line justification, my understanding of the proposal is that I'd need to do this:

p {
   text-align: justify;
   text-wrap: multi-line;
}

Because line breaking and multi-line justification methods are inherently linked, I turn on justification with text-align but request the method using text-wrap.

That said text-justify is also available to say whether the justification method separates words only or can also separate characters. The text-justify spec as written also goes on to say:

The guidelines in this level of CSS do not describe a complete justification algorithm. They are merely a minimum set of requirements that a complete algorithm should meet. Limiting the set of requirements gives UAs some latitude in choosing a justification algorithm that meets their needs and desired balance of quality, speed, and complexity.

...which to my mind implies that text-justify could be expected to specify the justification (and hence) line breaking algorithm in the future.

I think what I'm trying to ask is: should text-wrap affect the way text is justified? If so, this implies that text-wrap determines the justification algorithm (perhaps in conflict with text-justify).

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Apr 11, 2018

The Working Group just discussed Allow for paragraph-level line breaking.

The full IRC log of that discussion <dael> Topic: Allow for paragraph-level line breaking
<dael> github: https://github.com//issues/672#issuecomment-379723234
<dael> fantasai: astearns added a new feature and there was limited discussion. I feel we should have more check in with the group.
<dael> astearns: Issue is pretty long.
<astearns> https://drafts.csswg.org/css-text-4/#text-wrap
<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.
<dael> fantasai: We've talked about fancy wrapping algorithms before.
<dael> eae: It's not that we don't want to impl, it's not a priority.
<dael> astearns: I added it to the spec as a this would be nice to have.
<dael> fantasai: Alternative is you do it anyways and you don't need an opt in.
<dael> eae: Opt in is nice since it's quite a bit mroe costly.
<dael> myles: You can't have this on by default.
<dael> myles: THis will be way slower.
<dael> fantasai: If concern is about perf we might want a note to say if someone impl and discovers no perf issues.
<dael> florian: If you want to do it and have made it fast you can apply to both.
<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.
<dael> RIck: UA could descide this is giant and we won't do it anyway?
<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.
<dael> fantasai: Sounds like what you want is text-wrap:expensive
<dael> fantasai: If that's what it's conveying let's convey that. There are lots of other thigns to consider.
<dael> myles: But balance is also expensive. Different algo for different reasons.
<dael> fantasai: Wrapa nd multiline are trying for the same effect.
<dael> florian: You're not asking for slow. You're asking for pretty even if it's slow.
<dbaron> high-quality-wrap?
<dael> myles: It isn't one spectrum, there are different algo with different purpose
<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.
<dael> myles: WE could make it more complicated but there's 0 impl so simple would be good.
<dael> astearns: Concerns with leaving this prospective value in?
<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.
<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.
<dael> fantasai: I think multiline isn't clear.
<dael> myles: Let's call it pretty
<dael> fantasai: Sure.
<dael> florian: We started with paragraph and we shifted to multiline because it doesn't always consider the whole paragrpah.
<dael> myles: maybe not pretty because titles don't want this.
<dael> astearns: I'm happy to bikeshed on name. multiline is pretty well known by the breed of people that use indesign.
<dael> florian: There was a thing for a switch...for editing purposes you don't want the algo.
<dael> astearns: Separate issue for that.
<dael> fantasai: In taht case you want stable and something else.
<dael> astearns: And there's a note at the end of the section on that problem.
<dael> myles: If we were to impl we prob would make multiline same as wrap.
<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.
<dael> fantasai: I like it as a modifier.
<dael> dbaron: Agree wrap should be in the same.
<dael> myles: Should balance also have wrap?
<dael> Rick: multi-line line breaks would be just fine
<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.
<dael> astearns: We're at time. I've got some of this discussed. Do you want a resolution fantasai ?
<dael> fantasai: I think we agree it's a modifier on wrap not a sep keyword.
<dael> astearns: I believe there is a sep issue on editing and multi line
<dael> astearns: Resolution that we shoudl change value to wrap-nice, wrap-better...something?
<dael> astearns: Issue is open we can bikeshed there.
<dael> fantasai: We can make it a modified on wrap.
<dael> koji: If multiline is modifier balance should be one too.
<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.
@liamquin

This comment has been minimized.

liamquin commented Apr 12, 2018

@robertknight

This comment has been minimized.

robertknight commented Apr 30, 2018

I'm currently experimenting with doing paragraph-level line-breaking in userland in the tex-linebreak package. There is a bookmarklet that you can use to try it out on existing content.

I'm using the Knuth-Plass algorithm with only some small modifications. The main issues and sources of overhead I've encountered with a user-space solution are:

  • The difficulty of taking into account floats when determining line widths, especially since a float outside a paragraph can affect the line widths of content within the paragraph.
  • The overhead of measuring text, depending on the browser. I'm using Canvas APIs. Chrome appears to be much faster than Firefox here (~40ms vs ~400ms for every <p> in the Wikipedia article on London ). In either case, the library is repeating a lot of work that the browser has already done.
  • DOM manipulation overhead for inserting the necessary elements to alter inter-word spacing and add linebreaks in stable Chrome. The overhead has disappeared entirely in Chrome Canary, so more research needed here.
  • Insertion of DOM elements to alter the appearance of rendered text can change which selectors match. This mostly affects sites with poorly written CSS.

What I'm planning to do next is to take a look at the CSS Layout API to understand whether it is possible to use that to reduce the duplication of work.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Aug 9, 2018

@liamquin Thanks very much for your detailed comment on line-breaking algorithms in #672 (comment) !
Do you have any good references we can link to from the spec, or should I try to summarize your points in a note?

@liamquin

This comment has been minimized.

liamquin commented Aug 9, 2018

fantasai added a commit that referenced this issue Sep 16, 2018

[css-text-4] Drop keyword and mark an open issue, since there's no co…
…nsensus on what syntax is or isn't necessary for good text-wrapping algorithms. #672
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment