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

litherum has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [text-layout] Houdini and text layout ==
This issue is a bit premature, but I'd like to get the gears turning here early to avoid conflict later on.

As I understand it, one of the goals of the Houdini effort is to be able to re-implement existing styling facilities that are present in the browser. There are specs for animations, layout, painting, and parsing, all of which are things that browsers already do. I've heard rumblings that eventually this will extend to being able to implement inline-level features (using CSS parlance) in addition to block-level features.

Text layout is a little bit of a different beast, though, and should be approached with caution. In particular, it's very easy to get it wrong, and when it's wrong, content can be unreadable, or worse: misleading. In order to do text layout correctly, fonts have to cascade properly, font-specific shaping needs to be applied correctly, grapheme clusters have to be segmented properly, the bidi algorithm needs to be executed correctly, caret positions need to be calculated correctly, physical arrow keys need to be translated to the correct logical direction, variation selectors need to be applied correctly, tracking, kerning, and hyphenation need to be applied in a script-specific manner, line breaking needs to be correctly calculated given an appropriate amount of context, selection bounds need to be calculated correctly and at the correct time, and double-click needs to identify words correctly. And it all has to be done with the performance requirements of the "hot path." Some of these requirements require hundreds of kilobytes, or even megabytes, of data tables to do correctly. (And that's just some of the constraints.)

A possible Houdini text layout API should need to be designed such that it's easier for a web author to satisfy the many text layout requirements than it would be for them to break them. A web page placing specific glyphs from specific fonts at specific places probably wouldn't be robust enough for properly internationalized text on the Web.

There are many possible ways such an API could go, but my recommendation to start with would be a model that matches the CSS Regions model. A region would describe some (possibly complex) 2D geometry, and a region could be chained to a successive region, and text would automatically flow from one region to the next. Inside a region, the text-specific layout (like letter-spacing, line breaking, etc.) would be handled with existing CSS properties. Such a design gives authors considerable power over how their text flows around the screen, but also gives them the necessary support they need so content works great in all locales.

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/854 using your GitHub account

Received on Wednesday, 30 January 2019 19:41:30 UTC