When I first wrote that comment, I wrote something like “you could do it, but the end result would be absolutely terrible”. Then I decided that actually it wasn’t possible after all in any meaningful way, and changed it to “except probably even less plausible.”

In reality, with what I have in mind, it’s kind of a bit of both: what I have in mind is that you’d need to split each piece of the Knuth-Plass layout (box, &c.) into a DOM element of its own first, so that the layout can determine their sizes and shuffle things around appropriately—since the layout API is only giving you the set of CSS boxes to lay out and their sizes and any engine-decided inline breaks in them, and not the ability to inspect what’s in them or to break them up into further fragments.

Once you’re doing that, it’s probably a bad idea to use the Layout API, because you get no substantial benefit (a ResizeObserver to notify you when you need to redo the layout is just about as good), but are using a lot more DOM nodes (which is bad for performance, and I strongly suspect it’d cancel out the benefit that the Layout API version can run away from the main thread), and are using a new, less-well-supported and probably-buggier API to boot.

Also browsers have some pretty terrible bugs around how hyphenation especially works when you have zero-width characters, and they have shown no interest in fixing them. (Chromium’s are the worst, but Firefox has a couple of interesting ones as well.) Therefore you’d probably need all of your line-breaking opportunities (most notably, soft hyphens) to be in boxes of their own. And now you probably won’t get your ff ligature if a hyphen could be inserted between them, so I’m probably going to have to disqualify it as not being able to produce the same output.

In the end, I’d be surprised if a variant of https://github.com/bramstein/typeset using the Layout API as far as possible while retaining identical output (excepting this soft-hyphens-inside-ligatures case, if my guess is correct) could get down to even 20× slower than it, or using less than about 10× as much memory. In practice, I think figures like 100× slower and 500× memory are more likely. It’s possible that it would be less janky for large amounts of text, given that it operates in a worklet which may be run off the main thread by the browser; but I doubt it, due to the increase in other requirements.

This is all assuming that my understanding of what would be needed and possible is correct—I may have stated it too strongly given my lack of particularly detailed knowledge in the area.

The ultimate problem I see with breaking words into separate boxes is that they can't be rendered "in flow" anymore. So I guess the actual Text has to be set outside the layout API.

However, consider the case of the CSS Flexbox. It can also wrap boxes, and there some smarter way of looking ahead could be helpful and would be within the scope of the layout API. Not sure.

And indeed, for rendering PDFs it may not be necessary or beneficial to rely on the Houdini APIs at all.