One thing about creating new features for a product such a
browser is the features they are almost always designed and
implemented in such a way that is convenient for the
creator of a product but not for anyone else (this isn't intentionally done though). The proprietary
features of browsers are designed to fit the architecture
of the browser so that they can implemented as quickly and
easily as possible. They don't go through months of years
of iteration like standards do.
If you look closely at some of the documentation of CSS or
scripting features of browsers, you will find numerous design
decisions that seem odd. This is not because the designers
were stupid, but because architectural issues prevented the
designers from creating something more sensible.
The IE documentation refers to numerous
that really seem to be only there because some part of its
architecture requires it. No other browser would have a need
for such features. IE's way of displaying unstyled XML as
a 'fancy tree' was fine for it, but since Mozilla can render
styled XML directly, that feature took some time to work out how best to implement it, without breaking XML that was supposed to be displayed styled.
Some people have complained that with XBL, one has to add
various tags to describe properties and methods, rather
than just using a script file with functions in it. While
that may seem easier for the XBL author, there may be
implementation details that make it harder to handle. What
I mean is that given a specific browser architecture, it's
possible that a separate script would be difficult for the
browser implementor to deal with.
A good example would be the innerHTML property of elements.
While this may seem like a convenient way to change the
content, it adds a dependency of an HTML parser to the DOM
module. And not only an HTML parser, but one that can parse
a fragment, not just a document. While this may not seem
like such a concern for a browser, it today's world of
componentized systems, there may be a product which has
licensed a pre-built HTML or XML parser, or may be using a
standard parsing library. Since many languages often include
an HTML or XML parsing module, developers would tend to just
use that. Since the developer doesn't necessarily have the
option of changing the parser, if it doesn't provide any
hook to handle the innerHTML property, it really isn't
possible to include such as feature.
So, don't assume that a feature found in one product is
necessarily implementable in another. The standards go
through several iterations with comments from many people or groups, in
order to ensure that they are the most implementable in
the most cases. Propreitary features don't.