Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Please don't do this.

Native controls have dozens to hundreds of subtle UI interactions. Consider a text input element. On macos there are text shortcuts - cmd+A to select all. cmd+left / right to go to the next or previous word. Page up / page down. Home / end. Spell check. A right click menu with about 10 more options, including OS based text services. Tapping on a text input element on ios or android will pull up the native on-screen keyboard, configured in system settings. Every major OS version, the UI changes in small and subtle ways.

You simply can't reimplement this functionality in the web browser. Browser APIs don't let you intercept a lot of the keyboard shortcuts you need. You don't have access to macos text services, or the native iOS keyboard UI.

Some people try to reimplement this stuff in the browser, but it always feels horrible to use. Nearly native, but laggy. Nothing looks quite right. You can't select text on the page properly. Fonts render slightly wrong. I have muscle memory for keyboard shortcuts that don't work. I hate it.

Please read TFA

> for most web apps, you’re much better off with good old DOM elements. Take the humble <input type="text"> element, for example. With it, you get crispy rendering at any resolution, support for tab, focus, selection, mouse interactions and arrow key navigation, internationalization for right-to-left text and Asian compound characters, accessibility for screen readers…

I did read the article. It is not a balanced piece. The title is “You might want to build your webapp in canvas instead”. Almost the entire article - basically everything except for that paragraph - is talking about canvas rendering. About when and why it might be better. There is nowhere near enough discussion of the downsides. If you read this article you could walk away thinking Google docs is implemented entirely on top of the canvas API. This couldn’t be further from the truth.

There are a lot of comments in this thread excited by the idea of turning my web browser into a dumb frame buffer for someone’s home grown, laggy, half baked UI framework that cannot function on par with the DOM for hard technical reasons. I don't want to run software like that.

The author is not obligated to lay down every single pro and con for something, it's just a blog post with some examples and if the reader wants, they can research more into the topic themselves.

I just don’t want to log in to my banking portal in 3 months to find the whole thing has been rewritten on top of canvas for no reason.

Just because people use a technology incorrectly does not make the technology bad, especially when people like the author explicitly state where it does and does not make sense.

Late to the thread, but I agree with everything in this comment. The best way to build a website (especially any sort of transaction and/or form) is with the standard tools: HTML, CSS, the smallest amount of JS necessary.

I've been working for a number of years to make the HTML canvas element more accessible for those situations where using a canvas element makes better sense (allegedly) than using standard tools - because there's always those special edge cases, and if people are going to use canvas elements then I want them to build them in the most accessible and responsive way possible.

I'll not spam my product, but as part of my work I have produced a webpage where I try to list the things a HTML canvas element needs to do to meet WCAG requirements. These are my own, personal views so challenging my claims is entirely justifiable, and correct!

https://scrawl-v8.rikweb.org.uk/docs/reference/sc-accessibil...

Read the post. The author talks explicitly about when canvas is useful (unsurprisingly, for canvas shaped apps) versus when to use native DOM elements.

Reply on news.ycombinator.com