People would certainly do namespacing hacks, but that doesn’t bother me much. If you’re using “namespacing hacks,” then you’re well aware of the fact that you’re doing so at your own risk. To me, anything that is prefixed by -renderingengine is a “use me at your own peril” sort of thing. It’s a red flag to the developer that these things may still be “beta,” so to speak, and if you use them for a production site, you do so at your own risk. The important thing is that they’re there for designers and developers to play with, provide feedback on, and learn about.

Yeah, but CSS3 isn’t even a nailed down draft yet, is it? I sort of understand eschewing some of that pure awesome when it is picked up too soon. Then again, validation isn’t the end all be all of a working site. Plenty of sites function just fine without being valid.

That’s not to say that validation should be ignored. We know the nightmare that ensues when people don’t used some sort of touchstone for comparison.

As a side note, I’ve seen Zeldman (the man, not the “image” of Standardistas) be less of a zealot in some areas than the stereotypical standards nazi. So, I think the guy might appreciate a little, be it ever so slight, disassociation with that image.

I think it’s more an allusion to Standardistas in general, eschewing some of the new shiny hotness in CSS3 and/or what the Webkit and Gecko teams are building into their builds because they might cause a validation error.

Why reward users using a 5 year old browser with an “identical cross-platform” degraded experience and punish those using a modern one that can support the shiny new hotness?

For how long do we let Internet Explorer hold us back? Does anyone honestly think IE8 is going to magically offer full support for current standards?

Agreed: the namespacing isn’t hurting anyone.

Yet, people balk at conditional comments for implementing CSS now, so how long do you think it would take before people complain about what would eventually be called “namespacing hacks” in the CSS files?

Just thinking out loud on that aspect, really.

Bridget: To me, the namespacing we have now solves this problem. The WebKit team has been adding new features left and right, and it’s not hurting anyone, because they’re doing it in their own namespace, and not moving it in into the public namespace until it’s a standard (or at least so widely implemented that it’s a de facto standard).

I can’t take the credit for the core browser engine idea. I read a comment on Andy Clarke’s blog where Mike Loizides brought up the idea. I’m merely putting out feelers to see if it is feasible or reasonable as a solution.

I originally thought the same as Jeff — that it might not be practical. However, the more I read from the vocal web community, the more I question that it may be a solution for us all.

Jeff, you said:
>Hopefully you understand that neither myself nor Alex are suggesting we abandon standards and let all browser makers do their own thing.

I would certainly hope not, but having the browsers competing to provide the new and shiny you want, tends to cause that kind of drift, don’t you think? Isn’t that why sites were being built to accommodate Netscape and/or IE? Their versions of the shiny didn’t play nice together. I’m not so certain it would be any different this time.

To Alex’s point about Amaya failing miserably, I’m not at all familiar with Amaya but will read up on it to be better informed. A product that abandons real world usability is certainly not something I would favor. I hope that much remains clear in any commentary I might make.

I would like to understand one comment that Alex made in his article. Exactly how does Zeldman hurt me? I just don’t see it.

So one of the things I was tempted to cover in my original post was some mention of how standards bodies can effectively shorten the time between deploy and standardize. WHATWG has gone one route (BDFL, short iterations, deep implementer involvement) and the EcmaScript 4 working group has gone another (baseline reference implementation maintained by the WG). The ES4 WG example is perhaps most similar to what you’re proposing and I do have some hope that it’ll work.

The idea of a single core browsing engine is also interesting from the perspective of economics. Browser vendors make what money they get from chrome and search engine integration, leaving renderer development as a “loss leader” to hopefully entice users and organizations to switch (or at least not run screaming for the hills). One can imagine the browser vendors aren’t keen to keep re-running this race for every new set of features either. Your idea might have legs.

One thing I’m not clear on yet is how such an arrangement (particularly if it happens at W3C) would end up in a state any different than Amaya (http://www.w3.org/Amaya/). Since Amaya’s first and only loyalty is to W3C specs and not to the real web, it fails miserably at enough real-world tasks that it wouldn’t ever for the basis of a real product. Without competition, it’s unclear to me what force would provide the strong impetus to improve the renderer over the long haul. Giving maintenance responsibility to the W3C seems like a fast path to a tragedy of the commons.

That said, if a way can be found to encourage healthy competition and improvement, a single renderer could indeed get us out of the sticky spot we’re in (at least in the short term).

Regards