- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sat, 22 Apr 2006 13:53:33 +0200
- To: "Jim Ley" <jim@jibbering.com>
- Cc: "Web APIs WG \(public\)" <public-webapi@w3.org>
* Jim Ley wrote: >"Bjoern Hoehrmann" <derhoermi@gmx.net> >> I have no idea what the code is supposed to do and what constraints >> there are. It is not clear, for example, why you cannot just use e.g. >> >> obj.MozFoo = obj.WebkitFoo = obj.OperaFoo = 0.7; > >Such code would throw a run time error in certain IE6 installations, and >other less common UAs, assuming obj is a DOM object or even more often in >certain other types of host objects. 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. >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. Clever vendors might put the extension on some fast standards track and use the standards organizations VendorName instead of their own, so the problem does not arise even with the proposed model. As an example, the WCSS CSS extension "-wap-accesskey" is supported by multiple vendors, even though it follows the -vendor-name scheme. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Saturday, 22 April 2006 11:53:37 UTC