A clean break from the past was tried once already: XHTML 2.0. It failed.

We absolutely plan to (and are!) working on new standards that enable greater efficiency and developer productivity. I don't like the fact that floats are used for layout any more than anyone does, not the least because it makes it hard to parallelize. But at the end of the day we're building a browser, not a from-scratch app platform.

It failed for a number of reasons - timing, lack of compelling new features, IE's lack of support for application/xhtml+xml, Gecko's Yellow Screen of Death, etc. I'm not sure that you can blame any one of them. And it really wasn't a clean break in the sense that whyme is talking about.

I'm pretty sure it failed due to not being backwards compatible. Sometimes you can throw stuff away if it isn't getting much use, but backwards compatibility is too important in the real world.

If your browser won't browse the Web, consumers simply won't use it.

XHTML 2.0 was not a worthy successor. Apologies if my hatred for the current technology is coming through, but hey... At least I'm being honest.

He didn't mention XHTML. He seems to be talking about an entirely new layout language, which is nutty, but not as crazy as XHTML, which was "let's make everything way more complicated for the sake of ideological purity, but not add any new features"

"rebuilding the entire world wide web" is one of the few projects that I'd imagine is _more_ difficult than "write a new web browser from scratch."

Well the sooner we start the better. ;)

Why?

What's the pain point here, beyond just wanting to reinvent a round-enough wheel?

It's not a case of the wheel needing to be round enough. The wheel is old and has not been able to keep pace. We have many people walking aside the wagon repairing the wheel at every turn. Those people are the current browsers. The wagon is the current technology and the people going along for the ride can see just how painful this is.

Anyone who has attempted to implement trivial things, like thematic scrollbars or cross-browser capable code, or dealt with dom thrashing via JavaScript, knows the amount of effort going in (or knowledge required) to do trivial things is ridiculous; considering how long we've been travelling down this road. Why are we still using a wagon? And why do we want to build more of them running in parallel?

>Anyone who has attempted to implement trivial things, like thematic scrollbars or cross-browser capable code, or dealt with dom thrashing via JavaScript, knows the amount of effort going in (or knowledge required) to do trivial things is ridiculous

That's true, but that's maybe for the better?

In the sense that it leaves a place for desktop and native apps to thrive too.

I would worry if the browsers was a great execution environment, that could even run Photoshop or Valve or Pro Tools, and every company went that route.

It would mean total loss of data freedom (they would push you to have them in the "cloud"), and a rent-model for software purchases, with software being able to completely change under your feet (like Gmail did for example).

What's the superior alternative? (serious question)

In spite of the firmly stated opinion I left elsewhere in this thread, I do indulge in imagining how all this tech stack could be better.

First things first, I found out the other day that someone actually built the major part of my vision: Constraints Oriented stylesheets (using cassowary).

http://gridstylesheets.org/

This is how iOS now handles layout. It makes easy things easy, and hard things achievable. Exactly what you'd want.

Beyond this, I think that html has too many tags. To put another way, the browser should not generally permit <script> and <style> to exist in the same context that <em> can exist. onblah= attributes were a terrible mistake that we'll never be able to undo. It would be cool if there was something like a <content> tag which, within it, only permits content oriented mark up, while disabling scripting and styling tags. Likewise, forms, scripting, meta tags and linkages should be in isolated contexts.

And finally, what idiot decided that & ampersands should have a prominent position in many URLS and then use & for entity encoding in html, a completely different purpose. URLS now have to be http://entity&amp;encoded

uhg. so stupid. what would be wrong with <amp> or <amp/> instead? or since we've freed up & for normal expected use, <gt> <lt> and <quot>

ah well.

> ...what idiot decided that ampersands...

    example.com/?a=1&b=2
    vs.
    example.com/?a=1;b=2

The second example doesn't need to be encoded in HTML.

https://stackoverflow.com/questions/3481664/semicolon-as-url...

