Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From SVG to Canvas – A new way of building interactions

felt.com

Post reply on HN
Print view View original

71–80 of 97 posts

Re: From SVG to Canvas – A new way of building interactions

#71

Post by mydriasis »

ygra wrote: post #59
tadfisher wrote: post #28

Earlier quoted context omitted.

Genuinely asking, how do you make something like their map view accessible with so many objects and layers? I'd imagine you end up with a solution that exposes various content rectangles and ignores everything else, kind of how Google Maps does it.

Not all of accessibility is for those who cannot see (well). WCAG also has a bunch of guidelines for loss of dexterity and other ailments: • keyboard support (being able to navigate to all controls as needed, not being stuck in a navigation island from which there is no escape with the keyboard, etc.) • pointing device considerations (not requiring drag unless absolutely essential, no action on mouse-down, etc.) • no…

No action on mouse down? So we need to develop applications that you can't click? Is that really part of accessibility requirements these days?

Re: From SVG to Canvas – A new way of building interactions

#72

Post by dingledork69 »

ygra wrote: post #59
tadfisher wrote: post #28

Earlier quoted context omitted.

Genuinely asking, how do you make something like their map view accessible with so many objects and layers? I'd imagine you end up with a solution that exposes various content rectangles and ignores everything else, kind of how Google Maps does it.

Not all of accessibility is for those who cannot see (well). WCAG also has a bunch of guidelines for loss of dexterity and other ailments: • keyboard support (being able to navigate to all controls as needed, not being stuck in a navigation island from which there is no escape with the keyboard, etc.) • pointing device considerations (not requiring drag unless absolutely essential, no action on mouse-down, etc.) • no…

Oh is that why modern American software is almost unusable? Give me back my modifier keys and compact UIs

Re: From SVG to Canvas – A new way of building interactions

#73

Post by dingledork69 »

hollow-moe wrote: post #62

Ah yes, people blocking canvas fingerprinting will also love your blank pages, but as they're a minority of users it's not a concern

If you choose to disable features in your browser then they won't work. Is this surprising to you?

Re: From SVG to Canvas – A new way of building interactions

#74

Post by tylerag »

mydriasis wrote: post #71
ygra wrote: post #59

Earlier quoted context omitted.

Not all of accessibility is for those who cannot see (well). WCAG also has a bunch of guidelines for loss of dexterity and other ailments: • keyboard support (being able to navigate to all controls as needed, not being stuck in a navigation island from which there is no escape with the keyboard, etc.) • pointing device considerations (not requiring drag unless absolutely essential, no action on mouse-down, etc.) • no…

No action on mouse down? So we need to develop applications that you can't click? Is that really part of accessibility requirements these days?

There's a difference between mouse down and mouse up. A click needs both.

Re: From SVG to Canvas – A new way of building interactions

#75

Post by CornCobs »

> These InteractionHandlers are just objects satisfying a specific TypeScript interface. They’re not coupled to React or hooks or anything like that, which feels quite freeing, honestly. There’s no worrying about stale closures or dependencies or hooks rules - it really is just TypeScript.

> None of the interactions depend on a particular rendering system. We can actually use the DOM as a render target with all its pointer events disabled, and use this interaction system on top, which is quite neat!

In general, I think this is the most important takeaway here. Too often, we couple all our frontend logic to the rendering framework (especially state) when it has no business living in React and being tied to the component lifecycles.

I've had really good experience with MobX for React - separating out all our state into independent observable objects that React simply reacts to. This really cleans up a lot of logic and makes the presentation layer very clean.

In particular, a pattern that I believe in is simply exposing singleton, global stores for various parts of my application - effectively treating them as APIs that the rest of the app can subscribe to.

Re: From SVG to Canvas – A new way of building interactions

#76

Post by mwcampbell »

josephg wrote: post #10
rektide wrote: post #8

Earlier quoted context omitted.

Google Docs document canvas is a tool. Most of the chrome & interface is html & works great. The switchover to canvas broke a ton of extensions. Chrome eventually went out & built a custom api to help users deal with some of the massive loss of functionality that switching off high-level html to go use lowest level html caused. But that took a ton of effort from Google, & the result is still a shadow of what was poss…

> IMO, do the right thing for user agency & stick with higher level web stuff. Reinventing has many subtle pitfalls. This is great advice 99% of the time. But the browser has two big pitfalls which hurt google docs: 1. Browser rich text editing events are famously awful and inconsistent on different browsers and platforms. 2. Google docs wants the same document to render exactly the same on all OS / browser combinati…

> 2. Google docs wants the same document to render exactly the same on all OS / browser combinations.

I think the industry needs to let go of this need for control. The browser is a user agent, not an author agent, and the same should be true of a document viewer. (Ideally, the browser itself should _be_ the document viewer.) For accessibility, if nothing else. And as for users brute-forcing a page break, let them be forced to finally let go of the print medium. We've been shackled by the print-first approach for long enough. Yes, I'm talking about accessibility again.

Re: From SVG to Canvas – A new way of building interactions

#77

Post by rektide »

chrismorgan wrote: post #18
thomasfromcdnjs wrote: post #4

I've built diagram like tools several times, constantly umming and ahing between Canvas and SVG. SVG seems to get you pretty far, but I always end up with Canvas in the long run. Fun fact: Google docs is actually a canvas.

> Fun fact: Google docs is actually a canvas. This is often said, and almost as often misunderstood as referring to what I call the “pure canvas” approach where you throw away almost everything the browser gives you and start from scratch. Some key points about Google Docs, just to clarify (I’m not disagreeing ): ① Only its document area is rendered with canvas; its chrome is all still regular HTML. ② It still uses t…

This is one of the best comments I've read on the much ballyhood Google Docs canvas! Favorited. I expect I'll be referencing this a good bit over the years.

Re: From SVG to Canvas – A new way of building interactions

#78

Post by rektide »

mwcampbell wrote: post #76
josephg wrote: post #10

Earlier quoted context omitted.

> IMO, do the right thing for user agency & stick with higher level web stuff. Reinventing has many subtle pitfalls. This is great advice 99% of the time. But the browser has two big pitfalls which hurt google docs: 1. Browser rich text editing events are famously awful and inconsistent on different browsers and platforms. 2. Google docs wants the same document to render exactly the same on all OS / browser combinati…

> 2. Google docs wants the same document to render exactly the same on all OS / browser combinations. I think the industry needs to let go of this need for control. The browser is a user agent, not an author agent, and the same should be true of a document viewer. (Ideally, the browser itself should _be_ the document viewer.) For accessibility, if nothing else. And as for users brute-forcing a page break, let them be…

"Pixel perfect design" is a phrase I keep seeing from Flutter camp, from Towards A Modern Web Stack. I'm so with you though: that's an anti feature!

Developers/companies shouldn't have totalitarian control over the experience, I there should be malleability in software. Software is almost always best when it's not super hardened into form. This grasping for absolute control is poor form, in most cases.

Re: From SVG to Canvas – A new way of building interactions

#79

Post by rektide »

Super late to this but they mention element overlap in SVG making thinks like drag & drop hard. That's their "interactivity" gripe, and the one that for me carried the most weight.

I'd be very interested to get more discussion on this specific issue, of handling mouse events well in SVG.

The particular example felt contrived, in that I might just apply a class HasPointerEvents to every element and change the pointer events off for everyone except the drag & the dropped element. But I suspect there may be some other real mouse handling topics in SVG that really are interesting & challenging, & would love some discussion on that. Kind of iwld that the internet doesn't have a ton of obvious forums to go hash out tech topics like this... Post a random question/challenge to stackoverflow & cross your fingers.

Post reply on HN