MozillaZine

Tree Closes For 0.9.8

Wednesday January 16th, 2002

Mozilla.org has closed the tree to approved checkins only, starting as of 12am Wednesday, and will do so until 0.9.8 has branched. 0.9.8 will have a variety of new items including new natively drawn widgets on WindowsXP, Mac OS X, and GTK, when you are in the classic skin (We will have more on this later, including screenshots); the addressbook was rewritten, and now supports printing, a new "Get Map" button allowing you to query for a map based on a card address, and other stability fixes; Windows MAPI support; and a huge amount of performance and stability work.

Many believe this is one of the last milestones prior to 1.0, and that Mozilla.org will actually have 1.0 following 0.9.9. 0.9.8 should branch sometime next week, with a release two Mondays from now. We'll keep you updated on both the branching and the release.


#61 Re: In straussís defense

by strauss

Friday January 18th, 2002 7:33 AM

You are replying to this message

Thanks for your note. There are two important changes that I've been discussing.

One is a change in argument. For the last few years, the big argument against native widgets has been that there were supposedly important CSS attributes that were difficult or impossible to apply to native widgets. If you look at the CSS specs, though, it doesn't appear that any of these are mandatory attributes for form controls, and in fact it appears that CSS3 actually requires the use of system default appearances for form controls, as one would expect given the importance of platform standards in user interface design. I've been arguing this issue without getting much of anywhere since 2000, but suddenly, without any public discussion, the Mozilla project as a matter of policy has turned around and decided that in fact the extra CSS attributes are not important, while platform default appearances are. For people who follow CSS and related issues I think it's important to note how this argument wound up coming out, rather than sweeping the issue under the carpet as an embarassing about-face.

The other change is technical, although it also has significant consequences for the user. There has been a fundamental architectural shift in the XUL widget model. The previous model was that widgets were described in an HTML-like form stored in user-selected repositories that allowed for a variable interface. At runtime, when a widget was created, the XUL layer would go to the user-selected file, pull out the variable HTML-like representation of the widget, and render the widget from that representation. Now, at least when using native widgets, the HTML-like representations in the user-selectable files are ignored in favor of native OS widget-drawing calls. This is a basic architectural shift in XUL, and again it's something that is important to note for people who follow XUL, as well as people who follow the features of theming and skinning of which so much has been made by Mozilla advocates. The scope of theming and skinning is now considerably reduced, given that most users prefer the platform standard appearance.

My attempts to point out these two important changes have been met by the usual chorus of personal attacks against me, and by vague claims that I am committing some error which somehow cannot be pinpointed. II don't think it bodes well for the project that the level of argument continues to be so low.

Lee Strauss