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 00:10 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? checking <http://docs.sun.com/source/816-6408-10/> i see that `getHours` was implemented in JavaScript 1.0 while `className` and the `toString` method (on the Date object) were implemented in JavaScript 1.1. are there reasons to feature test for `getHours`, `toString` and `className`? if so would the following tests be adequate? if (Date.prototype.getHours && Date.prototype.toString && typeof document.body.className !== 'undefined') { // above code here } 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. 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.
From: Hans-Georg Michna on 17 Jan 2010 06:30 On Sat, 16 Jan 2010 23:10:29 -0600, john wrote: >is there any general advice on when it would be ok to assume a feature >will be available? The question is equivalent to asking for a list of features for each of the browsers in question. I'd like to have that too, but I doubt that a comprehensive list even exists. Hope someone proves me wrong. The DOM objects listed on http://w3schools.com/jsref/ have tables with information on three major browser versions, but the site may be neither complete nor up to date nor entirely accurate. Their form comes closest to what I would wish. If only they would complete and regularly update their contents! http://javascriptkit.com/ often mentions browser versions, but unfortunately that site is severely incomplete and not always correct. https://developer.mozilla.org/en/JavaScript has a very good JavaScript reference with browser versions, but it is only valid for Mozilla offspring, i.e. Firefox. I'd like to know about any further, useful reference works. Hans-Georg
From: Thomas 'PointedEars' Lahn on 17 Jan 2010 08:33 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? > > 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. Second, JavaScript is not the only ECMAScript implementation. 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. > while `className` and the `toString` method (on the Date object) were > implemented in JavaScript 1.1. You are mistaken. `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. IOW, since you cannot assume the host environment provides that property, you should test whether that property exists before accessing it. Interestingly, though, the Client-side JavaScript 1.3 Reference says that the `toString' Date prototype method implemented in JavaScript 1.1 while the Core JavaScript 1.5 Reference at MDC says that it was implemented in JavaScript 1.0. The original Core JavaScript 1.5 Reference, too, still available e.g. from <http://ific.uv.es/informatica/manuales/CoreReferenceJS15/date.html#1206669> says "1.1" instead. I have observed in Netscape Navigator 2.02 (JavaScript 1.0) a few minutes ago (thanks to the evolt.org browser archive and Wine) that it supports var d = new Date(); d.toString() but not any of new Date().toString() (new Date()).toString() or d.getHours().toString() The difference between the References can be attributed to the use of toString() without and with the `new' keyword in the same statement when testing. So apparently "1.1" was an error in the Reference that was corrected at MDC. That the last expression fails in Navigator 2.0 appears to be related to the fact that Number.prototype.toString() is not supported until JavaScript 1.1 (Netscape 3.0; I have tested with Navigator 2.02 and 3.04). So you have to consider *all* components before you can make a correct compatibility judgement. > are there reasons to feature test for `getHours`, `toString` and No. > `className`? Yes. > 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. As for the `className' test, if you want to trust that implementors understood ,-[ECMAScript Language Specification, Edition 3 Final (2000), 11.4.3] | | 5. Return a string determined by Type(Result(4)) according to the | following table: as that `typeof' needs to result in a built-in String value, as clarified in ,-[ECMAScript Language Specification, Edition 5 (2009), section 11.4.3] | | 3. Return a String determined by Type(val) according to Table 20. then you can keep the strict comparison. If instead you subscribed to the idea that "With host objects, all bets are off."™, you would use a type- converting comparison. I recommend doing to the latter as the potential decrease in efficiency is negligible as compared to the possible gain in compatibility. > 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: <http://jibbering.com/faq/#posting> <http://PointedEars.de/es-matrix> 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 you desire further answers, please fix your From header as mandated by Internet standards, and sometimes provider's Acceptable Use Policies, and recommended by Netiquette guidelines. Violating foreign namespaces like using `nomail.com' for the domain part of an address header is _not_ acceptable. (And to me, neither is preventing e-mail communication abusing top-level domains like .invalid, should you get that idea as a result of your research.) <http://tools.ietf.org/html/rfc1036> <http://tools.ietf.org/html/rfc1855> 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: kangax on 17 Jan 2010 10:23 On 1/17/10 8:33 AM, Thomas 'PointedEars' Lahn 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? [...] >> while `className` and the `toString` method (on the Date object) were >> implemented in JavaScript 1.1. > > You are mistaken. `className' is (clearly) _not_ a built-in property but a > property of objects implementing the HTMLBodyElement interface of W3C DOM No, the interface is HTMLElement (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not HTMLBodyElement. [...] -- kangax
From: Thomas 'PointedEars' Lahn on 17 Jan 2010 10:27
kangax wrote: > Thomas 'PointedEars' Lahn wrote: >> john wrote: >>> given the following javascript: >>> >>> var hour = new Date().getHours().toString(); >>> document.body.className = '_' + hour; >>> >>> [...] >>> while `className` and the `toString` method (on the Date object) were >>> implemented in JavaScript 1.1. >> >> You are mistaken. `className' is (clearly) _not_ a built-in property >> but a property of objects implementing the HTMLBodyElement interface of >> W3C DOM > > No, the interface is HTMLElement > (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not > HTMLBodyElement. Yes, but if you check the IDL for HTMLElement, you can see that both statements are correct. I was referring to this property, therefore the more specific reference here. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |