3 ms·
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.
by panic 8y ago
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.
- CyberDildonics 8y agoI don't see how that makes any sense at all. What is the actual limiting factor?
- slededit 8y agoThat'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.
- gmueckl 8y agoQt can be compiled to WASM and the resulting demos were looking good to me. Where did you experience problems with canvases?
- panic 8y agoThe 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.
- dakom 8y agoRight - 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.