5 ms·

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 p

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.

Ygg2 14y ago
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.
- pjmlp 14y ago
  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.
  - MatthewPhillips 14y ago
    That ship sailed when forms were added. You might be interested in Gopher (no, really, it's still great).
    - pjmlp 14y ago
      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.
  - corresation 14y ago
    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.
    - pjmlp 14y ago
      I am happy that I was able to fulfill your expectations...
huskyr 14y ago
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" /> ?
- qompiler 14y ago
  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.
  - 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
olavk 14y ago
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.

Ygg2 14y ago

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.

pjmlp 14y ago
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.
- MatthewPhillips 14y ago
  That ship sailed when forms were added. You might be interested in Gopher (no, really, it's still great).
  - pjmlp 14y ago
    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.
- corresation 14y ago
  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.
  - pjmlp 14y ago
    I am happy that I was able to fulfill your expectations...

huskyr 14y ago

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" /> ?

qompiler 14y ago
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.
- 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

olavk 14y ago

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.