A more straightforward response would just be to call for HTML to be brought back under the control of the W3C. There are certainly merits to that, but at the same time a) W3C has its own obvious flaws as the overlord of HTML, b) no matter how benevolent a dictator W3C would or could be, even democratic (or quasi-semi-democratic) control is not the same thing as actual openness in the form of de facto (not just notional) forkability, and c) there's no easy and obvious way to get the yoke of W3C control back on the necks of the browser-vendor cartel, no matter how desirable it might be.
Regardless, one important first step is for people in general to have a clear-eyed view of what the present situation really is. One necessary part of that is for people to stop having a reflexive feel-good response to the 'Open Web' slogan.
Especially Håkon Wium Lie, who isn't even mentioned in this article, brings up some really convincing points against CSS Regions.
With Adobe's CSS Regions and other improvements [1] everyone could write an Google Docs competitor (single person mode) in one hour. Of course, Google and Microsoft with its Office Web fear this possible upcoming situation.
It would be awesome if some browser devs improve "contentEditable". It's really sad, there are so many bugs in Webkit and Firefox bugtrackers and got submitted related to this topic and no one fixed them. And no new features arrive either for years. Read some source code TinyMCE & co and you know what I mean, a lot of hacks to work around browser bugs.
What's weird is that even Microsoft IE10+ and Apple iOS 7 support CSS regions! And Chrome (and Opera Next) want even remove multi-column support, or at least fall back to a inferior bugg solution, wtf.
What I don't get that Mozilla proposed their own inferior solution. It's reminds me of Mozilla's movement against WebSQL, a very sad story for HTML5.
If I were Adobe I'd try to build a javascript-based solution for now, and push on the standards committees for the long term.
We have sufficient market share on the desktop that a few months from now, we will be in a position to unilaterally dictate them.
We hope to leverage this control to achieve the same dominance in mobile eventually."
—
"In practice, this allows us to call the project "open" while simultaneously ensuring Google will be the only effective contributor to the Chrome and Blink source now and in the future. We've had enormous success co-opting the language of open source in the past to imply our products are better, and we aim to continue with that strategy."
* Proxy all mobile connections through an html-simplifier
* Ignore inline elements like <strong> and <em>
* Remove the vertical part of the box model, and disallow any vertical positioning statements
* Simply serve raw html to the end user. In these days of semantic HTML5, users should be able to read it anyway.
By Håkon Wium Lie,the father of CSS, the CTO of Opera, and a pioneer advocate for web standards
Any claims that this will improve performance in the long-term are misguided: These kinds of layout features are necessary, so stripping them from the core (especially when other browsers are implementing them) will result in a nasty mix of browser-specific pages and low-performance javascript shims.
What evidence is there that it did not come at the expense of Google support for any proposed Web Platform features that Google could not efficiently implement?
