While this is fantastic as a demo, I hope this does not become a huge trend. Canvas is almost as bad as flash if you use it this way
I googled your site and found this URL that looked like a PDF (http://ericlesch.com/eric-lesch-resume.pdf), but it didn't work either. You know something's wrong when your users would rather take a PDF than whatever you're doing.
(Also: no robots? Why not? I can't even use Internet Archive to see the past PDF link or the less canvas website, nor can I use Google to search just the text of your site.)
The loss of highlighting text and accessibility is unfortunately unavoidable if you are using Canvas or WebGL for rendering. That's the price you pay for having better animation performance - so it's a tradeoff.
And no, I don't have a BS in CS. ;-)
On the flip side, anything of less complexity will necessarily be less flexible. Though giving up some of that flexibility may not be a bad thing.
I don't say this to discourage, as I frankly think the technology in general is headed in that direction and have done my own work in that regard.
It would be interesting to see if anyone will create a feature-complete HTML rendering engine in JS. It will significantly change how we approach web development, as the choice in rendering engine would move from the user to the developer.
Not accessible for anyone with accessibility options.
Probably not going to work well, if at all, for people with JS disabled.
More error-prone, imo. I've had HTML5 canvas projects in the wild for over 1 year working fine, until Chrome updated its browser and it started producing errors for one particular deprecated function. You obviously can build web apps to continue working, but mine didn't out of the box. If you write websites in HTML the chance that your entire website stops loading and working completely due to one issue is extremely small.
Beyond that canvas takes a bit more resources which is an issue for mobile. My canvas projects also always sucked up quite a bit of battery somehow on mobile.
Lastly, there aren't any huge benefits imo. HTML5 & Canvas are awesome, they have their place, but atm more like Flash: Games, (interactive) Advertising banners, complex animations to create a brand experience etc.
But for an actual website? If you can't do it with CSS animations it's probably way too annoying, for example while this website is 'nice', I don't like it. I'd hate to have more websites like this, the animations just get annoying. Animations aren't there to be fancy, they're there to be intuitive. If you have a drop down menu, it may drop down, not because it's fancy but because you understand that it origins from a certain click on an element, and the menu's options are contextually associated with that element. Which is why a slide in or fade in animation would make no sense, it's animating for animation's sake.
I can't copy and paste text off of it.
It's not accessible; screen readers can't read anything off of it.
It renders at half the DPI of my screen.
At some point, I wound up on a blank screen with no way to go forward or backward to anything but the "create a free website" banner. Haven't reproduced that to give you repro steps, but it happened.
It was frequently janky on my machine; animations would hang occasionally.
It doesn't work at all on my mobile browser (Firefox); I just get a white screen with the banner at the bottom (it did work on Chrome, but the "Back" button was frequently hard to hit).
All of this could be done by animating actual HTML content using JavaScript or CSS animations, in a way that would degrade gracefully for people who couldn't use those for some reason, and which would render at the full DPI of my screen, be copy/pastable, searchable, accessible, and so on.
By the way, the editor on makemake.io is fairly impressive. But it seems like it would be more appropriate for it to edit HTML with JavaScript or CSS animations, or SVG, rather than a custom rendering engine using Canvas.
None of the text is in HTML which means:
- it can't be used by assistive technology, e.g. for people with reduced visibility. People with partial sight use the web too.
- it doesn't work in reader mode, which is a common feature of web browsers to use standard CSS to read just the content.
- it has none of the benefits of WAI-ARIA
- I can't use services like Google translate
- that archive.org doesn't work
- search engine X can't index it. Maybe Google could one day with the right investment in technology, but there are more search engines than Google.
None of the styling is in CSS which means
- your animation wastes CPU cycles and isn't optimised
- I can't increase the size of the text if I need to if I have poor eyesight (zoom just makes the whole canvas bigger)
- on my phone screen text is unreadably small and I can't do anything about it.
- you're re-inventing layout stuff that browsers do. I found a layout bug[1].
Reinvents stuff that web browsers, not JS should be handling which means:
- I found a navigation bug in a few seconds[2].
- it doesn't work with older browsers. Some people are still using old versions of IE and can't switch.
- that standard web behaviour doesn't work. How do I open a link in a new window?
- it forces me to use the mouse to click things rather than the keyboard (not everyone uses the web the same way you do)
- it doesn't work at all if JS is disabled.
[1] Layout bug: load window with small window size, then resize. Some circles move, some don't.
[2] Navigation bug: back button doesn't work under certain circumstances.
This is a good technical demo, and shows the development skills of the author. Unfortunately it also shows that he has no idea about core web development issues, which on the web is probably more important, especially in a portfolio piece.
Rather than trying to change the world to not use canvas, how about screenreaders get fixed to read fonts off canvas?
Probably because the site author isn't taking the window.devicePixelRatio and backingStoreRatio when creating the 2D context.
> this "text" isn't in the DOM, it's not real text
The text is not in the DOM, but that doesn't mean it is not real text. It is text, literally strings, written with `context.fillText()` which could certainly be wrapped by screenreader software.
Doing so would make the world a better place for the bling by providing a more consistent experience - since 100% of people using canvas will never get extra budget to modify their logic, but 100% of canvas fillText() calls could be handled by a screen reader.
Unfortunately a great deal of engineers seem to have invested time and reputation in the unlikely change-the-world scenario, so I suspect blind people will continue to have a poor experience on the internet while a11y engineers who don't actually care for workable solutions continue to dominate the discussion.
As it stands, there's a way of saying 'I put some text on the canvas' but no way of saying when it was removed. The whole canvas could be cleared, or a particular region could be cleared, or over-written, or the canvas could be resized, which would result in it being cleared.
So if you wrote to a buffer every time you wrote text to the screen it would fill up pretty quickly. If you animated anything (as is happening in this example), then you'd have a million copies of the same text as it was re-drawn each frame.
There's also the temporal aspect, of course. With CSS it's possible to say 'this text is relevant, but you'll see it in a few seconds'. If you disabled CSS then the text would be there, static. If you were using a screen reader, you wouldn't know it was there until a certain point in time. That's not particularly compatible with the way people use screen readers.
The answer to which might be to manage on-screen resources and keep track of what is visible on screen and when it's removed.
And how do you represent the page hierarchy? You'd have to emulate some kind of DOM.
All of which comes under the banner of 'replicating the stuff that browsers already do, but with inevitable bugs and overhead and things you hadn't thought of'.
I think the appropriate response is to use canvas for interesting graphics that can't be done without it, and to keep text and markup for textual applications. Of course you can push the envelope of what's possible using new tech to create novelties, but it shouldn't be advocated for 'normal' web applications.
It looks like this page is a promo for a general content authoring system based on rendering in canvas, and that's a bad idea for all the above reasons.
Indeed. That's a solvable problem - you can track pixels and estimate with a degree of certainty - but it certainly does exist.
You'd also have to determine prominence of the text, which again is solvable assuming the size and weight and zoom level of the text has some bearing on the importance.
And you note the temporal aspect too - you'd have to track whether something was visible, ie sufficiently contrasts against the background, not opaque etc.
And indeed, there's no hierarchy asides from prominence.
All of that, plus more, is far more easier than getting the entire world to avoid, or write fallbacks for canvas.