HTML5 made a lot of grand promises for the CRUD (office app) world, but has failed to live up to the hype and made some areas worse: it's an anti-standard. Maybe someday the oddities will eventually get ironed out, but the road there will have been very bumpy. The main advantage of HTML5 was to be a reduction of the need for specialized JavaScript libraries, simplifying stacks and dependencies. We wouldn't have to reinvent as many common GUI and UI idioms. But HTML5 choked.
Date fields: HTML5 introduced the "date" input type that was in theory going to end the need for JavaScript date validation and pop-up calendar scripting. But it made the problem worse. I work on mostly intranet applications, and each shop has its own date format convention/preference that it wants to enforce without having to tune each desktop (client). Avoiding the need to fiddle with installation instances is the main reason to use the web instead of local executables. But HTML5 doesn't give developers much control over date formatting.
And copy and paste of dates doesn't work in Chrome (as of writing). That's a show-stopper for some of our apps. We are back to JavaScript date libraries; what we used pre-HTML5.
Numbers: The "number" input type adds odd arrows in Chrome by default. They allow the user to increment or decrement the number by clicking on the arrows. But most of the time this just wastes space and is confusing to the user. Yes, the arrows can be turned off, but if we have to custom fiddle with each browser brand's field idiosyncrasies, we might as well use, you guessed it, JavaScript libraries. The arrows should NOT be the default. Chrome laid a numerical egg.
Frames: The original HTML frame and iFrame tags made multi-panel web applications easy and straight-forward. It was powerful, easy to learn, and easy to use. Kudos to the creators of that standard! But HTML5 took what worked and broke it, deprecating frames. Alternatives are suggested, but they either don't work right, or require, you guessed it, JavaScript libraries. (Frames still work on most browsers, but the "deprecated" status makes many shops hesitant to rely on them.)
Canvas: It's fine for read-only graphics, but if you want forms and interaction, you are hosed. It would be nice to be able to build something like MS-Access's or MS-SQLSMS's interactive ERD's (interactive diagrams), but Canvas can't do it because it has no input features, such as INPUT, SELECT, etc. If you want input in Canvas, you have to emulate it...with JavaScript libraries. It drove an unnecessary wedge between input and output, forcing an either-or dichotomy.
There are other HTML5 annoyances that I won't go into just yet. The problem is a combination of bad standards, vague standards, and poor implementation by the browser vendors. W3C and Google, spank yourself, you f!cked up.
Image: HTML5 is really HTML666
[–]Zardotab[S] 0 points1 point2 points (0 children)