MozillaZine

Downloadable Chrome Spec Updated

Thursday April 8th, 1999

David Hyatt has updated the downloadable chrome spec.

The spec reflects functionality as of M4. Of importance to web application developers is the new information on altering chrome via signed javascript. This could allow for adding and subtracting, disabling and enabling of buttons in the application's toolbar. This can allow the application toolbar too keep in synch with the content in the browser window.

Revisions have been made to the spec, so please check it out.


#7 Re:Downloadable Chrome Spec Updated

by mozineAdmin

Thursday April 8th, 1999 10:26 PM

You are replying to this message

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?