Show HN: My animated website, rendered entirely in HTML5 Canvas
ericlesch.com
ericlesch.com
- The animation makes refreshing work really strange. I can see the buttons, they then disappear and re-appear before I can use the website.
- Can't select text, no copy and paste, going to have to manually type out your email address to contact you? Never mind what it does for accessibility/SEO.
- I had a problem with the back button sometimes taking me to a blank page (forcing a refresh and another watch of the name animation), though this seems to have stopped happening.
Interesting experiment, if only to show why this is a terrible idea.
This site doesn't follow any specific standards, but {most} agencies won't either, because they're billing their time
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.
Most of the technical issues raised are fixable but a few are not.
SEO is fixable by following the Google ajax SEO spec. Accessibility and other issues with selecting and highlighting text are not.
Many of the other criticisms could also be levied at other javascript heavy sites (e.g. Facebook).
It's clear that many people are philosophically opposed to rendering websites in Canvas because it reminds them of Flash and is incompatible with the semantic web.
I guess the proof will be in whether or not web consumers end up thinking it is cool or not. That remains to be seen. Personally I think this approach opens up a lot of interesting possibilities.
Anyway, thanks again for your interest and responses, even if they were largely negative. :-)
From worst to best, Safari appears to have inconsistent antialiasing and no hinting, Firefox has no antialiasing, while Chrome looks the best with antialiasing. They all look fairly blurry and out of place.
- I don't have immediate action items - regardless of remote resource load times I'm forced to wait for a two-part intro animation to unfold before I can do anything, even on my fourth or fifth visit. I don't have time to wait like this, and I don't want my users to have to wait for superfluous visuals either.
- There's almost no content - I'm not sure what the "progress" bars in the skills section measure and how they were calculated, no description of accomplishments or skills built in experience section
- UX animations are clunky at best and misleading at worst. The rectangle of blue that becomes the "back" button and sets off "Javascript Developer" gracelessly darts back and forth, and why when I press "back" does the carousel effect continue to turn forward?
I recognize this is likely more an opportunity to show off makemake's abilities, but as someone evaluating a potential hire I'm left with a lackluster impression. Apologies if this is too negative - I'm hoping the honesty will offset any lack of tact.
You just picked a tough crowd to show this to... everyone here cares about the semantic web and has nothing but contempt for the "all-flash" websites from 15 years ago. You should really try making a CSS3 version that just puts z-indexed img and div tags in an relative positioned container and animates the x/y. Then people could insert their semantic HTML and animate it however they want.
If you go that route you could even allow people to create small widgets/components. Say you want a crazy/animated sidebar but don't want to break the rest of your page... you could just open up your editor and work on just the widget and export code to drop that widget into your page.
Overall I think this is an awesome project. I'm also coding a huge HTML5 editor project you should check out when it launches... http://www.superanimo.com
It's more of a competitor to GoAnimate/PowToons than your startup. I think HTML5 canvas is underutilized in the startup community so I hope both of our projects take off.
I also thought about doing the same thing in DOM with Famo.us but I found after some experimentation that the performance wasn't good when you had a lot of objects on the page. Canvas animation perf scales reasonably well.
Regarding widgets, I think maybe you are talking about something like http://themeforest.net/item/quasar-wordpress-theme-with-anim...
I think you can also do that sort of thing with Adobe Edge or Google Web Designer.
Anyway, thanks for the feedback. I'd like to see your project when it's completed. :-)
I don't have a mailing list. I hate signing up to lists that are all talk about an unreleased product... I rather just show people when it's ready. I have a full-time day-job so I can't work on it as much as I want, but I should have a rough version live at the end of next month.
- SEO sucks. - You're killing the Web semantic :-)
To really make a point, CSS 3D websites are even cooler :) some of you might remember acko.net [1]
TypeError: this._container is null line 177 > eval:1:330345
That is because I pause the rendering engine if the browser tab is not focused. I don't want to consume a bunch of CPU and memory when the user isn't looking at the site.
How would Google index this site?