- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 15 Jul 2007 21:45:09 +0300
- To: Jon Barnett <jonbarnett@gmail.com>
- Cc: "Doug Schepers" <doug@schepers.cc>, "public-html@w3.org" <public-html@w3.org>
On Jul 15, 2007, at 20:40, Jon Barnett wrote: > Hixie pointed out that you can detect support for certain features > using Javascript [1], such as writing PING as uppercase in the DOM, > and then checking the HTMLAnchorElement.ping property (lowercase). I > suspect the same logic can apply to new input/@type values - use > <input type="date">, and then check the HTMLInputElement.type property > for either "date" or "text". This is the best way because the test for the existence of the implementation involves testing the implementation itself. > But a unified method would be nice. Such as a > DOMImplementation.rendersElementNS(strNS, strElementName) function, > and a complementary .rendersAttribute function? > > Either that, or an enormous number of hasFeature strings... These are problematic, because the claim of support is detached from the actual support. It isn't feasible to subdivide features down so that each minute subfeature had its own string. Browsers will likely claim that they support a feature even when the support is not full. OTOH, an implementation may indeed support something but have a bug in the hasFeature impl. Given that hasFeature can be wrong accidentally or deliberately, I think we shouldn't add more feature strings and we should encourage script authors to poke the actual features to see if they are there. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Sunday, 15 July 2007 18:45:28 UTC