When people refer to HTML5 for games (including this post) they usually mean the HTML5 canvas and its associated APIs (canvas/webGL), not using actual HTML elements to render game graphics.

From what I know, canvas rendering is pretty much the same across different browsers. It's a pretty low level API so there's not as much room for interpretation. In any case, the Acid3 test you're running is focused on the specifics of HTML/CSS layout, and don't think it tests the canvas at all.

I think that canvas has done a good job of taking over the use cases that Flash had, and is very portable these days (basic canvas has 98-99% support[0]).

[0] https://caniuse.com/#feat=canvas

Canvas rendering isn't that consistent, and when it goes weird it's often OS specific instead of merely browser specific. Some things I've run into:

- OSX likes to turn random Unicode symbols into emoji (extends past Canvas)

- Fractional font sizes on Chrome/Linux get bizarrely stretched out (after a transform that makes the font not a fractional size)

- Complex clipping operations freak Chrome out

- All the compositing rendering options are broken somewhere or mis-defined to the point that it's weirdly hard to render anything to an alpha channel

You also need input APIs to make a game, and the input APIs often have strange inconsistencies in function names, returned objects, or event ordering.

Canvas is nice and straightforward if you want a purely sprite-based game with only mouse/keyboard input (but even then you need to jump through hoops if you want pixel art). Anything beyond that is going to need cross-platform debugging.

Canvas has also had some really weird performance issues in the past that are browser specific. Chrome once decided that the number of images used was too many in an animation, so it had to decode some of the images in the animation on the fly. This obviously killed all performance. This bug has been fixed, but I'm sure there are many others like it around.

> ran the Acid3 test, and got different results at different speeds

It's worth checking the Acid Tests homepage [1] here:

> Acid3, in particular, contains some controversial tests and no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers.

[1] https://www.acidtests.org/

Well, the rendering problem can be solved by using an existing game engine. Rendering is done in WebGL, and the engine abstracts away the browser-specific details.

Furthermore, because of Google's dominance, not many browser engines are left in the market. Essentially all you have to do is support WebKit, Gecko, Blink, and you'll cover 99.9% of your userbase.

The HTML part of javascript game engines is generally just enough to get a <canvas> on screen and dive into WebGL.

The thing is, you can target Unity/Unreal/etc at a browser and get most of the benefits listed above, plus the benefit of using more-or-less the same toolkit as everybody else.

Has Unreal improved their HTML5 offering? It used to be rather poor, because of the immense filesize of the engine. Have they got it down to reasonable levels yet?

How is that a unique problem? If you have an iOS native app and you want an Android native app the difference are probably 100x the differences needed to deal with Safari's quirks vs Firefox's vs Chrome's. Same for Mac->Win->Linux.

The context of the discussion is HTML/JS as a game development platform. Considered as a platform, that is rather unique. iOS and Android are generally not considered as a single platform.