There would have been more links in this post, but I’m too old for dangerous sweatshop blogging. Also, people get paid to do this?
The Mozilla Foundation is celebrating the ten year anniversary of AOL’s having released the Netscape Navigator source code and creating the foundation. Here’s the original press release. One thing I remember is that Slashdot broke the story of AOL releasing the code before it was announced — it was the first really big story Slashdot broke. (In fact, I think I learned of the existence of Slashdot when someone pointed me to the story there.)
Not long after the code was released, there was a big argument about whether Mozilla should dump the Netscape 4 HTML rendering engine and use a new, modern, standards compliant engine called NGLayout, or whether they should just get a release out the door built on the existing code. Back in October of 1998, I wrote a scathing piece insulting the Web Standards Project for lobbying the Mozilla folks to move to NGLayout, which I’ve quoted in full below. (This was in my pre-blog days when I was more an essayist.) The Mozilla Foundation rewarded me for defending them so ardently by announcing that they were adopting NGLayout just a month later.
“I Want My NGLayout!”
October 5, 1998
As regular Outraged! readers already know, this writer is generally dissatisfied with the so-called standards process in the computer industry. Standards which are written before working code is created are more often than not doomed to failure, standing instead as filthy monuments to the capriciousness and excess energy of companies with time and money to burn.
One particular showpiece of the standards process is the current state of HTML, as implemented by the world’s two most popular browsers, Netscape and Internet Explorer. They both comply to varying degrees with the relevant standards (CSS1, CSS2, and DOM to the buzzword savvy), but neither browser maker has shown much initiative in the race for 100% standards compliance. This indicates two things; one, that writing browsers that comply with standards isn’t a high priority, and two, that it isn’t particularly easy (if implementing CSS and DOM were easy, both browsers would support them).
Anyway, some disgruntled Web developers have banded together to cajole Microsoft and Netscape into providing full standards compliance in their Web browsers, in order to further the Web as a platform for deploying applications, and to make the job of designing nice Web sites easier and less expensive. Anyone who has attempted to use the latest features in the Web browsers (generally mashed together under the misnomer DHTML) can attest to the fact that this is a worthy effort; the current state of standards compliance basically dictates that everything must be written twice (once for each browser).
Unfortunately, the members of the Web Standards Project, as this nascent group is called, have decided that their first axe to grind is with Netscape over which “rendering engine” will be included with version 5.0 of its browser. As most everyone who hasn’t been in a deep sleep for most of 1998 knows, Netscape released the source code to its browser back on March 31. Since then, even though Netscape has retained the prime caretaking role over the code, the browser has been open to public input, contributions, and scrutiny.
Thus, the public has gotten a rare inside look at the guts of the development process of an incredibly complex, popular application. Not long after the Mozilla project got underway, Netscape released the source code to NGLayout (which was, at the time, called Raptor). NGLayout is Netscape’s next generation rendering engine; it will provide tighter standards compliance and better performance than the current rendering engine, which is known as Mariner. Unfortunately, it is also significantly further from completion than Mariner, and hasn’t been integrated with the rest of the browser. Today, you can download a rough build of NGLayout which runs in a skeleton window and renders HTML extremely quickly during the brief period of time before it crashes.
Under ordinary circumstances, the public wouldn’t even know that NGLayout existed, and certainly wouldn’t know where its level of completion stands as compared to the Mariner engine, which is undergoing incremental improvements for the first public release of Mozilla. But, now that it’s part of the Mozilla project, people are free to view and toy with the source code, and compare it to what’s currently out there.
The Web Standards Project (WaSP) has started a petition to urge Netscape to forget about Mariner (the current rendering engine), and focus all of its energies on NGLayout, which is going to be much better than Mariner when it is completed. While this seems like a good idea, and I have no doubt that the WaSP means well, this effort betrays a baffling lack of understanding of the way the open source development model works, and poor choice of tactics.
First, let me talk about the sheer inanity of the very concept of the Internet petition. Perhaps, at one time, the online petition was a fine way to demonstrate that there was a groundswell of support behind an issue, but I firmly believe that day has passed. There are petitions for everything on the Internet; covering everything from television shows that get cancelled to the lack of a particular game for the Macintosh. News of various petitions spreads like wildfire, and since the cost of filling out a petition is nothing, people fill out petitions campaigning for issues that they scarcely care about. Unfortunately, because the level of effort required to circulate a petition online is so low, the petitions get no respect. Decision makers just aren’t interested in reading a report saying that 150,000 people want the latest version of QuickBooks to be ported to the Macintosh without knowing how many of them are willing to put their money where their mouth is.
The fact that Mozilla is an open source project only further dooms the WaSP petition to irrelevance. Even if the signatories of the petition have money to spend, it doesn’t matter, because Mozilla is totally and completely free. The blessing and the curse of the open source movement is that the areas of development are driven by the aims of the people who actually work on the projects. Mozilla will support Apple’s ColorSync because people at Apple felt it was worthwhile to contribute that code, not because somebody signed a petition saying they should do it.
The galling thing is that if the WaSP wants better standards support in Mozilla, they should be working to contribute to the Mozilla project directly, or to find some friends who can. The reason Mariner is slated to be part of Mozilla is that NGLayout doesn’t look like it will be ready in time to meet the project’s timetable. Does it really make sense to hold up the release of the first public version of Mozilla in order to appease a few puling Web developers?
Jeffery Zeldman, one of the leading members of the WaSP urges Netscape to “do the right thing,” but I’m forced to wonder if he even really knows what that is. What he and the other members of the WaSP seem to be saying is, “do the right thing for us.” Dan Shafer, pundit at large for CNet’s Builder.com, lays down an ultimatum, “Netscape must not ship a 5.0 browser without NGLayout.” He further urges them to pull out all the stops and commit its entire engineering resource to this effort.
What he, and the other folks behind this petition, fail to realize is that they are part of Netscape’s engineering resource. The success or failure of Mozilla depends on the Internet community at large as much as it does on Netscape. If they, or others, want Mozilla to have a particular feature, or look a certain way, or run on a certain platform, then they’re as empowered as anyone at Netscape to make it happen.
The source code is out there. The rest is up to you.
Microsoft’s Monday announcement of the new browser compatibility features in Internet Explorer 8 has set of a torrent of commentary. They described their new approach to markup versioning in an article at A List Apart and on the Internet Explorer blog.
The basic idea is that Internet Explorer 8 will enable you to specify which rendering engine you want IE to use in a meta tag on your page. So you can tell it your markup is IE7 compatible, IE8 compatible, or bleeding edge compatible, in which case it will use whatever the latest and greatest rendering engine is. We can assume that IE9 will retain all of those modes and include a new IE9 mode as well, assuming that Microsoft doesn’t decide it’s too much trouble to maintain all of the different rendering modes and toss some of them out by then. If you don’t include the special meta tag to turn on IE8 rendering mode, IE8 will default to using the IE7 rendering engine.
I appreciate that Microsoft is trying to solve a tough problem here — not breaking the sites of people who have included hacks for specific versions of Internet Explorer while at the same time giving themselves the opportunity to fix bugs and add new features in the browser. I don’t know if it’s an elegant solution, but it is a solution to that specific problem. What I wonder, though, is what this means for Web developers. I imagine the question most developers are asking is, “What’s the most sensible way to write markup, CSS, and JavaScript in the coming browser ecosystem?”
Sam Ruby points out that any DOCTYPE that’s unknown to IE will be rendered with the IE8 rendering engine. So if you want to bank on the improved standards support in IE and avoid using the new meta tag, just pick a DOCTYPE that is correct but that IE doesn’t do anything special with. I have a feeling that’s the approach most standards oriented Web developers will wind up taking.
Those developers whose depends on specific quirks of IE7 will be able to force IE8 to render pages in that mode, and developers who code to standards can pick a DOCTYPE that IE will use to render pages in its newest, most standards compliant mode. That strikes me as a pretty reasonable workaround for the meta tag business, which I don’t see any real need for anyone to use.
The other question I have is how the other browser makers will react. Firefox and Safari seem content to keep improving the standards support in their browsers without dithering over breakage of older pages, but their situation is different than Microsoft’s. For one thing, they have always been significantly more standards compliant than IE, so they don’t inflict severe breakage on people when they change. Secondly, people rarely include Safari and Firefox hacks on their pages. They code to the standards supported by Firefox and Safari, and then include whatever hacks they need to in order to make their pages look right in IE6 and IE7. The developers of WebKit are not going to be adopting the versioned rendering engines approach IE is taking, and really there’s no reason to do so. I expect the Mozilla folks will say the same thing.
The specific bit of good news here is that it should free developers from adding yet one more browser-specific style sheet for IE8. Lots of people these days are using hackish workarounds to make sure their pages look right in both IE6 and IE7. When IE8 is released, you won’t have to do anything to make sure your IE7-specific code doesn’t cause breakage, the way IE6 code did in IE7. And it looks like there is a path to using the latest and greatest features without any of this meta tag foolishness. So I think it’s going to be alright.
There is a whole lot more on this topic just about everywhere, so much so that I’m going to punt on linking to all of the reaction. You’ve probably read it all anyway.
© 2024 rc3.org
Theme by Anders Noren — Up ↑
Apple and Safari for Windows
Apple has backed off on pushing Safari for Windows out to iTunes users as a software update and now more accurately lists it as “new software“. What I find interesting about Apple’s sudden eagerness to get Windows users to install Safari is that it shows they’re significantly more committed to it as a product than I would have originally guessed. My original speculation when Safari for Windows released was that Apple was making it available so that Web developers who use Windows would have no excuse for not testing their sites in Safari, and more importantly, Mobile Safari. Now it looks like Apple feels like Safari has legs and that they want to get into the browser fight on Windows.
I think Apple could stand to improve their conduct a bit in terms of how they push out the software, but I welcome the additional competition in the browser market. It feels like Safari more than any other browser is pushing the state of the art forward in terms of standards compliance.