The spec's posted at http://www.mozilla.org/xpfe/ConfigChromeSpec.html

The news item now reflects the proper URL for the spec.

I have persistent skins working in my tree! I'll be sure to check the code in when the tree opens after M4.

I'm hoping to see some Web sites out there that write fancy skin editor pages for switching skins.

Does anyone else think that this is just more proprietary crap? I may be in the minority here, but I'd rather have a Mozilla with complete html4/CSS1 NOW, rather than Mozilla with chrome later.

Ask yourselves, if MS had done this, would it be well accepted, or would it be rejected as an effort to balkanize the web while not supporting existing standards? Be honest.

To CPT -- by definition this is not proprietary. Proprietary implies hidden, while the source code to this feature is avalable to everyone. It may be considered commercial though.

Whether this is a good thing or not is another matter. It better be configurable (changing the behaviour of the button labeled back for instance would be bad).

Are you smokin' crack? Proprietary? Please read more about XPToolkit before you form any more opinions. This architecture is completely open. It's still under 'open development' It relies on open and accepted standards. Um.... It's a good thing. Trust me.

CPT,

I think you are making some assumptions about the code. The fact is that the UI is being built from scratch, and requires full-time developers (developers that are not working on the layout and rendering aspect of the code). Developers aren't being pulled from layout and rendering to work on UI. In fact, the UI needs those developers to continue their work. (see below for details)

HTML4 and CSS1 are being worked on by a large number of developers. However, they are useless without a UI to manage the browser. The UI development is starting from scratch, and they are building an open, cross-platform infrastructure that will save them time and effort in the long term.

What is interesting in this case, however, is that the UI is dependent on the *layout* code as well, because the rendering of the toolbars happens via the same engine that renders an HTML page. Consequently, the UI people also require a proper implementation of the HTML and CSS1 specs, because toolbar "skin" properties are defined via CSS. They also require a proper XML implementation, because toolbar hierarchies and and properties are defined via XUL (a XML compliant tag set). For example, moving the the XPat XML parser recently revealed well-formedness errors in the XUL (chrome definition files) that the previous parser didn't pick up. Without the proper parser to implement XML properly, these errors would have gone unnoticed.

The fact of the matter is, XUL and downloadable chrome are being incorporated for *the user's* benefit. The user will be able to define the look and feel for their browser that meets their needs. It sounds like what you're asking for is a generic browser that renders web-pages well, but doesn't take into account any competition in its market category. Why should they not compete? Why should they not work towards elegance, openness and usability in the UI?

The question of whether or not downloadable chrome is proprietary is beside the point. Since it has nothing to do with the rendering of the web page, Netscape could be the only utilizer and it wouldn't harm the state of standards compliance one bit. However, it's also a moot point, because the spec is open for any company to implement (and contribute to).

What do you mean "if MS had done this"? They already have. You can download a CNet version of IE, for example. And no one complains, because it's IE-specific functionality that doesn't affect the display of HTML. They're solution is terribly MS-centric, but that's to be expected.

Mozilla is just taking MS's ideas to their logical conclusion. They are opening up the UI so that the user can easily configure it (without fear of losing essential functions). They are making the spec open so that it is easy for designers to create new buttons and toolbars. And they are adding a "downloadable" and "scriptable" aspect to the UI, so that it can be used easily in web-based applications.

Your complaint seems to be the one that has been going around for years: "Why are Netscape and MS working on extra functionality when they aren't even compliant in any spec"? They do it because there's more to a browser than HTML display. In this case, they're doing it because they really have no choice. With the move to the new layout engine in November, they had to rebuild the UI from scratch. Should they do it wrong (native code and non-configurable) the first time, and fix it in the next iteration? Or should the work towards a UI that's both cross-platform and easily reconfigurable?

Yeah, well <BLINK> was open too, and I thought that was a bad idea as well, especially since <DIV> was working it's way through the standards process at the time. "Open" is the opposite of "closed", not "proprietary."

I'm not just bashing Mozilla, I am none too pleased with Microsoft for not compleating their standards support before moving on to other things. And I'm not the only one; check out this webmonkey article: http://www.hotwired.com/webmonkey/99/15/index1a_page5.html?tw=browsers

When Mozilla is released, I'll probably be pleased as punch with it, but untill then, I'll remember that Microsoft (of all companies) wore the white hat by supporting CSS in version 3. Although it sucked (especially toward background images) it was closer to the standards than <MULTICOL>.

Mozadmin:

That was a very illuminating response.

I didn't realize that the skins were actually part of the UI. I thought they were more like Kaleidoscope schemes that you find on the Macintosh platform; not really part of the system, just something laid on; just as real chrome isn't a car bumper in and of itself, but can be applied to a car bumper. It appears in this case, chrome IS the bumper.

CSS is so broken in IE3 that it would have been better to not even have the support at all.

em == px is all that has to be said.

Again to CPT --

If you look at the XUL files that describe the UI, you will see that they are much more than just skins. You can rearrange the elements as you please, and add new functionality via javascript snippets (which may make use of extra functionality exported via XPIDL interfaces).

I fail to see how this method of implementing the UI is worse than writing the complete UI once for each platform. This minimises the amount of platform specific code, which most people would consider a good thing (even if they didn't allow `downloadable chrome', I would consider this approach a good one).

David

Hi. Speaking of "Web sites out there that write fancy skin editor pages for switching skins," I think it would be a great idea to try to implement skin "morphing." Not morphing in the t2 fluid sense necessarily, but what about being able to change the skin of the CURRENT window on the fly as opposed to having to open a new browser window.

Possible/ pain in the ass/ what do you think?

floyd

This shouldn't be hard at all. IIRC, M3 already modifies part of the chrome to start and stop the throbber animation and to do the test security info thing. I can't see it being much (if any) harder to replace the whole chrome instead of just some.

Toolbar moving and hiding will also depend on dynamic chrome, as will all sorts of as-yet-unthought-of features.