However, let me burn some karma this fine morning:
All of these layout libraries are, in my opinion, indicative of the fundamentally flawed layout model of HTML and CSS: it is overly complicated and can be extremely difficult to achieve bog-standard layouts (e.g. name-value pair forms) without lots of css work (in relative terms) and a deep understanding of the CSS layout system. For example, google "center a div on a page" and witness the carnage. I find the Swing layout managers, for example, far easier to work with in achieving a given UI that looks correct and resizes correctly as well. The client-side web has ignored many of the lessons of thick client development, much to its detriment IMO.
Same goes for mixing code and markup. When I put a button on a page, I want to put the code associated with that button in the definition of the button. Not in some random file tied to the button by a brittle and easily-duplicated id. Separating the markup and the programmatic logic is now orthodoxy, but it's a stupid orthodoxy: yes, yes, you don't want to put domain logic in your UI, but why the hell would you want to give up being able to quickly ascertain what a button does, even if you didn't create the UI?
No one is saying that HTML and CSS aren't with flaws. They are the industry standard, supported by all modern browsers, which changes everything. Similarly, you may prefer the syntax and philosophy of Lisp, but that doesn't change the fact that Java/C++ are far-and-wide the most popular languages used, and in many industrial applications -- industry standards.
The pro's for separating code and markup are thought to outweigh the cons, but there is nothing forcing anyone to adopt this standard. As you may or may not know, re-usability and maintainability can go a long way when working with a large webpage. If I am trying to massively overhaul my website while maintaining the same use-cases, the javascript is probably not going to change, but the HTML and CSS will, and herein lies the benefit of separation.
That being said, if for some reason you would prefer a button's behavior to be more apparent in it's markup, scripts can be used in-line with identical functionality. If your concern is linking to an external document (which is also done as a step of simplification of large projects, not obfuscation) it is totally acceptable to style an HTML page from internal <style> tags.
The problem is that people don't bitch enough (or barely at all, really) about the flaws of HTML and CSS, and rather just run with the insane decisions that are made. We get a huge "design" industry that has grown up creating one-off widgets, layouts and UI metaphors, and ignores many of the best lessons from thick client applications.
Why does the separation of the html and javascript matter to you? I can see the CSS being separate, at the very least for style reuse, but why keep the functionality of a widget off in a separate file, tied only to a widget by class or id? I don't make a conceptual distinction between the button's markup and what the button does, and I want to be able to look at a button in a file and understand what the hell clicking on it makes happen. Moving the code away from the definition of the button is obfuscation, except to designers who can't stand to see a bit of javascript in their HTML.
If you don't subscribe to the logic and end-user benefits of progressive enhancement, there are probably many things about HTML+CSS+JavaScript that you don't like.
However, what are the arguments for what you are asking for besides easier short-term development practices? And, as said above, there's nothing stopping you from building your webpages that way (especially a “widget” that is self-contained). It works that way as well. How does this make HTML+CSS+JavaScript broken? If anything it is very resilient to different coding practices.
I pressed Ctrl+- a few times and your design broke—the "Paste some code" and "Apply settings" get shifted right, off the page, with a huge space in their place.
6 comments
[ 4.6 ms ] story [ 37.6 ms ] threadHowever, let me burn some karma this fine morning:
All of these layout libraries are, in my opinion, indicative of the fundamentally flawed layout model of HTML and CSS: it is overly complicated and can be extremely difficult to achieve bog-standard layouts (e.g. name-value pair forms) without lots of css work (in relative terms) and a deep understanding of the CSS layout system. For example, google "center a div on a page" and witness the carnage. I find the Swing layout managers, for example, far easier to work with in achieving a given UI that looks correct and resizes correctly as well. The client-side web has ignored many of the lessons of thick client development, much to its detriment IMO.
Same goes for mixing code and markup. When I put a button on a page, I want to put the code associated with that button in the definition of the button. Not in some random file tied to the button by a brittle and easily-duplicated id. Separating the markup and the programmatic logic is now orthodoxy, but it's a stupid orthodoxy: yes, yes, you don't want to put domain logic in your UI, but why the hell would you want to give up being able to quickly ascertain what a button does, even if you didn't create the UI?
Downvote away, kids.
The pro's for separating code and markup are thought to outweigh the cons, but there is nothing forcing anyone to adopt this standard. As you may or may not know, re-usability and maintainability can go a long way when working with a large webpage. If I am trying to massively overhaul my website while maintaining the same use-cases, the javascript is probably not going to change, but the HTML and CSS will, and herein lies the benefit of separation.
That being said, if for some reason you would prefer a button's behavior to be more apparent in it's markup, scripts can be used in-line with identical functionality. If your concern is linking to an external document (which is also done as a step of simplification of large projects, not obfuscation) it is totally acceptable to style an HTML page from internal <style> tags.
Why does the separation of the html and javascript matter to you? I can see the CSS being separate, at the very least for style reuse, but why keep the functionality of a widget off in a separate file, tied only to a widget by class or id? I don't make a conceptual distinction between the button's markup and what the button does, and I want to be able to look at a button in a file and understand what the hell clicking on it makes happen. Moving the code away from the definition of the button is obfuscation, except to designers who can't stand to see a bit of javascript in their HTML.
However, what are the arguments for what you are asking for besides easier short-term development practices? And, as said above, there's nothing stopping you from building your webpages that way (especially a “widget” that is self-contained). It works that way as well. How does this make HTML+CSS+JavaScript broken? If anything it is very resilient to different coding practices.