Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #18786

Re: Clean up HTML content

Show all headers | View raw

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:
    <news:3FF99790.4060001@PointedEars.de>
    <https://groups.google.com/group/de.comp.lang.javascript/msg/9fa70f6407c8d3fc?dmode=source>    
[2] Earliest version on Usenet available on Google Groups:
    <news:40584264.6070500@PointedEars.de>    
    <https://groups.google.com/group/comp.lang.javascript/msg/6c1f50d6e339b802?dmode=source>
[3] <news:490EE64E.5000307@PointedEars.de>
    <https://groups.google.com/group/comp.lang.javascript/msg/40ce845814b9933c?dmode=source>
[4] <news:4A49E20B.3040608@PointedEars.de>
    <https://groups.google.com/group/comp.lang.javascript/msg/b56b53e651bf007f?dmode=source>
[5] <news:4A4BE96C.1020801@PointedEars.de>
    <https://groups.google.com/group/comp.lang.javascript/msg/b24a396bcaf24e75?dmode=source>
 
>>> 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
>>
>> 
<http://pointedears.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fobject.js>
>>
>> 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.
>>
>> 
<http://pointedears.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Fcss.js>
>>
>> That, too, can be easily found with a Web search.
> 
> Would be nice to have same input search field to search through SVN files.

<http://lmgtfy.com/?q=getComputedStyle+site%3Apointedears.de>
 
> 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 

<https://groups.google.com/group/comp.lang.javascript/msg/5e095a9d3a86353c?dmode=source&output=gplain> 

(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.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Clean up HTML content Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-05 08:48 +0100
  Re: Clean up HTML content Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-05 17:55 +0100
    Re: Clean up HTML content Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-05 20:25 +0100
      Re: Clean up HTML content Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-06 00:03 +0100
        Re: Clean up HTML content Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-06 00:08 +0100
          Re: Clean up HTML content Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-03-06 22:06 +0000
            Re: Clean up HTML content Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-03-10 01:14 +0100
        Re: Clean up HTML content Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-06 22:02 +0100
          Re: Clean up HTML content Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-06 23:45 +0100
            Re: Clean up HTML content Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-09 11:29 +0100
              Re: Clean up HTML content Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-09 16:11 +0100
  Re: Clean up HTML content Danny <dann90038@gmail.com> - 2013-03-07 14:28 -0800
    Re: Clean up HTML content Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-03-09 11:37 +0100
      Re: Clean up HTML content dann90038@gmail.com - 2013-03-09 11:44 -0800

csiph-web