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: Garrett Smith on 18 Jan 2010 02:36 john wrote: > On 17 Jan 7:12 PM, Thomas 'PointedEars' Lahn wrote: >> john wrote: >> >>> Garrett Smith wrote: >>>> Object.prototype.hasOwnProperty fails in older browsers, such as Mac >>>> IE. >>>> >>>> The greatest divergence will be found in browser object models. >>> >>> could you recommend a reference for the browser object model? >> >> As a result of the diversity of possible runtime environments, there is >> _not_ *the* browser model. > > after my initial searching i thought that may be the case. > >>> i searched with google but didn't find anything that looked >>> authoritative. i read the following pages from the search results: >>> > >> > <http://javascript.about.com/od/browserobjectmodel/Browser_Object_Model.htm> > >> >> Without looking at it, that is probably not a good starting point. > > after looking at it it certainly didn't feel authoritative. so i suspect > your suspicions are correct. > >>> the MSDN article seems a bit sparse >> >> It is not just one article, is it? > > i can't say for sure. it was the only page from MSDN that showed up on > the first page of google search results. perhaps tomorrow i'll have more > time to explore that site and turn up meatier pages. > >>> and while thorough i'm not sure the accuracy of the about.com article. >>> are there others that would be worth reading? >> >> Yes. Read the FAQ. > > i did search the FAQ and FAQ Notes but didn't see any mention of > "browser object model" or "BOM". do you happen to know which section or > page discusses this topic? > >>>> Use w3c standards features an approaches first and do not expect >>>> non-standard behavior from them. >>> >>> understood. >> >> It is *really* bad advice, though. Instead, expect rather insane DOM >> implementations: do not rely on any return value; especially, do not rely >> on implementation assertions provided by the API (like >> DOMImplementation::hasFeature()), and avoid the Element::*Attribute*() >> methods where short-hand attribute properties suffice (we have discussed >> this at length recently, I am surprised Garrett does not seem to >> remember.) > > i misread Garrett's response to say "do not expect _standard_ behavior > from them". after even my basic testing i'm pretty much ready to expect > non-standard behavior in even seemingly simple cases. I meant what I wrote: Don't expect nonstandard behavior from standard properties. Code that is expecting XHR to work over file: protocol is expecting nonstandard behavior (though technically XHR itself is nonstandard, though it is a w3c WD). Code that is expecting assignment to DOM domstring properties to be converted to string is expecting nonstandard behavior. Code that is expecting typeof document.images == "object" is expecting nonstandard behavior. Code that uses malformed, nonconformant HTML is expecting nonstandard behavior. When the code doesn't do what is expected of it, then it is necessary to understand why. For DOM related issues, this usually boils down to looking closely at the code and looking closely to what the specs say should happen. Regarding XHR working draft explicitly states that protocol other than http and https is outside of the scope of the spec (or implementation-dependent). The code that is expecting XHR to work over file: protocol is expecting nonstandard behavior. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 18 Jan 2010 08:40 Garrett Smith 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. So no longer of any concern. Thanks. >> 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 You should know better than to cite Working Drafts as reference material. (How many times have I told you already?) PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Garrett Smith on 18 Jan 2010 11:19 Thomas 'PointedEars' Lahn wrote: > Garrett Smith 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. > > So no longer of any concern. Thanks. > >>> 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please read that again: "stopped at CR phase in 2007. "CR" Stands for "Candidate Recommendation". | Candidate Recommendation (CR) | A Candidate Recommendation is a document that W3C believes has been | widely reviewed and satisfies the Working Group's technical | requirements. W3C publishes a Candidate Recommendation to gather | implementation experience. A recommendation (REC) can be used as a normative reference. http://www.w3.org/2005/10/Process-20051014/tr.html#rec-track-doc >> http://www.w3.org/TR/WICDMobile/#dom > > You should know better than to cite Working Drafts as reference material. > (How many times have I told you already?) > If you look at the conclusion I wrote:- | 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. There is nothing proven here. A normative reference is not required and no normative reference was used. That document was not cited as a reference (normative or otherwise). I wonder what the rationale for omitting document.body was. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 18 Jan 2010 11:21 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith 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. >> >> So no longer of any concern. Thanks. >> >>>> 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. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please read that again: "stopped at CR phase in 2007. > > "CR" Stands for "Candidate Recommendation". > > | Candidate Recommendation (CR) > | A Candidate Recommendation is a document that W3C believes has been > | widely reviewed and satisfies the Working Group's technical > | requirements. W3C publishes a Candidate Recommendation to gather > | implementation experience. > > A recommendation (REC) can be used as a normative reference. > http://www.w3.org/2005/10/Process-20051014/tr.html#rec-track-doc > (in contrast to a CR, a REC can be a normative ref). -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 18 Jan 2010 12:23
Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> 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. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please read that again: "stopped at CR phase in 2007. > > "CR" Stands for "Candidate Recommendation". <yawn> I know. </yawn> (You should also have known better than trying to lecture me [of all people] about the W3C Process Document.) > [...] > A recommendation (REC) can be used as a normative reference. > http://www.w3.org/2005/10/Process-20051014/tr.html#rec-track-doc But a CR cannot. >>> http://www.w3.org/TR/WICDMobile/#dom >> >> You should know better than to cite Working Drafts as reference >> material. (How many times have I told you already?) > > If you look at the conclusion I wrote:- Your conclusion is irrelevant. You should have never cited this document in that manner in the first place (whom are you trying to fool here?): | Status of this Document | | [...] | Publication as a Candidate Recommendation does not imply endorsement by | the W3C Membership. This is a draft document and may be updated, replaced | or obsoleted by other documents at any time. It is inappropriate to cite | this document as other than work in progress. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee |