> I found NW.js before that and wished it was more popular and had more love nw.js made me appreciate HTML5 so much. I ran into bugs with literally every sing

> I found NW.js before that and wished it was more popular and had more love nw.js made me appreciate HTML5 so much. I ran into bugs with literally every single nw.js API I used in the application. Here's a taste: * nw.js window menu: arrow keys don't properly navigate across menus, accelerator shortcuts randomly break (bog standard ones like <ctrl-1>), some weird race condition displaying the menu which affects the dimensions of the document that get returned by the DOM, inability to change an accelerator shortcut during runtime, and many, many more * at one point, the nwworkingdir attribute for input tags didn't work unless I injected the tag/attr/value as innerHTML * win.zoom and menu.popup didn't play well together * many others On the other hand, the only HTML5 limitation I can remember was that SVG's getbbox will include clipped content in the returned bounding box. There's apparently a newer option to exclude the clipped areas, but AFAICT it isn't honored in any of the browsers. So each time a user would submit a bug, I'd get a sinking feeling because I just knew it'd be some weirdness in one of the nw.js APIs which would have scant documentation. If that turned out to be the cause of the bug it would either be unfixable or require really nasty kludges to work around. (E.g., at one point nw.js didn't play well with the @font tag, but after hacking I figured out that it would work if I included the font inline in the relevant css as a data url.) On the other hand, if the bug had to do with my own buggy js code or a misunderstanding of the DOM, I'd get excited because I knew there'd be 1000 pages of documentation, 10 years of various workarounds (most with code examples on SO), and probably even a blog with smooth animations showing why that part of the DOM works the way it does.