Something is wrong with this picture.

Either you have separation of data and presentation or you don't. HTML didn't. HTML5 still doesn't. It is not possible to present an arbitrary block of data in a normalized, optimal form, and have CSS render it any way you want. For that you need script (or XSLT!), but even then, unless you go canvas, you have to deal with a markup language for presentation that is actively trying to not be presentation but be data instead. Its trying and failing. Life would be so much easier (and involve much less cognitive dissonance) if the DOM stuck to being presentation.<p>As it is, developing web apps is this giant joke, where you encrypt what you really want to happen in the form of pseudo-data (html) and magic rule-based transformation (css), and then the browser goes to a ton of effort to attempt to recreate what you really wanted. The effort the browser has to go through as soon as you introduce a div, or change its class, just to determine which, if any, of the CSS rules now apply to that node and any of its children, is just offensive. Worse: its something you, the programmer, must be able to model in your head to determine what the fuck is going on. Good luck with that! The result we get is "try it and see" "programming".<p>HTML1.0 was a local optimum. Somewhere there is another, better optimum. The W3C appears to be willing to travel the Himalayas of suboptimal to find it.

HTML markup is a good example of premature design optimization. It may have been a good in theory to separate content from presentation, but if you look at the web today, the way pages are generated is a huge mess.<p>Even this site, which uses tables for layout when "you're not supposed to used tables for layout", is a good example of why HTML is so bad for creating web pages. There's no reason I should have to jump through all the hoops I do to display two div blocks side by side in a horizontal box. All other XML based layouts I've used (Android and Flex) are a piece of cake compared to messing with HTML, CSS, and JavaScript.

Many of us are developers on here, so I propose the following: rather than be lead around by the nose on this, why don't we change it? We could define our own XML (or JSON? optional?) based <i>data markup</i> format and a separate <i>presentation markup</i> (XML/JSON based though!) format for displaying it on a graphical interface. Then we could create a browser plug-in that used it, or fork a browser to understand how to render it (or both).<p>We could set up our web servers to detect if the client has the plug-in/browser and serve this new standard if so, or redirect to "legacy" web pages if not (with a little "best experienced with" badge). If the day comes that we aren't getting anymore "legacy" requests we can just drop them (or even better, just program the servers to be able to auto-generate something passable if a legacy client did happen by). If done right, this really could get traction, since most web designers would prefer a nice format to fighting their way through as one has to today, and clients shouldn't be able to tell any difference.<p>The web is ours. If the "standards bodies" are making crap standards we don't have to stand for it.

"I heard people speak of Web Authors and Web Developers and making various distinctions about them. I heard some folks of arguing that this audience of ours prefers markup over scripts, and when faced with concrete examples of the opposite, retort that those are just some script library folk, not the majority."<p>Get these people some personas, stat!

A markup language, by definition, cannot define behaviour. You can do design, layout and animations with markup, but you simply cannot do any kind of processing or behaviour (when I say behaviour, I mean things like authentication, processing, manipulating data, etc). So if your webapp needs to be behaviour-rich (which I don't know how you can call it a webapp if it isn't) then you're going to need a scripting language to define those behaviours.<p>HTML + CSS + JavaScript are complex tools, it would be great if we could unify them into a single language. I think that jQuery's success is in part due to this unification, but I certainly don't think jQuery is the answer.

I guess the real question is can you or how would you try to reform the culture that has surrounded the process? Or is the alternative branching out and creating your own like WHATWG?

The thing is, web was supposed to be about documents but it always wanted to be about programs. A basic markup language together with styling goes with the former but in the latter it becomes something you need to work around.

For me this just demonstrates W3C's distancing from reality... There where pretty good data-driven and thought-out decisions on HTML5 from the beginning, but things were pretty grim for this year. Parts of the spec are being just pushed around (microdata…), meanwhile there is no public place for developers to be heard (and no, mailing lists and bug trackers are not ideal. this is 2011).<p>Despite that, the web as a platform is getting better and better. Yes, it's hard to build stuff with HTML/CSS/JS, but it gets easier by the month, and the current state of the technology is really amazing (except for a few legacy browsers still bogging things down).

I like to think the whole problem with web development is that it is popular. Almost all of the exclusive web design/script people I have met are essentially terrible at what they do - I think this happened because the web is so popular and so new that the good engineers and designers are so few and far between that their direction is diluted by the masses. Hopefully it will right itself over time.<p>Ultimately the tools will mature to the point where what the data representation is beneath them will mean nothing to these kinds of consumers. (e.g. how you save your photos as .jpg, .tga or whatever and usually care less about the details).

In this age of rich webapps, the markup is just there to launch javascript. There's nothing particularly wrong with that IMHO.