Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!newsfeed.straub-nv.de!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <104841153.13fF9WP0Kf@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sat, 09 Mar 2013 16:11:53 +0100 User-Agent: KNode/4.8.5 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <2342178.BYbISWzQ9U@PointedEars.de> <1699591.rPLLIT5s0r@PointedEars.de> <2295376.vs5DUIPqoH@PointedEars.de> MIME-Version: 1.0 Lines: 226 NNTP-Posting-Date: 09 Mar 2013 16:11:59 CET NNTP-Posting-Host: 500e65d6.newsspool2.arcor-online.net X-Trace: DXC=XZeY8LdFHfhUoRk[hk2WalA9EHlD;3Ycb4Fo<]lROoRa8kFnDZm8W4\YJNlb@mF9jNikdeIQbgJMhLo0g<6iGeQPVScd X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:18786 Cezary Tomczyk wrote: > W dniu 2013-03-06 23:45, Thomas 'PointedEars' Lahn pisze: >> Cezary Tomczyk wrote: >>> W dniu 2013-03-06 00:03, Thomas 'PointedEars' Lahn pisze: >>>> Cezary Tomczyk wrote: >>>>> Here's the code: >>>>> >>>>> var is_block_style = function (el) { >>>>> var el_style; >>>>> if (window.getComputedStyle) { >>>> >>>> You should feature-test this method in a way that does not primarily >>>> use implicit type conversion. There is one DOM implementation, MSHTML, >>>> that is notorious for throwing strange exceptions on properties of type >>>> "unknown" otherwise. See also, e.g., jsx.object.isHostMethod(). >> ^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ >>> Yes, I know that IE return sometimes "object", sometimes "function". >> >> More importantly, sometimes the result of the “typeof” operation is >> “"unknown"” there (I hope the additional quotes make it clear now). And >> then a type-converting test throws an exception. So a type-converting >> test cannot be considered appropriate for feature-testing host object's >> methods. It is insufficient for testing native object's methods already. > > That's surprising me, I mean about "unknown". I never saw it before. It has been common knowledge here and in de.comp.lang.javascript for about a decade now. IIRC, I had first suggested using a “typeof” operation to tell callable and non-callable properties apart, isMethodType(), in 2003 CE. [1, 2] After I presented my suggestion on Usenet it turned out that certain host objects in MSHTML exhibited the aforementioned behavior with “typeof”, which led to the extension of isMethod(). Eventually, IIRC as suggested first by David Mark in what you could call a “library battle” (reference anyone?), it led to the use of a second string argument and the bracket property accessor syntax to prevent type conversion on "unknown" properties. From that point forward, isMethodType() was marked deprecated in favor of isMethod(). [3] However, it became apparent that considering both host object properties and native methods in the same feature-test was rather inefficient and unnecessary, because when you want to feature-test a method you almost always know what kind of method you are testing for. So, IIRC, again it was David who suggested using two methods for either case, isHostMethod() and isNativeMethod(). I had my doubts about that at first. In parallel I had been continuing to improve isMethod() so that it could feature-test along a MemberExpression (for lack of a better term) [4], and accepting a reference to an Array instance, several methods at once, eliminating the need for several calls with related features; the latter was suggested by kangax [5]. Eventually recognizing David's suggestion as necessary to be implemented in some cases (most notably event handling), the method now being properly namespaced as jsx.object.isMethod() was redesigned so that it could distinguish between those two cases, and a minimum jsx.object.isNativeMethod() was added to call it, reusing most of the existing code. jsx.object.isHostMethod() and jsx.object.areHostMethods() became aliases for jsx.object.isMethod() then. Curiously enough, I am now at a point where I see calling jsx.object.isNativeMethod() as computationally wasteful if the base object is known and there is only one property of it to test, and have begun to replace those calls with a simple “typeof” operation again. This design decision was also supported by ECMAScript Edition 5 specifying in section 11.4.3 that host objects MUST NOT yield any of the string values for native objects with “typeof”, except "function" if they are callable. ____________ [1] Earliest mention on Usenet available on Google Groups: [2] Earliest version on Usenet available on Google Groups: [3] [4] [5] >>> jsx.object.isMethodType = function (s) { >> ^^^^^^^^^^^^^^^^^^^^^^^ >>> return /^\s*(function|object|unknown)\s*$/i.test(s); >>> }; >> >> … and no; evidently the name of the method I mentioned is different. The >> actual method *actually* is too long to be posted here. It can be found >> in >> >> >> >> which in turn can be easily found with a Web search. > > isHostMethod is the same as isMethod, as I see: > > jsx.object.isHostMethod = jsx.object.areHostMethods = jsx.object.isMethod; Yes, see above. >>> I do not see here >>> >> http://pointedears.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom.js >>> method getComputedStyle. >> >> Because it requires *CSS* (D)OM capabilities. For historical reasons it >> is not available as jsx.dom.css.getComputedStyle(), though. >> >> >> >> That, too, can be easily found with a Web search. > > Would be nice to have same input search field to search through SVN files. > I found jsx.dom.getComputedStyle and seems it's code looks not so big. Note the dependencies. >>> * https://developer.mozilla.org/en-US/docs/DOM/window.getComputedStyle >> >> Keep in mind that this is a wiki. Anyone logged in can write any >> nonsense there. And anyone logged in can correct it. If they learn >> about it. > > "Anyone can write nonsense, anyone can correct it." - how to trust in > that sources then? Hm... Exactly. However, you might be interested to know that I have recently migrated my MDN account to Mozilla Persona, so there is a chance that things are not as bad. >> [why document.defaultView.getComputedStyle is to be preferred] > > Thank you for nice explanation. Also, method jsx.dom.getComputedStyle > looks good. You are welcome. The trunk version might need to be updated, though, so that makes use of getPropertyValue() if available; it may also fix some bugs. It appears to better to accept only CSS-style property names as arguments, and convert them to script-style ones only when necessary. But I have to check use-cases and dependencies first. BTW, the first version of that method appears to be available at (which I found during isMethod() research; ironically that version already used getPropertyValue().) >>>>> var imgClassName = 'testimg'; >>>>> >>>>> var tidyHTML = function (node) { >>>>> var elms = node.childNodes, >>>>> i = elms.length, >>>>> text = '', >>>>> elm; >>>>> >>>>> if (!node.hasChildNodes() >>>> >>>> I have never used that method before. Unless you are sure about its >>>> backwards-compatibility, you should replace the call with >>> >>> I use https://developer.mozilla.org/en-US/docs/DOM/Node.hasChildNodes >>> from long time. Sesms it's implemented long time ago. See: >>> http://www.quirksmode.org/dom/w3c_core.html >> It was *specified* a long time ago. I rather do my own tests instead of >> relying on MDN or Quirks Mode. > > Yes, many things can be specified, but not implemented. However, > theoretically, we should check if there are exists all methods before > using them. More over, they can work with a very different way that that > is expected. You are preaching to the choir here. > Is not it already fall into an paranoid? I do not know. Parse error. >>>> (i.e., its boolean ”global” property has the value “false”). >>> >>> Right. I should set "global" as "true". >> >> No, I did _not_ suggest that you should make that mistake: > >> var rx = /foo/g; >> var s = "foo"; >> >> /* true */ >> rx.test(s) >> >> /* false */ >> rx.test(s) >> >> /* true */ >> rx.test(s) > > Correct me if I am wrong: in fact boolean "global" should be false > because I need to find at least one "class name". No need to find all of > them. Except when I want to remove them. Correct. But more importantly, RegExp.protoype.test() should *never* be called on RegExp instances with the “global” flag set, because it wraps RegExp.prototype.exec(). > [...] > >>> Because sometimes I removing node. >> >> How does that explain the opposite direction of the concatenation? > > I suppose it doesn't have to be opposite direction. It *must not* be in your case (unless you want the result to be backwards). “Opposite“ does not just mean “i--” here; it means ”i--” *and* “… += x[i]”, or “++i” *and* “… = x[i] + …”. -- PointedEars Twitter: @PointedEars2 Please do not Cc: me. / Bitte keine Kopien per E-Mail.