Various DOM-related wrappers (Code Worth Recommending Project)

[Peter Michaux]

Peter Michaux wrote:
[snip]

I'd be interested to read your design guidelines.

My design guidelines include that when I provide code for possible public
use I want to be prepared for the eventuality of an unknown execution
environment as much as I can, instead of fixing the code after *maybe* it
has been reported to break. I think that is a part of proper QA.

Would you test for the following old language features before you used
them?

Date
Array.prototype.join
Math.sin
arguments

You can test for these things and you say "as much as I can" yet I'm
still curious if you actually do test for these.

 

[Thomas 'PointedEars' Lahn]

Would you test for the following old language features before you used
them?

Date

No, that was introduced with JavaScript 1.0, and JScript 1.0.

Array.prototype.join

Not anymore. That was introduced with JavaScript 1.1 (Netscape 3.0), and
JScript 2.0 (Windows NT 4.0, maybe also in IE 3.x for Windows NT).

If I were to test this feature, I would have to test *for* `typeof' as well
(necessarily with evil[tm] eval()) as that was not introduced before
JavaScript 1.1. And that would be too much to ask for, also considering
that it is highly unlikely anyone still uses NN2 and IE3. (For the latter
and maybe the former, I could even argue that usage of this security-leaky a
browser should be implicitly sabotaged by not providing a fallback for it.)

Math.sin

No, same reason as for `Date'.

arguments

No, same reason as for Array.prototype.join().

You can test for these things and you say "as much as I can" yet I'm
still curious if you actually do test for these.

HTH

PointedEars

 

[Peter Michaux]

Would you test for the following old language features before you used
them?

Date

No, that was introduced with JavaScript 1.0, and JScript 1.0.

Array.prototype.join

Not anymore. That was introduced with JavaScript 1.1 (Netscape 3.0), and
JScript 2.0 (Windows NT 4.0, maybe also in IE 3.x for Windows NT).

If I were to test this feature, I would have to test *for* `typeof' as well
(necessarily with evil[tm] eval()) as that was not introduced before
JavaScript 1.1. And that would be too much to ask for, also considering
that it is highly unlikely anyone still uses NN2 and IE3. (For the latter
and maybe the former, I could even argue that usage of this security-leaky a
browser should be implicitly sabotaged by not providing a fallback for it.)

Math.sin

No, same reason as for `Date'.

arguments

No, same reason as for Array.prototype.join().

You can test for these things and you say "as much as I can" yet I'm
still curious if you actually do test for these.

HTH

So you don't test certain very old language features. That does help.
Thank you.

Now what about host objects? Do you test for the existence of every
host object before you use it? Do you test that every host object
works properly before you use and depend on it?

 

[Thomas 'PointedEars' Lahn]

So you don't test certain very old language features. That does help.
Thank you.

You're welcome, but please see my e-mail for details.

Now what about host objects? Do you test for the existence of every
host object before you use it? Do you test that every host object
works properly before you use and depend on it?

Not consistently yet, but maybe I should.


PointedEars

 

[Peter Michaux]

[snip]

Which browser has "alert" and it is not callable?

No idea which agent Thomas is referring to, but I don't see anything
wrong with:

if (isFeaturedMethod(this, 'alert')) {
...

}

Thomas would seem to prefer an equivalent to:

if (isFeaturedMethod(this, 'window') && isFeaturedMethod(this.window,
'alert')) {
...

}

I find that excessive.

What I don't like is:

if (this.alert) {
...

}

Same for:

if (document.getElementById) {
...

}

Those two are clearly ambiguous tests and I don't see how they save
more than a ms or two (and a few characters.) They also don't account
for Microsoft's ridiculous ActiveX host objects, whose methods blow up
when [[Get]] is invoked.

[[Get]] is invoked when typeof is used also. I've started a new thread
about this.

Encapsulating these tests in a common
function seems like the most robust and concise solution.

[snip]

 

[Peter Michaux]

You're welcome, but please see my e-mail for details.


Not consistently yet, but maybe I should.

You seem to trust that the older ECMAScript standard features will be
implemented but you don't trust that the older DOM standard features
will be implemented? They are both standards, both old and both have
parts that are implemented have been implemented without known
problems in any browser.

For example, would you test that a form object has an elements object
before using it's elements object? That seems to be in the same area
of assumable features with Array.prototype.join, don't you think?

 

[AKS]

AKS wrote: Actually, there's

no chances to meet such html-code [...]

Yes, there is.

<... onwhatever="property.access['with'].assignment =
'foobar';">

I wrote "such html-code " about class names. Because I didn't see such
markup as yet:

<div class="Thomas
'PointedEars'
Lahn">
</div>

But I am sure that you saw. And I think you agree with me, that it is
necessary to use regexps...

 

[Diego Perini]

AKS wrote: Actually, there's

no chances to meet such html-code [...]

Yes, there is.

