tc39 / proposal-intl-segmenter-v2

Version 2 of Intl Segmenter. Adding line break support.
https://tc39.github.io/proposal-intl-segmenter-v2/
MIT License
12 stars 4 forks source link

Should this API live in Houdini instead? #7

Open FrankYFTang opened 2 years ago

FrankYFTang commented 2 years ago

In TC39 2021-12-15 meeting, one issue raise of should line break facility live in Hudini instead since for proper paragraph line layout it require resolving Bidi and may need font metrics for character spacing etc.

FrankYFTang commented 2 years ago

The likely communication channel w/ Hudini is in https://github.com/w3c/css-houdini-drafts

yjbanov commented 2 years ago

Awareness of Houdini is important as a source to learn from, as well as to ensure overall fit of the proposal in the web ecosystem. However, there are a few aspects about this proposal that make it more appropriate for TC39 than Houdini (and, in fact, inappropriate for Houdini):

  1. The proposal operates purely on strings and is agnostic of the rendering technology. It can serve any rendering technology, be it HTML/CSS, 2D canvas, WebGL/WebGPU, or non-browser use-cases (Electron, JS-scripted game engines, Node.js, etc).
  2. There are use-cases when line breaking is done without rendering. For example, Flutter calculates line breaks for text samples to predict the extents of scrollable areas (called "prototype items"), which is purely a computational task that does not result in pixels (pixels do show up later, but this particular computation does not imply pixels). Houdini is all about laying out and painting text.
  3. Houdini is explicitly a CSS feature (the official name of the relevant component is literally "CSS Layout"). It is not in its scope to serve non-CSS rendering stacks. The input to Houdini is HTML DOM, which comes with certain data and layout model, and requires the availability of an HTML/CSS engine. Houdini also dictates a specific computational model, where layout "worklets" are isolated from the main JavaScript program into a separate memory heap and asynchronous boundary (a reasonable choice for HTML/CSS, which gives browsers the flexibility to schedule layout/paint computations on different threads). The output of a layout worklet is, by design, not consumable by the program supplying the input (the DOM), but by the painting/compositing systems. It's quite strange to require an HTML/CSS engine just to line break a string.
FrankYFTang commented 2 years ago

@rkirsling any opinion about adding line break into Intl.Segmenter vs create a more complete / complex api set in Houdini from JSC community?

rkirsling commented 2 years ago

@FrankYFTang I'm not personally involved in W3C, but I feel in agreement with the sentiments that Myles and Yusuke expressed.

FrankYFTang commented 2 years ago

@zbraniecki @gibson042

Constellation commented 2 years ago

ref #8 as a related note.