XML to the rescue! The alternate future of the web! XML + XSLT (stylesheet)-> XSL:FO (intermediate XML language for formatting) -> FOP (program to convert formatting objects to output) -> rendered format. XML all the way down! (One mistake, zero output.)

In your latex equation, you are missing where the data goes. The idea for html/css/js is that data goes into the html, layout and styling into CDs and interactivity is defined in JavaScript.

That makes sense. The problem is that we never got anything close to that.

The problem is it doesn't really make sense in 2015.

Or rather, it only makes sense if you accept the technical debt inherited from HTML, which is itself the simplified stepchild of SGML, which was a 1960s idea and firmly rooted in paper publishing.

Separating content and presentation isn't a bad idea. The badness happened because JavaScript - or some other web programming language - didn't appear until HTML was established. So instead of a generic object model, with tagged content containers linked to an updatable library of presentation and layout code that could be standardised and refined continuously, some semi-standard version of a sort-of-working layout library was pre-compiled into browsers and accessed through a not very coherent DSL.

This made it fast enough to be usable - a very good thing, given 1990s processing speeds - but it also made it much harder to develop and fix.

In 2015 CSS shouldn't really be necessary. So much layout and presentation is done with JavaScript anyway that it would make just as much sense to get rid of CSS and extend and standardise on something like jQuery-but-better to create an evolving cacheable layout library that bypasses browser quirks and uses exactly one common versioned codebase.

This might seem ambitious, but writing good code that works across all common browsers now is such a nightmare for everyone that too many devs are either not bothering, or their bosses are telling them not to bother because it's too expensive.

As a user, I keep finding sites that simply don't work in Chrome or Safari or IE or whatever. That's not good, especially when there's a business at the other end trying to sell things.

I don't doubt the web will creak along, and some people will do amazing things. But it's still frustrating when it could be simpler, more standardised, more consistent, and much more reliable.

> So much layout and presentation is done with JavaScript anyway that it would make just as much sense to get rid of CSS and extend and standardise on something like jQuery-but-better to create an evolving cacheable layout library that bypasses browser quirks and uses exactly one common versioned codebase.

The concept of executing untrusted code is entirely antithetical to security. Javascript, or any Turing complete language, or perhaps that even is too precise a constraint, is a remarkably bad idea for setting the style of anything that is otherwise static. There's no good reason that text and images need be stylized via a proper language rather than static, non-executable statements.

> As a user, I keep finding sites that simply don't work in Chrome or Safari or IE or whatever.

I keep finding sites that simply don't work at all in Firefox with NoScript. Many of those sites are primarily just text and images which don't display otherwise. It's completely insane from a security point of view.

As a web dev of 11 years, I don't find writing cross browser code a nightmare. And any web site that doesn't work cross browser is by amateurs at best.

I don't know what web sites you visit where you have such issues but I haven't seen them in years except for the occasional goofball site.

As someone that had to support IE6 and Chrome at same time, I can't agree with this statement.

Are you seriously trying to throw IE6 into this to attempt to prove your point? We aren't talking about antiquated browsers no one should be using today.

Are you seriously trying to deny IE6 isn't there in the wild? It was a job I had to do. I was paid to do it. It was awful. This happened circa 2013.

For contrast I now support IE8 and IE9. Without jQuery. It's bad. Really, really bad. Like, there isn't indexOf on Array and asking for polyfill is forbidden.

You're one-off job is nothing to be holding up as an example of current web development. My company has 23 active clients and I can't tell you the last time, many years ago, we saw IE8 in the visitors logs much less anything less than that.

You should not be so quick to dismiss other people's experience. You should also not assume that your experience is the world norm.

Us programmers often get this wrong.

Much of the government and enterprise sectors don't want to upgrade their browsers. They put a lot of money into their crappy intranet apps around 2000, and don't want to pay to have them rebuilt; since those require the old browsers to stick around, the new apps will still have to run on the old browsers.

I only was able to stop supporting IE7 this year :-P The only thing that has forced some of our customers to upgrade has been a year of successive SSL exploits that have rendered old browsers/OS insecure.

I wasn't holding it as example of current web development. I was holding it as a sample of web development that happened semi recently. It is also why web dev can be a nightmare - Legacy systems and browser incompatibility.

It's great if you never had to deal with them, but that doesn't mean it won't happen.

Note: It wasn't a one-off job either. There were multiple jobs, government sector.

I never said it didn't happen, I dealt with IE4 and Netscape (briefly), and that you mention "government center" is exactly the area I knew you were talking about.

As of today, you are right. However, we should be aiming towards a future where amateurs don't have to worry about browser incompatibilities. Coding time to be focused on building the product and its features, not juggling css rules to make it look the same across browsers.

> And any web site that doesn't work cross browser is by amateurs at best.

Good luck arguing with customers that will only pay when you achieve pixel perfect layouts across all browsers.

Or are able to replicate certain UI behaviors from native platforms.

Doing native stuff again, and I don't miss this type of arguments.

>that data goes into the html It's more like static content goes into the html, dynamic content goes into JSON.

Hmm... I don't see any conceptual reason why separating those things should require completely different languages, though.

Nobody bats an eye when you use Python for logic, sql for querying your database and regex for searching text. Unlike the front end, there are ample opportunities for "uniting" the backend in one language, yet nobody really seems to bother.

I speculate that it's because these languages are better at certain things, just like having a non-executable language for data, helps keep the data, data only (cue angry lispers), and facilitates easier writing of prose in a mark-up language than a real programming language could facilitate. Just look at markdown.

More over, we invented JSON, rather than just sending JS files between browser and server.

> Nobody really seems to bother

I prefer writing queries using Django's ORM even though it is underpowered.

Yeah, I guess I as a little hyperbolic :)

React and jsx constructed dom using inline-styles brings the disparate technologies together in a composable way.

But without cascading, the whole point of css.

Although LaTeX needs much better error messages.

As a very busy CSSWG member... I agree. There are a number of benefits to the current structure, but I highly suspect that if the web were invented today, styling would a JS-mediated aspect of the DOM, not something fully separate like it is today.