W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: [comment] XMLHttpRequest Object - Address Extensibility

From: Brad Fults <bfults@gmail.com>
Date: Fri, 21 Apr 2006 20:12:01 -0700
Message-ID: <1959130b0604212012t23265cbepe32b9fa3ba9f239c@mail.gmail.com>
To: "Jim Ley" <jim@jibbering.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>

On 4/21/06, Jim Ley <jim@jibbering.com> wrote:
> This is very silly, the VendorMember scheme is entirely stupid, it's
> completely useless for authors, we can't do anything with it, and is much
> worse than simple invented terms that eventually get standardised.

Completely agreed. This is how we get ridiculous code like:

if (obj.MozFoo)
  obj.MozFoo = 0.7;
else if (obj.WebkitFoo)
  obj.WebkitFoo = 0.7;
else if (window.opera) // because Opera creates stubs for obj.*Foo
just to drive us insane
  obj.OperaFoo = 0.7
else
{
  try { obj.Foo = 70; } // ugh IE
  catch (e) { alert("No idea what's going on!"); }
}

> If vendor A creates a useful member, vendor B can't then copy the interface
> as they MUST prefix it with their Vendor string, when some WG eventually
> standardises it, authors now either have to ignore all existing clients and
> just support the standardised ones, or ignore the new clients - either way
> any UA that wants the code to run will have to support the silly old methods
> too (except they can't unless they're the member that invented it)

Agreed. Also, I think the "what if someone uses a good property name
for a lame implementation" isn't as much of a concern because we're
talking about major browser vendors, not any random paster.

> Extension requirements similar to ECMAScript would be a much more logical
> approach.

Seconded.

--
Brad Fults
NeatBox
Received on Saturday, 22 April 2006 03:12:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT