knowing what and when to feature test
in [JavaScript]
|
Prev: FAQ Topic - How do I make a suggestion? (2010-01-17)
Next: Passing primitive variables by reference in JavaScript
From: David Mark on 20 Jan 2010 08:27 On Jan 18, 1:26 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Thomas 'PointedEars' Lahn wrote: > > Garrett Smith wrote: > > >> In your case, document.body might be undefined in an XHTML DOM. > > > Where and under which circumstances? Are you considering that the W3C DOM > > Level 2 HTML Specification applies to XHTML 1.0 as well? > > It was an old "bug" of mozilla where document.body was undefined. That > got fixed around 2003. > > > IMHO, it is rather unlikely that, since the same parser and layout engine > > would be used as for XHTML 1.0 (when served declared as > > application/xhtml+xml or another triggering media type), `document.body' > > would not be available in XHTML (Basic) 1.1. Especially as XHTML (Basic) > > 1.1 defined the `body' element in the required Structure Module that all > > XHTML 1.1-compliant user agents MUST support. > > There is "WICD Mobile 1.0" that suggests a subset of HTML DOM for mobile > devices. That subset does not include a body property. > > Seems to have stopped at CR phase in 2007.http://www.w3.org/TR/WICDMobile/#dom > > http://www.w3.org/TR/WICDMobile/#dom-html-ref > | interface HTMLDocument : Document { > | NodeList getElementsByName(in DOMString elementName); > | }; > > I don't know what the rationale is for omitting document.body, nor do I > know which implementations actually do that. Anyone who is able to fix > that, please do. What does it matter? Just use a wrapper that tries document.body first, then gEBTN, etc. You need it for some browsers and parse modes (e.g. XML). Return null if all fails. Substitute a simpler wrapper when the context allows:- function getBodyElement(doc) { return (doc || document).body; } var body = getBodyElement(); if (body) { // Needs a reference to BODY to work ... }
From: John G Harris on 20 Jan 2010 10:40 On Wed, 20 Jan 2010 at 13:49:01, in comp.lang.javascript, Thomas 'PointedEars' Lahn wrote: <snip> >Nonsense. The HTML standard makes recommendations as to how parsers are >supposed to handle invalid markup. But again, it is not wise to rely on >that as those are only recommendations. <snip> Which HTML standard is that ? The current standard makes no such recommendations. John -- John Harris
From: Thomas 'PointedEars' Lahn on 20 Jan 2010 11:34 John G Harris wrote: > Thomas 'PointedEars' Lahn wrote: >> Nonsense. The HTML standard makes recommendations as to how parsers are >> supposed to handle invalid markup. But again, it is not wise to rely on >> that as those are only recommendations. > > Which HTML standard is that ? The current standard makes no such > recommendations. You are mistaken: <http://www.w3.org/TR/html4/appendix/notes.html#h-B.1> PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Hans-Georg Michna on 20 Jan 2010 14:35 On Wed, 20 Jan 2010 13:49:01 +0100, Thomas 'PointedEars' Lahn wrote: >... There is _nothing_ that says XHR must not be used for `file:'. >One should be aware, though, that certain conditions must apply for this >to work. For example, in MSXML it requires the use of ActiveXObject(). I had wanted to ask about that already. I keep reading that the particular problem here is only the XMLHttpRequest in Internet Explorer 7, which exists and works fine, but refuses to touch any URL that begins with "file:". If yes, then it would be one of the rare examples where browser version sniffing is appropriate, as you cannot elegantly feature-test this. (Firing off an Ajax request just for the purpose of feature-testing is out of the question, I suppose.) What most people seem to do is cruder. They check the URL for the file: prefix and the browser for the presence of MSXML, and if both are present, they use MSXML even in browsers where XMLHttpRequest is perfectly usable, like in Internet Explorer 8. Do I see things correctly? The example below is an example for the crude method without browser sniffing. Hans-Georg // Constructor for universal XMLHttpRequest: function XHR() { // For support of IE before version 6 add "Msxml2.XMLHTTP": var modes = ["Msxml2.XMLHTTP.6.0", "Msxml2.XMLHTTP.3.0"]; // If working with the local file system, try Msxml2 // first, because IE7 also has an XMLHttpRequest, // which, however, fails with the local file system: if (location.protocol === "file:" && ActiveXObject) for (var i = 0; i < modes.length; i++) try { return new ActiveXObject(modes[i]); } catch (ignore) {} else if (XMLHttpRequest) return new XMLHttpRequest(); else for (var i = 0; i < modes.length; i++) try { return new ActiveXObject(modes[i]); } catch (ignore) {} return; }
From: David Mark on 20 Jan 2010 15:00
On Jan 20, 2:35 pm, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > On Wed, 20 Jan 2010 13:49:01 +0100, Thomas 'PointedEars' Lahn > wrote: > > >... There is _nothing_ that says XHR must not be used for `file:'. > >One should be aware, though, that certain conditions must apply for this > >to work. For example, in MSXML it requires the use of ActiveXObject(). > > I had wanted to ask about that already. I keep reading that the > particular problem here is only the XMLHttpRequest in Internet > Explorer 7, which exists and works fine, but refuses to touch > any URL that begins with "file:". Right. > > If yes, then it would be one of the rare examples where browser > version sniffing is appropriate, as you cannot elegantly > feature-test this. (Firing off an Ajax request just for the > purpose of feature-testing is out of the question, I suppose.) Not version sniffing, but an object inference is in order. As we know that all ActiveX versions support file:, we can support file: if we can create an ActiveX XHR object. See createXmlHttpRequest in My Library. > > What most people seem to do is cruder. They check the URL for > the file: prefix and the browser for the presence of MSXML, and > if both are present, they use MSXML even in browsers where > XMLHttpRequest is perfectly usable, like in Internet Explorer 8. They do what? > > Do I see things correctly? The example below is an example for > the crude method without browser sniffing. Not exactly. [...] > > // Constructor for universal XMLHttpRequest: > function XHR() { > // For support of IE before version 6 add "Msxml2.XMLHTTP": > var modes = ["Msxml2.XMLHTTP.6.0", "Msxml2.XMLHTTP.3.0"]; Oh, this is what you meant by MSXML. These are programmatic ID's for ActiveX components. You can be sure that XMLHttpRequest uses the same components behind the scenes. ;) > // If working with the local file system, try Msxml2 > // first, because IE7 also has an XMLHttpRequest, > // which, however, fails with the local file system: Right. > if (location.protocol === "file:" && ActiveXObject) Poor feature detection. Use isHostMethod or the like. > for (var i = 0; i < modes.length; i++) > try { > return new ActiveXObject(modes[i]); > } catch (ignore) {} > else if (XMLHttpRequest) return new XMLHttpRequest(); Same and missing try-catch (this constructor can be disabled by the user, just like ActiveXObject). I wonder if jQuery remembered to wrap that one too. :) > else for (var i = 0; i < modes.length; i++) > try { > return new ActiveXObject(modes[i]); > } catch (ignore) {} A bit redundant. :) > return; > I don't like that it runs these tests every time through, but the basic ideas are sound. Checking the UA string would be far more crude, not to mention disaster-prone. ;) |