Re: [css-houdini-drafts] [text-layout] Houdini and text layout (#854)

Myles, it might help if you were to break down what you mean when you talk about "text layout". 

I'd say that text layout isn't just one nasty beast, it's a whole ecosystem of critters that rely on and affect each other.  But, we wouldn't need to give access to all of them at the same time.

Working from your comments, I can think of a few distinct steps in the process (some of which could be broken down further):

- turning a string of characters + a set of font styles into a series of glyphs and their offsets
- identifying inline breaking opportunities (line wrap and hyphenation) and the glyph/offset changes they would require
- identifying justification/spacing opportunities of different types (letter, word, kashida, ???)
- possibly identifying fragmentation break opportunities in the block direction
- using all this information to break the sequence into inline boxes and position those boxes in the available space

I think it's also important to remember that there are two types of Houdini APIs:

- Information APIs that give the author access to information that the browser is already calculating

- Worklet APIs that allow the author to substitute code for a step in the browser's process

It's probably best to focus first on creating the information APIs, to develop the a standardized objects to describe the different parts involved.  For font-based text-shaping, we don't have an existing CSS OM to discuss the different moving parts. (SVG has APIs that give glyph offsets among other dimensions—but as someone who has tried to work with them, I assure you, they are incomplete.)  For inline text layout, we have the concept of inline boxes and their dimensions/positions, but not more.

The [Font Metrics](https://drafts.css-houdini.org/font-metrics-api/) and [Box Tree](https://drafts.css-houdini.org/box-tree-api/) APIs are definitely part of expanding that information model.  But they don't even touch some of the steps I mentioned above, such as breaking opportunities.

Now, imagine if we had an information API that allowed the author to ask the browser for all word break and hyphenation opportunities in a given text span, the length of the fragments in between the breaks, and the amount of length that would be added (e.g., for an inserted hyphen) or dropped (e.g., for a trimmed space) if the text was wrapped at that point.

With that information available, it would be a lot more reasonable to give authors the chance to write their own line-breaking algorithm (e.g., to implement "balanced" text-wrapping for a heading).

Justification within a given line would be similar: we first need a model of the information the browser knows about the text structure and its spacing opportunities, then we can consider letting authors set the rules for what to do with that information.

For lower-level steps in the process, adding custom code is trickier. I'm not sure whether we'd ever want to let authors override the Unicode bidi algorithm. But information APIs could definitely still be useful, e.g., to detect the directionality of user-input text in a web app.

At the text-shaping level, I sure wouldn't mind the ability to code up decorative glyph substitution and re-positioning effects without having to code them into the font itself.  Something like a custom OpenType stylistic set—maybe with the power to reposition or substitute glyphs from multiple fonts!  Or generate SVG glyphs dynamically!  But first we'd need an object model to define the glyph selection, substitution, and positioning code in the font—which may be difficult to implement when that text shaping code often exists outside the browser.

> my recommendation to start with would be a model that matches the CSS Regions model.

The ability to define a Regions-style fragmentation chain of boxes definitely sounds like a feature I'd love to see in the next level of the [Layout API](https://drafts.css-houdini.org/css-layout-api/). But I'm not sure it should prevent work on something like a line-breaking API, let alone the information APIs.

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/854#issuecomment-459146355 using your GitHub account

Received on Wednesday, 30 January 2019 23:05:42 UTC