HTML5 is being designed by "professionals" and I have never seen such a mess. Functionality is being introduced that shouldn't even be part of HTML, just look at the amount of new input types.
HTML should be a markup language, CSS should be the styling language and JavaScript should be used to handle matters such as input, processing and output. The principle of separation of concerns is very simple and elegant. In the long run it makes sure you don't get a mess of a framework in which things can be done in 50 ways, of which 25 work only in browser X and the other 25 behave differently in each browser.
You'd rather have the current situation of thousands of badly implemented datepickers and people loading the complete jQuery UI suite just for the datepicker instead of a simple <input type="date" /> ?
It doesn't solve anything. When you move such functionality into HTML you will just get "thousands" of browser specific datepicker implementations, in each version of said browser.
If there is a badly implemented datepicker written in JavaScript you can use a different library. A good JavaScript library will make sure it works with consistency and as expected in different browsers.
> When you move such functionality into HTML you will just get "thousands" of browser specific datepicker implementations, in each version of said browser.
My phone has one phone-optimised date picker; my PC has one PC-optimised date picker; my screen-reader has one screen-reader-optimised date picker. Sure there might be other versions for other platforms, but I as a user would only interact with three, and those three are all consistent and optimal for their situation.
Seems much better than our current variety of scripts which all target the desktop PC and fail at it, and don't even attempt to work on any other platform...
> If there is a badly implemented datepicker written in JavaScript you can use a different library.
Not if it's on somebody else's site I can't.
> A good JavaScript library will make sure it works with consistency and as expected in different browsers.
A library written and deployed today will work flawlessly with the browsers of tomorrow, including things like screen readers which the library author hasn't even thought about?
Taking your logic further, why bother having HTML parsing, layout, or rendering in the browser? In fact, if you object to the idea of semantic markup and would rather manually specify every detail of every element for every situation, why are you using HTML and not giving users a .exe? :P
I do somewhat agree, but how would Javascript be made to create system looking controls (i.e. Unity date controls on Ubuntu, Windows like on Windows 7, etc.), without adding some extensions for DOM?
I personally dislike that CSS is turning into a miniature programming language, but I assume this is the way forward until something way better comes along and simply replaces HTML, CSS, JS. I mean its better to say width - 10 pixel than to make JS for each silly snipet like that.
Why shouldn't HTML be used for defining input forms? You are just stating that it shouldn't. CSS should be used for styling the input form and widgets because it is a styling language, but HTML is perfectly fine for defining the semantics of input forms.
