I believe the argument is that Chrome's code-base is becoming the de-facto browser standard, which will allegedly simplify things by making a stable platform. B

I believe the argument is that Chrome's code-base is becoming the de-facto browser standard, which will allegedly simplify things by making a stable platform. But it's been hard to predict browser trends. Look how Chrome came out of nowhere and knocked Microsoft's off the top. Netscape also got sucker-punched. Who knows what will punch next. Web standards still have some glaring gaps that I'm not sure the current approach can tame. I propose "the web" be split into three standards: 1. Media/Games/Art/Video 2. Documents (existing HTML may be good enough with minor tweeks) 3. Productivity: CRUD and Data oriented interactive GUI By splitting, each standard can FOCUS on doing what it does best rather than the watered-down one-size-fits-all we have now. A given browser may support all 3, somewhat like how Java Applets and Flash could run inside of HTML documents. (They may be pluggins and/or independent browsers.) But unlike Applets & Flash, the standards wouldn't try to be full virtual OS's. Dump as much on the server as you can to keep client standards lean, and reduce the need for scripting by including common behaviors. For example, a common GUI idiom is for a button to activate a window or form. Rather than rely on scripting, that action could be built into the GUI markup: <button openTarget="myWindow"> Click to open My Window </button> Or maybe: <button label="Click to open My Window et. al."> <action> <setFocus target="myWindow"> <setFocus target="anotherWindow" modal="false"> </action> </button> The point is that if common GUI idioms and behaviors are built into the GUI markup standard, scripting (typically JavaScript) is not needed as often. The GUI Markup Language would be state-friendly and natively interactive, unlike HTML.