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: Eric Bednarz on 20 Jan 2010 20:15 Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: > John G Harris wrote: > You don't know what you are talking about. Standard-wise it really doesn't > get any more current than "html4/" at the moment. Somebody doesn't know what she is talking about for sure. 'HTML 4' is a W3C recommendation, the only relevant HTML *standard* is ISO/IEC 15445:2000. >> 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. Now pray read the paragraph on error conditions in the conformance section in the *normative* part of the prose. No informative hand waving required at all to support the thesis “Code that uses malformed, nonconformant HTML is expecting nonstandard behavior”. > You have been proven wrong; […] I call shenanigans.
From: Thomas 'PointedEars' Lahn on 21 Jan 2010 09:52 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> 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". OMG. Perhaps I am referring to the attribute discussions we frequently have, all of which are related to standard properties? >>> 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. Hardly. You were asserting that there was a standard to specify this as you called using `file:' and expecting it to work relying on non-standard behavior. >>> 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. That does not make it non-standard behavior. It is only non-standard if there is a standard that says type conversion must not happen. > Expecting type conversion to occur on that value is expecting > nonstandard behavior. No. >> 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. It isn't. You have some serious misconceptions about standards instead. >>> 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". Still it is _not_ "expecting non-standard behavior". > It is not hard to find an implementation where typeof document.images > !== "object". Many version of Safari are. Non sequitur. > [snipped more fallacies] >>> 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. The recommendations are there, that's the point. > Regarding non-conformant behavior, HTML 4 makes some suggestions for > that, too, and in that very same appendix. Exactly. > Expecting the browser to perform that error correction is expecting > nonstandard behavior. No, evidently not. > Error-correction beyond those few suggestions is not standard. No. It's the same misconception of yours again. > A program that requires non-standard behavior is at great > risk of failing. Non sequitur. >>> 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, [...] This WD (or any other working draft) is *irrelevant* with regards to standards! PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Thomas 'PointedEars' Lahn on 21 Jan 2010 10:06 Eric Bednarz wrote: > Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: >> You don't know what you are talking about. Standard-wise it really >> doesn't get any more current than "html4/" at the moment. > > Somebody doesn't know what she is talking about for sure. She, Erica? > 'HTML 4' is a W3C recommendation, the only relevant HTML *standard* is > ISO/IEC 15445:2000. Of course not. W3C Recommendations (with capital R) are considered Web standards. <http://www.w3.org/Consortium/> <http://www.w3.org/standards/> <http://www.w3.org/standards/about.html> <http://www.w3.org/standards/faq.html#std> <http://en.wikipedia.org/wiki/Web_standards> <http://webstandardsgroup.org/standards/> <http://www.opera.com/company/education/curriculum/> <http://www.zeldman.com/dwws/> <http://www.alistapart.com/articles/grokwebstandards/> <https://developer.mozilla.org/en/using_web_standards_in_your_web_pages> <http://www.456bereastreet.com/lab/developing_with_web_standards/> (Want more proof? Google is your friend. [psf 6.1]) >>> 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. > > Now pray read the paragraph on error conditions in the conformance > section in the *normative* part of the prose. No informative hand waving > required at all to support the thesis “Code that uses malformed, > nonconformant HTML is expecting nonstandard behavior”. Nonsense. >> You have been proven wrong; […] > > I call shenanigans. Parse error. 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 G Harris on 21 Jan 2010 09:49 On Thu, 21 Jan 2010 at 01:29:51, in comp.lang.javascript, Thomas 'PointedEars' Lahn wrote: >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. The W3C web site points to <http://www.w3.org/TR/1999/REC-html401-19991224/> Note the 401 in its name. You've picked a URI that foolishly points to the HTML 4.01 document while having the appearance of pointing to the HTML 4 document. >> 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. Regardless of the title, the section is there "to facilitate experimentation and interoperability between implementations of various versions of HTML", not to advise on handling invalid markup in general. >> 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". But all it says about bad syntax is "Since user agents may vary in how they handle error conditions, authors and users must not rely on specific error recovery behavior", which is where this started. >You have >been proven wrong; stop whining and learn to live with it. I say it was you who got it wrong. John -- John Harris
From: Thomas 'PointedEars' Lahn on 21 Jan 2010 10:24
John G Harris wrote: > Thomas 'PointedEars' Lahn wrote: >> 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. > > The W3C web site points to > <http://www.w3.org/TR/1999/REC-html401-19991224/> > Note the 401 in its name. You've picked a URI that foolishly points to > the HTML 4.01 document while having the appearance of pointing to the > HTML 4 document. AISB, you don't know what you are talking about. The "html4/" URI always refers to the latest (most recent) version of HTML 4, which currently is HTML 4.01. (That is, both mentioned URIs currently refer to the *same* resource.) ,-<http://www.w3.org/TR/html4/> | | This version: ^^^^^^^^^^^^ | http://www.w3.org/TR/1999/REC-html401-19991224 | (plain text [794Kb], gzip'ed tar archive of HTML files [371Kb], a | .zip archive of HTML files [405Kb], gzip'ed Postscript file [746Kb, | 389 pages], gzip'ed PDF file [963Kb]) | Latest version of HTML 4.01: | http://www.w3.org/TR/html401 | Latest version of HTML 4: ^^^^^^^^^^^^^^ | http://www.w3.org/TR/html4 | [...] (Granted, the use of `latest' in English can be confusing. However, if you had read more carefully ...) > [snipped more pointless babbling] 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 |