Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Bedrock

Excellent post. I agree wholeheartedly.

You might want to check out AngularJS. Although it would be nice to have these features baked into browsers and specs, Angular does a lot of what you describe, especially extending HTML.

First thanks for the monologues.

I'll grab on to one statement for my comment.

" every year we’re throwing more and more JS on top of the web"

The way things are going in my world, we are looking at replacing the web with JS, not simply layering. At a certain point you look at it all and say "why bother". Browsers render the DOM not markup. They parse markup. Just cut out the middle man and send out DOM - in the form of JS constructs.

The second part is to stop generating this markup which then must be parsed on a server at the other end of a slow and high latency prone communication channel. Instead send small compact instructions to the browser/client that tells it how to render and when to render. Later you send over the data, when it's needed.

So to dovetail into your statement, we really need more compact APIs that allow for highly descriptive yet compact instructions. Anything else will be just another layer on top of the web.

Servers should serve data, not markup or style. Clearly it has to come from somewhere but I'd like to see more built in shareable components as you've described where the end user gets a browser update or is prompted to update and then benefits across multiple sites.

Why shouldn't Jquery, Backbone, et al be bundled with the browser? They should be plugins not site specific downloads. More components can be built on top of those: templating, validation, media players, etc.

Let those components define the DOM through extension and overrides or expose such with an interface.

The more we can push to the client and share across the web, the less the networks bottleneck will impact end users.

In lieu of this we will serve up generic minimalist documents for the bots and use modular asynchronous JS for the users. Send as little as possible over the network and reuse it all wherever possible. Servers will serve data. The client will control the logic, manage the model and present the view and send back data when asked.

As I see it HTML, CSS, JS, SVG & Co are all part of the broad 'Assembly Language' for programming the web. CoffeeScript, LESS, SASS, Jade, etc. are all trying to do a good job in abstraction and boosting productivity.

Soon if you want to override the rendering of an element you can use 'CSS Canvas Drawing':

background: -webkit-canvas(awesomeRef);

And if you really want your own ABI-like freedom for enriching the browser you have the embed tag and the plugin-programming architecture. (e.g. Chrome Frame, Flash)

by Markus at
I feel the same way. I was in the process of writing "HTML6" (which is just a funny name) until another project of mine started to catch traction and had to slow down the process on this, but I'd love to hear what you think about it:

WIP, but close to done...: Code:

Hi Oscar:

I looked very quickly at your document, and I'm put off by the way it seems to invert the economic relationship, seemingly saying "HTML might be there, but the important stuff is what you invent". I don't think that's either the reality we have or the one we want. Prefixing/namespacing is a ghetto. Yes, you're going to need to prefix something to have extensibility, but should the shared and cheapest to invoke semantics be the ones that are in the ghetto? That feels wrong to me.

For what it's worth, I think the solution is simple. Just put all the stuff you're inventing behind a prefix and remove the "html:" from in front of all the tags you've put in the ghetto. We're doing this with Web Components by enforcing the rule that all extension elements must have an "x-" prefix in their tag names. At least then you know what's cheap and what's expensive. And it's not namespaces (long may they rest in peace).