4 ms·

It doesn't solve anything. When you move such functionality into HTML you will just get "thousands" of browser specific datepicker implementations, in each vers

• Shish2k 14y ago
  > 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