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: Hans-Georg Michna on 18 Jan 2010 12:47 On Sun, 17 Jan 2010 17:23:51 -0600, john wrote: >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. I thought it was obvious that a feature test is needed when one cannot rely on the feature being available in all of the targetted browsers. Therefore the question is equivalent to asking which features are available in which browsers. Hans-Georg
From: Garrett Smith on 18 Jan 2010 15:47 Thomas 'PointedEars' Lahn wrote: > 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. > Yes, that's a true statement, but beside the point. The document linked was not used as a normative reference. >>>> 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?): > The only person that seems to be fooled is *you*. The CR is not a normative reference, so arguing to say that I am wrong by using it as is a normative reference seems to be on the wrong track. I don't see where you're going with this (probably nowhere). I want to know if any implementations are following that CR, and also what the rationale for omitting document.body there. I do not expect you to answer those questions although someone else might be able to. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Jake Jarvis on 18 Jan 2010 16:43 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> 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. >> > > Yes, that's a true statement, but beside the point. > > The document linked was not used as a normative reference. > >>>>> 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?): >> > > The only person that seems to be fooled is *you*. The CR is not a > normative reference, so arguing to say that I am wrong by using it as is > a normative reference seems to be on the wrong track. > > I don't see where you're going with this (probably nowhere). > > I want to know if any implementations are following that CR, and also > what the rationale for omitting document.body there. I do not expect you > to answer those questions although someone else might be able to. It might just seem that you quoted that CR as an argument and support for "document.body might be undefined" (when it's not a bug). -- Jake Jarvis
From: Garrett Smith on 18 Jan 2010 17:36 Jake Jarvis wrote: > Garrett Smith wrote: >> Thomas 'PointedEars' Lahn wrote: >>> 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' [...] >> I want to know if any implementations are following that CR, and also >> what the rationale for omitting document.body there. I do not expect you >> to answer those questions although someone else might be able to. > > It might just seem that you quoted that CR as an argument and support > for "document.body might be undefined" (when it's not a bug). > What part of "Seems to have stopped at CR phase in 2007" sounds like an argument? Or is the argument in 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. I don't see it. Does any browser implement WICD Mobile 1.0 and use the DOM Level 2 HTML Subset? What do you think the reason for omitting document.body from that draft is? Don't have answers? Join the club. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 20 Jan 2010 07:49
Garrett Smith wrote: > john wrote: >> Thomas 'PointedEars' Lahn wrote: >>> john wrote: >>>> Garrett Smith wrote: >>>>> 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. Nonsense. Obviously you have not paid attention to previous discussions. Does setAttribute()/getAttribute() ring a bell? > 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). Nonsense. 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(). > Code that is expecting assignment to DOM domstring properties to be > converted to string is expecting nonstandard behavior. Nonsense. The API Specification does not say how implementations should behave there. While there is indication that it would be unwise to rely on implicit type conversion, that is certainly not based on an expectation of nonstandard behavior. > Code that is expecting typeof document.images == "object" is expecting > nonstandard behavior. Nonsense. `document.images' is a reference to a host object. Host objects are free to implement whatever `TypeOf' algorithm they want per ES3F, with any possible string value as a result. While ES5 limits that to not include "object" (and other values), there are more implementations that implement ES3F than ES5 (of which it is not entirely clear what it is its current status). That is, it is certainly not safe to have the aforementioned expectation, but it is also NOT an expectation of non- standard behavior. > Code that uses malformed, nonconformant HTML is expecting nonstandard > behavior. 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. > 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. You don't get it, do you? Working drafts are NOT to be cited as reference material, as something else than "work in progress". They are NOT standards. While that already follows from the W3C Process Document and common sense, the very text of the Working Draft you are referring to explicitly says so in its "Status of this Document" section. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigat-or.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 |