Show HN: NEW Heads-Up Grid: A Responsive Web Page Overlay Grid
bohemianalps.com
bohemianalps.com
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?
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.