Hacker News Reader

Comment by panic | Hacker News Reader

In order to have native-quality text editing on the web, you need to use the DOM. Using the DOM limits what kind of UI you can have.

View on HN

Right - so why can't we have this for the DOM? Much of the power of QML could work wonders for that, for example setting anchor points based on other elements. I think the problem is that in many cases it needs either weird css hacks or injecting dynamic values via js.

It'd be nice to have a web layout tool that ties it all together and lets the designer use familiar tools like pivot, anchor, align, etc. - even if it exports some proprietary combo like react + styled components.

No doubt that's what FramerX and friends are after... so I guess there's progress, but it feels like the web just needs an overall rewrite to get out of the legacy cruft that came along with making static pages dynamic.

I don't see how that makes any sense at all. What is the actual limiting factor?

That's actually the limiting factor, otherwise you could just compile Qt to WASM and draw to a canvas.

To render text nicely you need to know the geometry of the screen so you can anti-alias properly. A canvas goes through a series of transforms that work fine for images but garble text.

The look of the text is just the tip of the iceberg. Many text editing operations are tightly integrated with the operating system and impossible to implement without an editable element. For example, on recent iPads you can move the cursor around by swiping the keyboard with two fingers. I don't know how you'd support this gesture without creating an actual editable element on the page.

Qt can be compiled to WASM and the resulting demos were looking good to me. Where did you experience problems with canvases?

Reply on news.ycombinator.com