HTML works well enough for its purpose, but its SGML heritage makes it awkward to read and write; it is implemented inconsistently and sometimes clumsily, with countless edge cases where each browser pivots a different way; and it changes far too slowly to live up to our demands.
CSS is worse: it is simply unsuited for layout. Don’t believe me? Without looking anything up, design a three-column layout where all columns have equal height even when their contents are unequal. There’s a reason this layout was called “The Holy Grail”.
It isn't baffling that "open web" technologies lack this kind of programmer-facing openness. That's a result of the browser wars, the underlying implementation, the original design concerns, the limitations of the early internet, and umpteen other factors both human and technological.
> Without looking anything up, design a three-column layout where all columns have equal height even when their contents are unequal.
I can see your point, but this particularly is not that hard: http://jsfiddle.net/fbJ6J/. I know, I know, but it does comply with your requirements. =)
"What would it mean to be able to subclass an HTML Element?"
"The network is our bottleneck and markup is our lingua-franca. To deny these facts is to design for failure. Because the network is our bottleneck, there is incredible power in growing the platform to cover our common use cases. To the extent possible, we should attempt to grow the platform through markup first, as that provides the most value to the most authors and provides a coherent way to describe behavior to JS.
As markup begets JS objects via a parser. DOM, therefore, is merely the largest built-in JS library.
Any place where you cannot draw a line from browser-provided behavior from a tag to the JS API which describes it is magical. The job of Web API designers is first to introduce new power through markup and second to banish magic, replacing it with understanding. There may continue to be things which exist outside of our understanding, but that is a challenge to be met by cataloging and describing them in our language, not an excuse for why we cannot or should not."
And then finally sum it up with this quote:
"It is high time we started designing low-level stuff for the web in idiomatic JS …"
There's some fantastic discussion in the comments there, too.
Still waiting for someone to invent the thing that lets you write server-side code and client-side code in the same language in the same file, and magically handles the execution of what where (and the secure transmission of stuff between the two) on the server.
I can imagine something like Parse where in addition to sending them data and stuff to store, you can send them a block of code to run on the server. They would of course cache compiled versions of those blocks for speed, but the idea of blocks (as in Obj-C) is an attractive one.
I'm not sure that it lets you share code between sever and client entirely seamlessly (it might--I honestly don't know), but it has another advantage: it lets you share objects between different clients seamlessly.
I would be very pleased to hear from people who would be interested in such a language - what features they will want from it.
As it turns out, layout and abstraction, as they relate to user interfaces, are two fairly difficult problems. I can say with some degree of confidence that current web standards kind of suck at both of these (I mean, they do an "ok" job, but could be far improved and simplified). This is not entirely anyone's fault (obviously), but rather something inherent to standards. Rather than design a fresh, sensible system, we have been using 20+ year-old standards because...they are the standard.
The first thing I would change? The web is no longer just a series of documents, and needs to be treated like a networked application. HTML and CSS should both die, and there should be only one language that dictates the behavior of a given web page (which can easily call other appropriately sandboxed languages). There is a little bit too much black magic - everything should be transparent. Really, the web browser should be the operating system, not the other way around. Everything a web browser does is beginning to look like an OS (tabs are threaded applications, etc). It seems detrimental to design to force applications to appear inside another application (even if there is a fullscreen ability).
Just my $0.02 ...
I agree with what he is actually saying. However, I am not that excited about building UIs with XML anymore though. I think we should have components that you can edit and layout with graphical designers.
In other words, design the entire platform from the point of view of web developers, not browser developers.
I don't know how you can gradually introduce this, though. Maybe a new doctype? UI toolkits for <canvas>?