There is a lot valid concern on accessibility and abuse this could result in, but it think it's important to see the other side of the argument.

There was a really good thread on Twitter a couple of days ago:

> In light of recent Figma news, lemme reiterate that of all the goods that can happen to the web, 90% of them can't happen due to not having access to font rendering & metrics in JS

https://x.com/_chenglou/status/1951481453046538493

And a few choice replies:

> t’s kind of crazy that a platform specifically designed for presenting text doesn’t provide functionality to manipulate text at a detail level

> Brute forcing text measurement in tldraw breaks my heart

Love it or hate it, the web is a platform for application development, making this easer is only good for everyone.

My argument on web APIs is what we should continue to go lower level, and so font and text metrics APIs for canvas would be awesome and an alternative to this. But I'm also a proponent of "using the platform" and for text layout, web engines are incredible, and very performant. Extending that capability to layout inside a canvas enables many awesome features.

One that I've repeatedly gone back to over the years is paginated rich text editing. It's simply impossible to do with contenteditable in a product level way - one of the reasons Google docs has a custom layout engine. This proposal would enable full use of contenteditable for rich text, but with full page/print layout control.

I hope it lands in the browsers.

▲

chrismorgan 7 days ago | parent | next [-]

> of all the goods that can happen to the web, 90% of them can't happen due to not having access to font rendering & metrics in JS

I’d be interested to see a representative excerpt of this person’s “goods that can happen to the web”, because it sounds pretty ridiculous to me. Not much needs that stuff, and a lot of that stuff is exposed in JS these days, and a lot of the rest you can work around it without it being ruinous to performance.

It’s also pretty irrelevant here (that is, about HTML-in-Canvas): allowing drawing HTML to canvas doesn’t shift the needle in these areas at all.

	▲	heresie-dabord 7 days ago \| parent [-]
		> excerpt of this person’s “goods that can happen to the web" 100% of my concern about the Web is about privacy and security... and why they don't happen.

▲

MartinMond 7 days ago | parent | prev | next [-]

> One that I've repeatedly gone back to over the years is paginated rich text editing. It's simply impossible to do with contenteditable in a product level way - one of the reasons Google docs has a custom layout engine.

As do we at Nutrient, we use Harfbuzz in WASM plus our own layouting - see the demo here: https://document-authoring-demo.nutrient.io/

Getting APIs for that into the Platform would make life significantly easier, but thanks to WASM it’s not a total showstopper.

Btw, I saw you’re working on sync at ElectricSQL - say hi to Oleksii :)

▲

Waraqa 7 days ago | parent | next [-]

I just tested this demo and it noticed it doesn't support Arabic text rendering (the letters should be connected) which is a main feature of Harfbuzz

▲

skrebbel 7 days ago | parent | prev | next [-]

Woa that's some heavy SVG lifting going on there!

If I get it right, every glyph used from the given font is rendered once as a SVG path (upside down! huh!), and then the whole page is a single huge SVG element in which every typed character is a <use> with a reference to that rendered glyph, translated with a CSS transform to the right place (i assume these coordinates come out of HarfBuzz?). Kinda mad that you had to redo 90% of the browser that way but the result is pretty impressive!

I'm curious why you render the glyphs to paths and not have the browser render those directly using eg svg <text> elements?

Was it hard to get this to work cross browser?

ps. srsly I love this about the web. You're doing this amazing engineering feat and I can just pop the trunk and learn all about it. Obviously feel free to not answer anything that's deemed a trade secret, I'm just geeking out hard on this thing :-) :-)

▲

rjsw 7 days ago | parent [-]

You can't size other SVG elements around text ones since you don't know how much space the text element will occupy.

▲

skrebbel 7 days ago | parent [-]

I don't mean HTML text nodes, I mean still the single big SVG like they do now, but with SVG <text> elements instead of <path> elements. They do know (I suppose) how much space that element would take since they're asking HarfBuzz to tell them.

▲

rjsw 7 days ago | parent [-]

You can't know the size of an SVG <text> element.

▲

skrebbel 6 days ago | parent [-]

why not? if you control the font and the font size then can't you have harfbuzz tell you how wide each glyph is going to be, and it'll fit precisely? (assuming the browser also uses harfbuzz for this, which it does)

	▲	rjsw 6 days ago \| parent [-]
		Because SVG isn't defined to call into harfbuzz. You don't control the font if the SVG fragment is embedded in HTML.

▲

qingcharles 7 days ago | parent | prev [-]

And, I think we've come full circle. I'm pretty sure that's how I was rendering text for the online office suite[] I wrote in ~1998 -- a Java Applet embedded in the browser.

[] VCs: "We're not investing in this crap! No company in their right mind would store their precious, confidential documents on the Internet!"

▲

6 days ago | parent | prev | next [-]

[deleted]

▲

6 days ago | parent | prev | next [-]

[deleted]

▲

troupo 7 days ago | parent | prev [-]

> I hope it lands in the browsers.

Why would you want world's least performant layout/UI engine infect canvas? This literally just cements the situation you quote about having no access to good APIs.

A reminder that Figma had to "create a browser inside a browser" to work around DOM limitations: https://www.figma.com/blog/building-a-professional-design-to...

> It's simply impossible to do with contenteditable in a product level way - one of the reasons Google docs has a custom layout engine. This proposal would enable full use of contenteditable for rich text, but with full page/print layout control.

Why would it enable contenteditable for rich text if you yourself are saying that it doesn't work, and Google had to implement its own engine?