And that would be great if it didn't inadvertently break certain browsers, proxies, web servers and parameter parsers. Back in the day the advice was you could use & or ;. TBL had subtly different semantics in mind for them though: apparently ; was meant to represent some coordinates in some spacial system while & was the normal query parameter separator.

Somewhere along the line, for some reason, everyone settled on & and the web ossified around the assumption that was the only character that ever gets used.

The worst part about ampersands in URLs is that not only you have to escape them but so few people know that you need to escape it!

How paralelizable would Cassowary be? It seems it adds a lot of inter-dependencies between elements, no?

I don't know the algorithm well enough to say for certain. but I get the impression it involves a clever work around to the interdependencies. it converts equalities and inequalities into a system of linear equations. It then converts this system into a matrix form it calls a "tableau". The solver appears to work by repeated applications of matrix operations which may be paralelizable. but I'm not sure. This is different from how physics engines resolve constraints, one after another. In a matrix form they just kind of all get optimised "at once"

the paper describing the algorithm is here:

https://docs.google.com/viewer?url=http://www.cs.washington....

At a really high level...

Create an entirely different model. One that acts as a hybrid between a full blown inefficient co-ordinate system and, plausibly, a more efficient box model.

We could start by modelling 'movement' which equates to objects having 1. A reference point, 2. A magnitude and 3. A direction.

It would be beneficial to do this in such a way that one could apply functions to said model achieving a reactive design that gives you a sense of a full blown co-ordinate system while achieving simpler mechanisms for ease in development and efficiency.

I know that's pretty high level stuff, but in my mind I can see a fairly clear path to achieve a significant improvement.

Cool, that sounds interesting. I certainly think it's worth experimenting with stuff like that in parallel to projects like Servo which optimize current standards, long-term it's hard to tell which will be better.

You won't displace entrenched technology with an entirely different model, no matter how good. Sorry, this is just a pipe dream.

The real competition for the web are the walled gardens of iOS and Android App development.

If iOS or android app development succeed, then you would be proving yourself wrong as they would be displacing the entrenched technology. It's that, or they are not real competition.

I have no pipe dreams. Displacing the aforementioned technologies with something better is inevitable. I just gave an example of how easy better ideas are to be found.

I always wonder what it would be like if the browser was just a thin virtual machine, something like Java had hoped to become, and then you could specify the components you wanted to run on top of that. If, for example, you are serving an HTML document, you could point the browser to also download the WebKit renderer, or whatever. If you're building something more akin to an application, you might use some other framework to host your application.

That's certainly been discussed many times. It's an interesting concept. The main downside though is that if each site has its own renderer, with no shared concepts like the current web has, then you lose out on things like easily making accessibility tools, web scraping, etc. etc.

The benefits are also clear though, basically not being limited to current standards.

People have been parroting this nonsense for years. You have WebGL etc in the browser now. Web "pages" aren't pages anymore, and there is no way to enforce semantically meaningful markup. All that's been accomplished by fighting against the future is to ensure that all these low level services were implemented poorly. You can have all your high-level, common concepts but they need to be built onto a layered system. What we have now is a laughable mess, and it proves that the browser vendors have no idea what they're doing.

Of course then Google would have you download Webkit as a renderer and NaCl as an execution environment. Which would be only available on the latest version of your OS.

And Apple would shove some Obj-C renderer down your device, only this would support only iOS, MacOS and Windows, not Android and certainly not Linux.

FOSS-Shops would transmit only a repackaged build system which then would start downloading source packages and start compiling them in your browser. 3min later and you could actually start using the application.

I really fail to see the advantage here.

I don't think that he knows. No one does. But that does not mean that it isn't something that should be discussed.

Well, of course, I don't think any reasonable person would say it shouldn't be discussed.

I was just hoping there was some interesting project already underway I could read about.

Something like XAML?

Man it's so much much better then crap-tml! I can layout anything flexibly and reliably in like 5 minutes.