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 20 Jan 2010 15:45 On Wed, 20 Jan 2010 12:00:35 -0800 (PST), David Mark wrote: >Oh, this is what you meant by MSXML. These are programmatic ID's for >ActiveX components. You can be sure that XMLHttpRequest uses the same >components behind the scenes. ;) Ah, I wasn't sure about that. >Same and missing try-catch (this constructor can be disabled by the >user, just like ActiveXObject). I wonder if jQuery remembered to wrap >that one too. :) OK, will do. >I don't like that it runs these tests every time through, but the >basic ideas are sound. Checking the UA string would be far more >crude, not to mention disaster-prone. ;) OK, I should probably keep the XHR object for future Ajax calls. Thanks for the good comments! Hans-Georg
From: John G Harris on 20 Jan 2010 15:07 On Wed, 20 Jan 2010 at 17:34:47, in comp.lang.javascript, Thomas 'PointedEars' Lahn wrote: >John G Harris wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> 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. >> >> Which HTML standard is that ? The current standard makes no such >> recommendations. > >You are mistaken: <http://www.w3.org/TR/html4/appendix/notes.html#h-B.1> You ought not to link to an obsolete version of the standard. Section B.1 is talking about semantic errors : elements, attributes, attribute values, and character entities that are not recognised. Garrett was talking about "malformed, nonconformant HTML", which I take to mean syntax errors such as <style></title> . John -- John Harris
From: Garrett Smith on 20 Jan 2010 15:57 Thomas 'PointedEars' Lahn wrote: > John G Harris wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> 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. >> Which HTML standard is that ? The current standard makes no such >> recommendations. > What part of "don't expect nonstandard behavior from standard features" do you feel is worth arguing about? > You are mistaken: <http://www.w3.org/TR/html4/appendix/notes.html#h-B.1> > > That explains the problem rather well. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 20 Jan 2010 17:03 Thomas 'PointedEars' Lahn wrote: > 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? > No. I actually have paid attention to most discussions, but don't know which one you are referring to now. Or why. If I had to guess why, my guess would be that you want to try to prove that you are correct about calling "nonsense". >> 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:'. You are setting up a straw man. Nobody said that XHR must not be used for file. The problem with using XHR for file is that doing so expects behavior out of an object where that has been specified as being implementation-dependent. It is a false expectation that is based on something not stated. > 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. Assigning anything other than a domstring for the value in an assignment to a property that is specified as domstring is unspecified. Expecting type conversion to occur on that value is expecting nonstandard behavior. 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. > That is a false statement. >> 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 If a host object may result in something other than "object", it would certainly make very little sense to expect the result to be "object". It is not hard to find an implementation where typeof document.images !== "object". Many version of Safari are. A program that has an expectation that typeof document.images !== "function" or typeof document.images === "object" will have problems. This NG saw such examples c2007. A program that expects typeof document.images === "object" is making a false expectation. Such behavior is nonstandard and should not be relied upon. In ES5, a callable object, host or otherwise, should result "function" and so in a conformant implementation of that, where document.images is callable, then typeof document.images === "function" must be true. 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. > Other than a few trivial suggestions, HTML 4 does not define how the parser is supposed to handle invalid markup. Regarding non-conformant behavior, HTML 4 makes some suggestions for that, too, and in that very same appendix. Expecting the browser to perform that error correction is expecting nonstandard behavior. Error-correction beyond those few suggestions is not standard. A program that requires non-standard behavior is at great risk of failing. >> 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. > The WD states that other protocols are implementation-dependent, and so I don't see why you're insisting that the WD is wrong and that file would have to be supported. The best a program could hope for is that the WD is correct and correctly implemented. Expecting file protocol to be supported means that either A) The WD is incorrect, or B) All browsers that support XMLHttpRequest must implement the behavior that is defined as non-standard, and must do it in the way that you imagine to be correct. The XMLHttpRequest specification is currently a working draft, and so statements about standard behavior for XHR cannot use that draft as a normative reference. The XMLHttpRequest specification is also highly visible, actively maintained, mature, and has other specifications as dependencies. If there is a problem with not supporting file: I suggest you post that the the relevant w3c mailing list and explain your proposed solution so that the problem can be corrected. Until such changes to the occur, expecting certain behavior of XHR using file: protocol is a false expectation. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 20 Jan 2010 19:29
John G Harris wrote: > Thomas 'PointedEars' Lahn wrote: >> John G Harris wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> 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. >>> Which HTML standard is that ? The current standard makes no such >>> recommendations. >> You are mistaken: <http://www.w3.org/TR/html4/appendix/notes.html#h-B.1> > > You ought not to link to an obsolete version of the standard. You don't know what you are talking about. Standard-wise it really doesn't get any more current than "html4/" at the moment. > Section B.1 is talking about semantic errors : elements, attributes, > attribute values, and character entities that are not recognised. And now pray read its title. > Garrett was talking about "malformed, nonconformant HTML", which I take > to mean syntax errors such as <style></title> . Your conclusions as to what could have been meant are irrelevant. There *is* a standard that makes recommendations what to do about invalid markup which includes any notion of "malformed, nonconformant HTML". You have been proven wrong; stop whining and learn to live with it. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk> |