Re: [comment] XMLHttpRequest Object - Address Extensibility

On 4/22/06, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> That's why I added "for the first three implementations", and it is not
> really relevant what implementations do that do not support the vendor-
> specific extension. The original code also assumed you can catch the
> exception you might get when accessing obj.Foo, that's not correct in
> some less common implementations.

The point of the code was not to be correct or syntactically clean, it
was to present what inevitably will follow (and has followed) from the
lowest common denominator of developers who are just trying to make
their app work in a cross-browser environment.

> >I think it's a very good example of why VendorFoo is not an option, it
> >forces code like the previous to be created, ...
>
> You base this on the assumption that it might actually happen that some
> extension is implemented in the way described by the original code. This
> might happen, and some authors might want to cope with that, but it is
> not clear at all that this is something we need to optimize for.

In case you didn't pick up on it, that example was modeled largely
after the various |opacity| implementations. So this assumption isn't
a very far stretch, as it has already happened in the past.

The point is not optimizing for some obscure author's desire, it's
negating the need for the bloat in the first place. Mandating the
VendorFoo naming convention actually guarantees that there will be
code bloat to compensate for the various implementations of a single
feature. It's not as if the bloat is only temporary either, because
developers (and their managers) require apps to be
backwards-compatible with all reasonable browsers, some of which
inevitably will only support the .VendorFoo property rather than the
.foo property standardized three years later.

That said, I see this not as a case in need of additional
optimization, but a case requiring the removal of
specification-mandated bloat that is by no means temporary.

--
Brad Fults
NeatBox

Received on Sunday, 23 April 2006 18:08:52 UTC