<... onwhatever="property.access['with'].assignment =
'foobar';">

I wrote "such html-code " about class names. Because I didn't see such
markup as yet:

<div class="Thomas
'PointedEars'
Lahn">
</div>

But I am sure that you saw. And I think you agree with me, that it is
necessary to use regexps...

I think specifications where not written to cure imagination...

I agree that a regexp must be used in correctly (as per specs)
matching class names to cover also these edge cases but anyway the
regular expression is reduced to whitespace (\s) in one of these two
tastes:

(' '+el.className+' ').replace(/\s+/g,' ').indexOf(cn)
(' '+e.className+' ').split(/\s/).indexOf(cn)

Don't know but I remember some difference exists in IE by using regexp
in split, if I recall the separator will not be an item in the arry or
something like that. So this is another reason to prefer the
"replace()" method.

Are there further cases you see these may fail in class names
matching ?

 

[David Mark]

[snip]

var getChildren = (function() {
if (isFeaturedMethod(html, 'children')) {
return function(el) {
return el.children;
};
}
if (isFeaturedMethod(html, 'childNodes')) {

Need to test for tagName support with this?
Perhaps.


&& isRealObjectProperty(html, 'tagName')

If no tagName support the following will never find any children.

I can't imagine that a browser would support childNodes, but not
tagName. But at the very least, nodeName could be used instead.

return function(el) {
// Should use XPath here when possible
// Doesn't matter for getEBCS as XPath branch never calls this
var nl = el.childNodes, r = [];
var i = nl.length;

while (i--) {
// Code duplicated for performance
if ((nl.nodeType == 1 && nl.tagName != '!') ||
(!nl.nodeType && nl.tagName)) {
r.push(nl);

If performance is a concern wouldn't the following be better?

var n = nl;
if ((n.nodeType == 1 && n.tagName != '!') ||
(!n.nodeType && n.tagName)) {
r.push(nl);

Perhaps.

}
}
return r.reverse();
//return filter(toArray(el.childNodes), elementFilter);
};
}
})();

Could the || be determined at feature test time?
Yes.


if (typeof getAnElement == 'function') {
var html = getAnElement;

var getChildren = (function() {
if (isFeaturedMethod(html, 'children')) {
return function(el) {
return el.children;
};
}
if (isFeaturedMethod(html, 'childNodes') &&
isRealObjectProperty(html, 'tagName') {
if (isRealObjectProperty(html, 'nodeType')) {
return function(el) {
var nl = el.childNodes, r = [];
var i = nl.length;

while (i--) {
var n = nl;
if (n.nodeType == 1 && n.tagName != '!') {
r.push(n);
}
}
return r.reverse();
};

}
else {
return function(el) {
var nl = el.childNodes, r = [];
var i = nl.length;

while (i--) {
var n = nl;
if (n.tagName) {
r.push(n);
}
}
return r.reverse();
};

}
}
})();

}

Even if this is incorrect, this points out something I don't like
about optimizing for speed. It creates a lot of code.

I didn't read it closely enough to comment on its accuracy, but the
idea is sound.

 

[David Mark]

[snip]

function elementDocument(el) {
if (el.ownerDocument) {
return el.ownerDocument;
}
while (el.parentNode) {
el = el.parentNode;
}
return el;
}

The above function will be defined in browsers without ownerDocument
or parentNode. NN4 seems to be one example.

Wouldn't it be better to write the following?

if (typeof getAnElement == 'function') {

var html = getAnElement();

var elementDocument = (function() {

if (isRealObjectProperty(html, 'ownerDocument')) {
return function(el) {
return el.ownerDocument;
};
}
else if (isRealObjectProperty(html, 'parentNode')) {
return function(el) {
var e;
while (e = el.parentNode) {
el = e;
}
return el;
};
}

})();

}

I'm assuming the extra "e" variable is faster than accessing
parentNode property twice.

That seems a valid assumption.

 

[AKS]

Are there further cases you see these may fail in class names
matching ?

No, if only there will be no unexpected sequense of symbols in
generated html-code (for example '\u00A0\Ç0020' between class names).
But, as you have mentioned above, "any CMS or automation producing
that kind of markup" must be discarded.
However it is funny, that browsers have nothing against such division.
Two names divided by '\u00A0\Ç0020', will be correctly applied.

 

[Thomas 'PointedEars' Lahn]

Actually, there's no chances to meet such html-code [...]

Yes, there is.

<... onwhatever="property.access['with'].assignment =
'foobar';">

I wrote "such html-code " about class names.
ACK

Because I didn't see such markup as yet:

<div class="Thomas
'PointedEars'
Lahn">
</div>

But I am sure that you saw. And I think you agree with me, that it is
necessary to use regexps...

Definitely, /\s+/ should be used instead of " ". See also my dhtml.js.


PointedEars

 

[AKS]

See also my dhtml.js.

Thank you, I saw it. And the most part is good enough.