Hacker News Reader

Comment by Ygg2 | Hacker News Reader

At risk of downvotes I must ask why? New input are added probably to bring them more in line with system inputs of the operating systems.

View on HN

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.

By stopping trying to make a document technology bend into an application stack and use native applications instead?

The more web projects I work on, the more I like desktop technologies.

That ship sailed when forms were added. You might be interested in Gopher (no, really, it's still great).

If you are only doing data entry yes.

Thankfully many are doing native on the mobiles, and the stories of companies being burned by HTML5 not being ready help as well.

There's that "document technology" canard again. It never fails to appear.

So your suggestion on how to make the web better is to abandon it. Okay, your input here is done.

I am happy that I was able to fulfill your expectations...

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.

Reply on news.ycombinator.com