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

61–70 of 97 posts

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

#61

Post by pyrelight »

simlevesque wrote: post #17

ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…

It's Flash Player all over again! Remember when SEO became important and everyone who had a Flash website had to make "low bandwidth HTML" sites for indexing? :)

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

#63

Post by sdiupIGPWEfh »

marcus_holmes wrote: post #9

> 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. This is a great example of "fighting the framework". React + SVG got them from nothing to a working product. But then they had to…

It's almost like there's no silver bullet, and neither management nor engineering are capable of sticking to one set of trade-offs. Instead, the product thrashes back and forth while trying to accommodate whatever the current feature demands happen to be, with no one applying enough higher order thinking to see that there is no end-state that satisfies everything. Just endless busy work, a few more paychecks, and actual value down the drain.

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

#64

Post by a13o »

azangru wrote: post #39
simlevesque wrote: post #17

ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…

Tangential question: how does accessibility work in Google Docs after they've switched to canvas? Or in Google Maps, which would be a much closer parallel?

There's an accessibility mode you can enable which provides keyboard and menu navigation, as well as audio cues. It's basically an alternative interface for interacting with the data layer.

I actually think this is a better approach to accessibility in web applications than trying to hang all of HTML+CSS+ARIA on the DOM. Check out Accessibility Object Model (AOM) for one spec proposal around this idea.

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

#65

Post by magpi3 »

marcus_holmes wrote: post #9

> 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. This is a great example of "fighting the framework". React + SVG got them from nothing to a working product. But then they had to…

This in a nutshell is why Visual Basic 6 eventually failed. It worked for your use case until it didn't. And of course a programmer could dive into COM and ActiveX to extend it, but avoiding that mess was why people chose VB6 to begin with.

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

#67

Post by josephg »

chrismorgan wrote: post #50
josephg wrote: post #31

Earlier quoted context omitted.

Ok, sure - you got me. If you mess with obscure browser options, you will successfully change how google docs renders content. But I suspect all of the people who select that option would fit in one meeting room, with a sign out front from google which says "WONTFIX". One thing people do do all the time in word processors is mash enter until the next bit of content ends up at the top of the following page. If a user…

I select that merely as the easiest way of demonstrating that it’s leaving important parts of its layout to the browser—parts that are not always consistent. There will be places where browsers in their default configurations differ, especially over time, to do with things like varying Unicode support or exotic OpenType shaping features, or even simple hinting. They won’t often be as big and flashy, but they’ll cause…

> There will be places where browsers in their default configurations differ, especially over time, to do with things like varying Unicode support or exotic OpenType shaping features, or even simple hinting.

And my point is simply that google docs is explicitly designed to prevent any of these sort of issues from being noticable to the user. Sure, maybe individual characters or words will render slightly differently due to type hints. But as I understand it, google tries to make sure it never results in an added or removed line anywhere. The only way they can make sure of that is by shipping their own text layout engine. And hence the use of canvas to render text.

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

#68

Post by Malic »

magpi3 wrote: post #65
marcus_holmes wrote: post #9

> 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. This is a great example of "fighting the framework". React + SVG got them from nothing to a working product. But then they had to…

This in a nutshell is why Visual Basic 6 eventually failed. It worked for your use case until it didn't. And of course a programmer could dive into COM and ActiveX to extend it, but avoiding that mess was why people chose VB6 to begin with.

I feel the same way about WordPress. If you stick to it's sweet-spot as a solution, it's ... good enough and cheap. But too many folks have this hammer called WordPress and see a world full of nails.

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

#69

Post by thekenwheeler »

paulddraper wrote: post #29
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.

You start with SVG Then you go to Canvas Then you go to WebGL Source: Early engineer at Lucidchart

it depends. canvas is typically much more cpu friendly. and does a way better job with text. (2d)

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

#70

Post by chrismorgan »

josephg wrote: post #67
chrismorgan wrote: post #50

Earlier quoted context omitted.

I select that merely as the easiest way of demonstrating that it’s leaving important parts of its layout to the browser—parts that are not always consistent. There will be places where browsers in their default configurations differ, especially over time, to do with things like varying Unicode support or exotic OpenType shaping features, or even simple hinting. They won’t often be as big and flashy, but they’ll cause…

> There will be places where browsers in their default configurations differ, especially over time, to do with things like varying Unicode support or exotic OpenType shaping features, or even simple hinting. And my point is simply that google docs is explicitly designed to prevent any of these sort of issues from being noticable to the user. Sure, maybe individual characters or words will render slightly differently…

> And my point is simply that google docs is explicitly designed to prevent any of these sort of issues from being noticable to the user.

I’ve demonstrated one place where it very obviously failed at this goal, and I know enough about variation in shaping to confidently state that others do exist, though the most obvious are almost entirely historical. But there are variations that can change glyph advance, which will affect layout.

They use the browser’s shaping, so they’re subject to its quirks. In order to obtain absolutely consistent layout, they’d need to do the shaping themselves, but they have chosen not to do that (and I think they’re right not to).

Google Docs has clearly been pushing for non-pagination in more recent times, and paragraph layout largely doesn’t matter once you’re not fussing about pagination.

They reimplemented breaking paragraphs into lines, but gained literally nothing thereby in terms of actual functionality or behaviour, since the browser offers absolutely everything they wanted from it, and they still rely on the browser for the shaping.

Post reply on HN