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 17 Jan 2010 13:35 Thomas 'PointedEars' Lahn wrote: > 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 Right. I assumed Lahn had an editorial mistake. >> No, the interface is HTMLElement >> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not >> HTMLBodyElement. > Apparently I assumed incorrectly. > 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. > http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-62018039 | interface HTMLBodyElement : HTMLElement { | attribute DOMString aLink; | attribute DOMString background; | attribute DOMString bgColor; | attribute DOMString link; | attribute DOMString text; | attribute DOMString vLink; | }; I don't see `className` on that list. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 17 Jan 2010 14:05 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%. > 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 > } > The test for Date.prototype.toString is irrelevant to your code:- new Date() // returns a Date, .getHours() // returns a number, . toString(); // calls toString on the *number*. That statement should be widely supported. > 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. Object.prototype.hasOwnProperty fails in older browsers, such as Mac IE. The greatest divergence will be found in browser object models. > 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. In your case, document.body might be undefined in an XHTML DOM. That problem can be avoided by not using XHTML, of course. Use w3c standards features an approaches first and do not expect non-standard behavior from them. Nonstandard features tend to have more divergence in how they work. MSDN has provided many code examples that work only in IE. Sites that use have used those examples failed in other browsers. To make those the sites work, other browsers copied the feature, but usually with a variation. When the standard approach fails, check your code against the specification. Did you expect something that was not specified? Based on the failure, you might want to either rethink the problem, address the failure by making sure that the condition which triggers it does not occur. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 17 Jan 2010 17:02 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> 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 > > Right. I assumed Lahn had an editorial mistake. So we are back to second name? >>> No, the interface is HTMLElement >>> (<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>), not >>> HTMLBodyElement. > > Apparently I assumed incorrectly. > >> 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. > > http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-62018039 > > | interface HTMLBodyElement : HTMLElement { > | attribute DOMString aLink; > | attribute DOMString background; > | attribute DOMString bgColor; > | attribute DOMString link; > | attribute DOMString text; > | attribute DOMString vLink; > | }; > > I don't see `className` on that list. Smith fails to see "HTMLElement" here. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Thomas 'PointedEars' Lahn on 17 Jan 2010 17:03 Garrett Smith wrote: > john wrote: >> 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. It's _host_ objects. Lowercase. *Really.* 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: john on 17 Jan 2010 18:23
On 17 Jan 5:30 AM, Hans-Georg Michna wrote: > 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. that's not at all what i was asking for. perhaps i phrased it poorly. i was wondering what criteria experienced javascript programmers use to decide when a feature test is necessary and when it's ok to skip it. not for a specific list of features they test for. after reading the responses from Thomas Lahn and Garret Smith i think it is largely a matter of experience with different implementations and understanding of the relevant specifications. |