So you can write on the checklist of things html5.5 or 6 or whatever needs:
* Local config storage (doable in cookies or localstorage)
* Local save storage (probably too big to fit in 5MB of localstorage)
* Mouselook (mouse buttons work fine). I think you can already do this
though, I know you can at least track cursor position and you can implement mouselook off that.
* Mousewheel in firefox, at least, wasn't rebindable.
* I see problems in fullscreen browser games that take every single browser button and override it, so you would probably want a "you can't rebind this key" key. If there isn't already one.
Tracking view position from mouse coordinates has always been possible, but handling mouse focus and coordinate wrapping is necessary for games with mouse look. The really tricky bit is that there are security implications in much the same way as full screen mode.
It's a start. Browsers were not getting any faster before because no one was pushing their boundaries, but nowadays it's a different story. I think we can expect browsers to get a helluva lot faster within the next 3-4 years, specially when it comes to canvas processing and rendering.
> Do we need all the power a PC provides natively to make great games?
I think the market has declared this to be a definitive "yes". Users don't want to waste their hardware dollars so that you can spend them on inefficient solutions.
When your competition takes advantage of the hardware, and you don't, then your application (or game) falls behind in the marketplace.
There's the argument that users are willing to have lesser performance ... for lesser cost. This is true, but quite different from your code performing more poorly than your competition's on the same hardware.
the function of computing power -> game quality is logarithmic, not linear. The 15 years behind of 15 years from now is a considerably smaller gap than the 15 years behind of now.
Crashing your browser (which browser?) or actually crashing the entire OS. Both are worrying from a security perspective, but the latter is very worrying.
To update, it looks like both the gwt quake to and the OP's quake crash safari and chrome on osx, but work great in firefox. The quake 1 demo actually runs noticeably quicker than the gwt one for me. This is a great showcase for what's possible for js games.
I've always thought about how well we learn lore and geography inside games we love (for example, I know where everything is within several different lands of Hyrule), and yet it's very hard to get students to really learn actual Earth geography. Perhaps some aspects of this kind of teaching should move into a gaming environment in schools.
I still don't understand his logic for this: Element fullscreen is not going to be added because there's already browser-wide F11 fullscreen.
If pointer-lock only works in element-fullscreen in Firefox (on which he develops) then what other choice is there ? Nobody plays shooters with the keyboard since wolf3d, and the BananaBread demo does pointer-lock precisely via element-fullscreen.
I think it's an interesting question of time. Quake I came out june 1996; so, html5 is almost* capable of doing a 16 year old game. This... is interesting from a data point perspective.
There is an open question as to how html5 now compares to native some years ago since that's how (for gaming) it should be judged. I believe we will reach a limit point and in the long term, maybe the browser-related inefficiencies will just be marginal to the end user experience.
In Chrome on Mac and Linux, sound crashes the tab often. Play with ?-nosound or on Windows. The loading image is also not displayed in Chrome (unlike Firefox).
* Local config storage (doable in cookies or localstorage)
* Local save storage (probably too big to fit in 5MB of localstorage)
* Mouselook (mouse buttons work fine). I think you can already do this though, I know you can at least track cursor position and you can implement mouselook off that.
* Mousewheel in firefox, at least, wasn't rebindable.
* I see problems in fullscreen browser games that take every single browser button and override it, so you would probably want a "you can't rebind this key" key. If there isn't already one.