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: john on 17 Jan 2010 18:23 On 17 Jan 7:33 AM, Thomas 'PointedEars' Lahn wrote: > john wrote: > >> checking<http://docs.sun.com/source/816-6408-10/> i see that `getHours` >> was implemented in JavaScript 1.0 > > Yes, but that does not mean anything. First of all, that documentation is > mostly outdated. You should use > > <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/> > > instead. will do. > Second, JavaScript is not the only ECMAScript implementation. as in the following? JavaScript, JScript and the implementations in Opera and WebKit (and some browsers i've never heard of) are all unique; different versions of an implementation may vary widely; and the implementations from various vendors are bound to vary. additionally there are some implementations that run completely outside of a web browser. > What matters > is that *some* of these features have been implemented since JavaScript 1.0 > *and* specified since ECMAScript Edition 1. For historical reasons, it is > therefore unlikely, though entirely possible, that an implementation still > usable today would not provide *those* features or support them in that > way. so what and when to test is a judgment call based on experience with implementations (of the browsers you are interested in supporting) and understanding of the relevant specifications? are there more criteria i'm missing? >> while `className` and the `toString` method (on the Date object) were >> implemented in JavaScript 1.1. > > You are mistaken. no doubt about that. i must not have been paying any attention when i looked up the `className` property. where it's mentioned in the JavaScript 1.3 reference it is clearly not what i was looking for. | className: The fully qualified name of a Java class in a package | other than `netscape`, `java`, or `sun` that is available to | JavaScript. > `className' is (clearly) _not_ a built-in property but a > property of objects implementing the HTMLBodyElement interface of W3C DOM > Level 2 HTML (as a shorthand to accessing the `class' attribute of the > corresponding element); those are host objects, and even though they have > an ECMAScript binding, the corresponding interface is language-independent. i have started reading the DOM Level 2 HTML Specification. >> are there reasons to feature test for `getHours`, `toString` and > > No. is that "No" because they are "old enough" features provided by the ECMAScript language and you have witnessed them working as expected? i.e. based on the relevant specifications and experience with implementations. >> `className`? > > Yes. is that "Yes" because it is a feature of the host environment and host environments should be assumed hostile? >> if so would the following tests be adequate? >> >> if (Date.prototype.getHours&& Date.prototype.toString&& >> typeof document.body.className !== 'undefined') { >> // above code here >> } > > No. You are testing the true-ness of the first two built-in properties, > not their callability; if you think you need to test them, test whether > `typeof' results in "function" instead. now that i've spent some more time reading and testing i can see that those test are indeed inadequate. particularly if you don't want to throw script errors in very old browsers; which i gather could be considered unacceptable or unimportant under certain conditions. >> i have gathered a number of "ancient" browsers (MacIE 5.2.3, Opera 7.54, >> Firefox 1.0.7 etc.) to test with but my question is more concerned with >> finding a general principle for what and when to feature test. > > First of all, you need to understand that in most cases (i.e., on the Web) > you are _not_ dealing with a *single* programming language but *several* > *different* ECMAScript implementations: i think i understand that. i should have been more clear that i was not looking at the JavaScript reference as if it applied to all web browsers. i'm going through all of the links referred to at <http://jibbering.com/faq/#onlineResources> and just picked the one i had looked at most recently to reference. > <http://PointedEars.de/es-matrix> bookmarked. > Second you need to understand the difference between built-in objects like > Date instances, and host objects (objects defined by the host environment) > like HTMLBodyElement implementations. > > <http://ecmascript.org/> should i begin with the 5th edition keeping in mind that some of the new language features will need feature testing or would it be better to become familiar with the 3rd edition first? does it even matter? > Should you desire further answers, please fix your From header my apologies.
From: john on 17 Jan 2010 18:24 On 17 Jan 1:05 PM, Garrett Smith wrote: > john wrote: >> given the following javascript: >> >> var hour = new Date().getHours().toString(); >> document.body.className = '_' + hour; >> >> is it safe to assume that any browser supporting javascript will be >> able to execute the code without error. in other words is it safe to >> assume the features exist and implementations will work as expected? >> > > Nothing is guaranteed 100%. which seems like one of the more interesting parts of browser scripting. >> i have gathered a number of "ancient" browsers (MacIE 5.2.3, Opera >> 7.54, Firefox 1.0.7 etc.) to test with but my question is more >> concerned with finding a general principle for what and when to >> feature test. >> > > That comes down to experience, unfortunately. fortunately this project is academic and for my own amusement so there is plenty of time to gain the necessary experience (and thanks to Thomas Lahn pointing out the evolt browser archive entirely possible). > 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? i searched with google but didn't find anything that looked authoritative. i read the following pages from the search results: - <http://msdn.microsoft.com/en-us/library/ms952643.aspx> - <http://javascript.about.com/od/browserobjectmodel/Browser_Object_Model.htm> the MSDN article seems a bit sparse and while thorough i'm not sure the accuracy of the about.com article. are there others that would be worth reading? >> is there any general advice on when it would be ok to assume a feature >> will be available? i've read the document at >> <http://jibbering.com/faq/faq_notes/not_browser_detect.html> but am >> still not sure where to draw the line. > > More caution is needed with Host objects. that was the impression i got from Thomas Lahn's initial response > In your case, document.body might be undefined in an XHTML DOM. That > problem can be avoided by not using XHTML, of course. of course; and since i'm interested in the very oldest dynamic browsers XHTML is not even an option as i guess none of them would know what to do with an XHTML mime-type. > Use w3c standards features an approaches first and do not expect > non-standard behavior from them. understood. > Nonstandard features tend to have more divergence in how they work. understood.
From: Garrett Smith on 17 Jan 2010 18:53 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> kangax wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> john wrote: >>>>>> given the following javascript: [...] >>>> No, the interface is HTMLElement >>>> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not >>>> HTMLBodyElement. >> Apparently I assumed incorrectly. >> To say that className is a property of objects implementing HTMLBodyElement is as misleading because it is too narrow. className is a property of HTMLElement and HTMLBodyElement is an HTMLElement. That is exactly what kangax correctly pointed out. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 17 Jan 2010 19:34 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> kangax wrote: >>>>> No, the interface is HTMLElement >>>>> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not >>>>> HTMLBodyElement. >>> Apparently I assumed incorrectly. >>> > > To say that className is a property of objects implementing > HTMLBodyElement is as misleading because it is too narrow. Not for those with eyes to see. > className is a property of HTMLElement and HTMLBodyElement is an > HTMLElement. Nonsense. > That is exactly what kangax correctly pointed out. kangax, too, failed to see what I was specifically referring to, and the inheritance present in the W3C DOM API Specifications. 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
From: Thomas 'PointedEars' Lahn on 17 Jan 2010 19:57
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? 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. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |