Various DOM-related wrappers (Code Worth Recommending Project)

On Dec 9, 2:34 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
wrote:

Peter Michaux wrote:
Based on the repository design guidelines, the above could be
substantially reduced to just
[...]
Notes:

There is no need to check for the existence of "document" as no
browser, NN4+ and IE4+, missing "document".

There is no need to check that document.getElementById is a callable
since there has never been a known implementation where
document.getElementById that is not callable.

If these are the guidelines for your project, to produce code that is not
interoperable and inherently unreliable, I don't want to contribute.

I somewhat agree with that sentiment,

I would say your codes says otherwise and that you agree that a line
for feature testing should be drawn somewhere.

[quoted from the original post in this thread]

// Note that Array.prototype.reverse is not
// tested as it is from JS 1.1

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 1:51 am, VK <schools_r... (AT) yahoo (DOT) com> wrote:

On Dec 9, 4:32 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

Based on the repository design guidelines, the above could be
substantially reduced to just

if (document.getElementById) {
var getEBI = function(id, d) {
var el = (d||document).getElementById(id);
if (el.id == id) {
return el;
}
};

}

That is an absolutely terrible way to implement a _runtime_ method.
DOM interface calls are the most used in any script and they have the
greatest impact to the performance. JS <=> DOM calls already much
slower then JS <=> JS calls and cutting their performance even further
for any bit is a crime to be punished :-) :-|

Features/environment sniffing has to be done only _once_ on the
instantiation stage

In the code I posted the feature testing is only done once.

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 10:49 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

On Dec 9, 2:34 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:





On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
wrote:

Peter Michaux wrote:
Based on the repository design guidelines, the above could be
substantially reduced to just
[...]
Notes:

There is no need to check for the existence of "document" as no
browser, NN4+ and IE4+, missing "document".

There is no need to check that document.getElementById is a callable
since there has never been a known implementation where
document.getElementById that is not callable.

If these are the guidelines for your project, to produce code that is not
interoperable and inherently unreliable, I don't want to contribute.

I somewhat agree with that sentiment,

I would say your codes says otherwise and that you agree that a line
for feature testing should be drawn somewhere.

I was talking about the issue he was referring to (gEBTN for document
vs. element.) At least I think that was what he was referring to. In
any event, I don't think that everything should be feature tested or
that the position of boycotting the project otherwise is a reasonable
one.

[quoted from the original post in this thread]

// Note that Array.prototype.reverse is not
// tested as it is from JS 1.1

I definitely don't bother testing anything from 1.1. That is a line I
have drawn in my own framework.

On Dec 9, 2:24 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 12:02 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

[snip]

I made a CSS selector function one time (something like
jQuery has) and I found that any

I have found that a combination of gEBI and gEBTN is all I ever need
to home in on whatever elements I need to manipulate.

I use something like a a getElementsByClassName sometimes but that
otherwise that is my limit also.

[snip]

// Another implementation for developers concerned with
// the IE5 problem about doctype and comments

if (document.getElementsByTagName &&
typeof getAnElement != 'undefined' &&
getAnElement().getElementsByTagName) {

var getEBTN = function(tag, root) {
var els = root.getElementsByTagName(tag);

if (tag == '*' && !els.length && root.all) {
var all = root.all;
els = [];
for (var i=0, ilen=all.length; i<ilen; i++) {
var el = all[i];

I prefer not to declare variables inside of loops. And for long
loops, a while that counts down to 0 will be faster. Granted, you
have to reverse the results at the end.

I prefer countdown loops also but don't use them when order matters.

// The following conditional could be factored out
// if necessary.
if ((el.nodeType == 1 && el.tagName != '!') ||
(!el.nodeType && el.tagName)) {
els[els.length] = el;
}
}
}

return els;
};

}

I haven't actually verified the IE5 bug yet and tested the above in a
wide set of browsers. I'm just looking at the packaging of the
concepts.

It isn't actually a bug, but a limitation of IE5's implementation of
gEBTN. It just doens't handle "*".

Fair enough.

[snip]

Even though the two getEBTN wrappers use different fallbacks for IE4
it looks like they could be combined into one just like I've done here
with no real performance penalty. If some browsers had document.all
and not element.all then that would be a problem but has that ever
been the case?

That one isn't likely. It was the gEBTN inference that I wanted to
avoid. The previous discussion about this stemmed from the fact that
most libraries make similar inferences about addEventListener (which
requires three implementations: window, document and element.) It was
noted that agents do exist that support that method for elements, but
not for window.

Do you have a link to that previous discussion? If so please post it
when we get to events. I didn't know such a case existed.

The API should be considered here. A getEBTN wrapper function like the
above could be called "getByCssSelector" and the calls to getEBTN
would become a subset of the possible calls to "getByCssSelector".

If you feel we must have a getByCssSelector,

I don't think it is a must.

then that makes sense. I
can't imagine a scenario where I would use such a thing.

I can only imagine myself using one that takes simple selectors like
"div", "#fooId", ".fooClass" and combinations of those three. A more
complex selector is only needed if the content creator is totally
uncooperative and won't add the hooks needed by the JavaScript
programmer.

The programming of a getByCssSelector sure is fun. Probably the most
enjoyable thing I've programmed in JavaScript that might be useful as
it involves a CSS selector string parser and optimization is a major
priority.

[snip]

This is something I'd like to add to the repository eventually. I did
a couple weeks of work on these types of functions a while ago and it
is very handy for enlivening pages for unobtrusive JavaScript. (Cue
"PointedEars" for a "lemmings" comment.)

I haven't found a need for such queries and I agree with "PointedEars"

That is the fourth and a half time that has happened recently.

in that event delegation is often the best way to go anyway.

I don't see them as mutually exclusive as there are only so many
elements on which to delegate and listeners concerned with different
handlers should not be combined. I really don't get what he is talking
about, he has told me I don't understand, and he is write.

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 4:32 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 12:02 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

[snip]



I didn't make a time test but I think the simulation of
Array.prototype.filter will be very slow. I made a CSS selector

Considering that the use of the filter wrapper only helps IE5 and
under, it does make sense to duplicate its functionality in the gEBTN
wrapper. But that function and other JS1.6 array method wrappers are
useful for other purposes where speed is less of an issue. I think
that we should deal with those shortly.

Looking at the rest of my "base" module, I think these topics should
be considered next (in no particular order.)

These extend what is currently being discussed:
- Get child elements
- Get first and last child element (with optionally specified tagName)
- Get HTML and head elements

These are needed to complete basic feature testing support:
- Style support detection
- createElement and XML parse mode detection
- Element parent and owner document
- Element "canHaveChildren" test

Array and object testing, traversal and mutation:
- isArray
- push/pop
- 1.6 Array method wrappers (filter, map, some, every, forEach, etc.)
- For in filter.

Events (needed to support more advanced feature testing):
- addEventListener wrapper
- DOMContentLoaded simulation

Miscellaneous:
- Get and set element text
- Cookies (with optional support for ASP's keyed values.)
- Plug-in detection

I realize that the task of finalizing, adding and documenting each is
a bottleneck,

Yes. I am working on an automated testing system now and that will
help greatly. A documentation format has not be worked out. These are
both just as important to the project as the actual code.

but perhaps we should start discussing some of these in
parallel.

No more than two at a time and maybe with a bit of a breather in
between each topic. Folks that want to keep up but have to do actual
work will be overwhelmed. I felt this project was a bit too demanding
on my time this past week. There is no timeline and slow with more
time to digest and think about things is better than fast and rushed.

Everybody has their own areas of interest,

indeed

so this may
increase overall participation in the project.

My preference is to focus on developing bigger modules and then the
smaller things you've listed above will be added in as necessary. This
helps us answer frequently asked questions like "Which Ajax library
should I use?" Ajax and event modules seem to be the first logical
modules to me. Already the functions prerequisite to Ajax have been
discussed so I would like to do that after gEBI and gEBTN. After the
gEBTN, gEBI and Ajax parts are finished the code repository will have
enough bulk to consider it in general and develop testing and
documentation systems before continuing with more features.

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 7:56 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 10:49 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

On Dec 9, 2:34 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
wrote:

Peter Michaux wrote:
Based on the repository design guidelines, the above could be
substantially reduced to just
[...]
Notes:

There is no need to check for the existence of "document" as no
browser, NN4+ and IE4+, missing "document".

There is no need to check that document.getElementById is a callable
since there has never been a known implementation where
document.getElementById that is not callable.

If these are the guidelines for your project, to produce code that is not
interoperable and inherently unreliable, I don't want to contribute.

I somewhat agree with that sentiment,

I would say your codes says otherwise and that you agree that a line
for feature testing should be drawn somewhere.

I was talking about the issue he was referring to (gEBTN for document
vs. element.)

I didn't even think of that difference. I never use
element.getElementById because an id is unique there is no real
difference (except perhaps performance by narrowing the search scope).
I agree there should be a feature test for both situations if the
particular implementation is documented to work in both situations.
For example

if (document.getElementsByTagName &&
typeof getAnElement != 'undefined' &&
getAnElement().getElementsByTagName) {

var getEBI = function(id, d) {
return (d||document).getElementById(id);
};

}

[snip]

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

Peter Michaux wrote on 09 dec 2007 in comp.lang.javascript:

On Dec 9, 1:14 am, "Evertjan." <exjxw.hannivo... (AT) interxnl (DOT) net> wrote:
Peter Michaux wrote on 09 dec 2007 in comp.lang.javascript:

// the simplest possible implementation

if (document.getElementById) {
var getEBI = function(id, d) {
return (d||document).getElementById(id);
};
}

What is the use of testing for getElementById,
as the js code will error anyway
when getEBI() is subsequently called while not defined?

The idea is to avoid errors.

A function that calls getEBI should only test for the existance of
gEBI and not document.getElementById. This is because the
implementation of getEBI may be changed and may not use
document.getElementById.

Seems a bit stupid to me, Peter.

If you plan to avoid any possible implementation change,
better not programme at all.

why not perhaps:

if (document.getElementById) {
var getEBI = function(id, d) {
return (d||document).getElementById(id);
};
} else {
var getEBI = function(id, d) {
return d.getElementById(id);
};
};



--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

On Dec 9, 8:31 am, "Evertjan." <exjxw.hannivo... (AT) interxnl (DOT) net> wrote:

Peter Michaux wrote on 09 dec 2007 in comp.lang.javascript:

On Dec 9, 1:14 am, "Evertjan." <exjxw.hannivo... (AT) interxnl (DOT) net> wrote:
Peter Michaux wrote on 09 dec 2007 in comp.lang.javascript:

// the simplest possible implementation

if (document.getElementById) {
var getEBI = function(id, d) {
return (d||document).getElementById(id);
};
}

What is the use of testing for getElementById,
as the js code will error anyway
when getEBI() is subsequently called while not defined?

The idea is to avoid errors.

A function that calls getEBI should only test for the existance of
gEBI and not document.getElementById. This is because the
implementation of getEBI may be changed and may not use
document.getElementById.

Seems a bit stupid to me, Peter.

I don't think there is any need for inflammatory words like "stupid".

If you plan to avoid any possible implementation change,
better not programme at all.

I'm not suggesting a gEBI wrapper should be written that doesn't use
getEBI. I'm speaking abou the principle that a function should only
test the features it calls directly to help to build a library in
layers with good modularity.

if (document.getElementById) {
var getEBI = function(id, d) {
return (d||document).getElementById(id);
};} else {

var getEBI = function(id, d) {
return d.getElementById(id);
};

};

This implementation confuses me a bit. What is the goal of the feature
testing in that implementation? If the else is the appropriate branch
and someone sends the second function "document" for the second
parameter it will error. Avoiding errors is the goal.

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 11:09 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

On Dec 9, 2:24 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 12:02 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

[snip]

I made a CSS selector function one time (something like
jQuery has) and I found that any

I have found that a combination of gEBI and gEBTN is all I ever need
to home in on whatever elements I need to manipulate.

I use something like a a getElementsByClassName sometimes but that
otherwise that is my limit also.

Yes, I occasionally find that useful. The biggest problem with it
(like gEBTN) is IE and other browsers that don't support XPath. It is
just too slow, so I try to avoid designs that rely on it.

[snip]





// Another implementation for developers concerned with
// the IE5 problem about doctype and comments

if (document.getElementsByTagName &&
typeof getAnElement != 'undefined' &&
getAnElement().getElementsByTagName) {

var getEBTN = function(tag, root) {
var els = root.getElementsByTagName(tag);

if (tag == '*' && !els.length && root.all) {
var all = root.all;
els = [];
for (var i=0, ilen=all.length; i<ilen; i++) {
var el = all[i];

I prefer not to declare variables inside of loops. And for long
loops, a while that counts down to 0 will be faster. Granted, you
have to reverse the results at the end.

I prefer countdown loops also but don't use them when order matters.

Is there that much of a performance hit with calling reverse on the
end result? It seemed like a good idea to me as the loop is n
operations, but the reverse is always one.

[snip]

Do you have a link to that previous discussion? If so please post it

No.

when we get to events. I didn't know such a case existed.

The source of that piece of information was Richard Cornford. The
discussion concerning splitting up addEventListener and gEBTN wrappers
was in a single thread. A search for "addEventListener" and
"getElementsByTagName" in the last two months or so should find the
posts.

The API should be considered here. A getEBTN wrapper function like the
above could be called "getByCssSelector" and the calls to getEBTN
would become a subset of the possible calls to "getByCssSelector".

If you feel we must have a getByCssSelector,

I don't think it is a must.

It certainly wouldn't bother me if we add it, but I know it is an
involved function and might not warrant the time it will take to
perfect it. I am more concerned with what gets left out than what
gets put in.

then that makes sense. I
can't imagine a scenario where I would use such a thing.

I can only imagine myself using one that takes simple selectors like
"div", "#fooId", ".fooClass" and combinations of those three. A more
complex selector is only needed if the content creator is totally
uncooperative and won't add the hooks needed by the JavaScript
programmer.

Right. So it could be argued that those three are covered by gEBI,
gEBTN and gEBCN. Any further wrapping is just syntactic sugar.

The programming of a getByCssSelector sure is fun. Probably the most

Fun?!

enjoyable thing I've programmed in JavaScript that might be useful as
it involves a CSS selector string parser and optimization is a major
priority.

Certainly could be useful for some applications, but I don't see DOM
queries as one of them.

[snip]

This is something I'd like to add to the repository eventually. I did
a couple weeks of work on these types of functions a while ago and it
is very handy for enlivening pages for unobtrusive JavaScript. (Cue
"PointedEars" for a "lemmings" comment.)

I haven't found a need for such queries and I agree with "PointedEars"

That is the fourth and a half time that has happened recently.

And I half agreed with something VK posted recently. God save us.

in that event delegation is often the best way to go anyway.

I don't see them as mutually exclusive as there are only so many

Certainly they aren't and I don't always use delegation.

elements on which to delegate and listeners concerned with different
handlers should not be combined. I really don't get what he is talking

Right.

about, he has told me I don't understand, and he is write.

Oops. Now you are agreeing with him.

Peter Michaux wrote:

On Dec 9, 1:39 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de> wrote:
Peter Michaux wrote:
Based on the repository design guidelines, the above could be
substantially reduced to just [...] Notes: There is no need to check
for the existence of "document" as no browser, NN4+ and IE4+, missing
"document". There is no need to check that document.getElementById is
a callable since there has never been a known implementation where
document.getElementById that is not callable.
If these are the guidelines for your project, to produce code that is
not interoperable and inherently unreliable,

Do you feature test everything?

I do feature-testing on occasions where I know there can be a problem if
feature-testing is not performed prior to execution. This particular one
qualifies for such an occasion:

`document' is a host-defined property of the Global Object. It depends on
the host environment whether or not it is available. Not testing for this
feature would cause the code to break (instead of simply not work) in host
environments that don't provide it or simply don't provide it under this
name. However, I would be willing to concede that code that does not test
for this property is seldom error-prone as that property was introduced
with the first versions of the languages, and implementors tend to be
backwards-compatible.

`document.getElementById' is a host-defined property of a host object. That
host object did not have that property in all previous versions of the
corresponding host environments, so it is possible that this property does
not exist in the host environment this code is exposed to. That one is
covered by the type-converting true-value test. However, the property may
have any value and therefore it is possible that it cannot be called. Not
to make the best effort possible to ensure it can be called will result in a
runtime error in environments where the property is not supported as such
or external code has overwritten/defined the value with a non-callable one.

Do you feature test that alert is callable?

Actually, I was about to implement that test because it has been reported
here that there is at least one user agent where calling it fails.

Do you feature test that string concatenation works?

No. String concatenation is a *language* feature, but one that was
introduced with the first version of the language and not with later
implementations.

Do you feature test that float division works (e.g. 1/2 is 0.5)?

Same here.

Do you feature test for the bugs in the implementation of feature "x" in
browser "y" that you have never seen?

Fallacy of many questions.

You could almost do this by an insanely laborious process of checking
things like float division in 100 different combinations before doing
float division.

Appeal to ridicule.

Hopefully you answer "no" to at least one of those question.
If so then you see that

Straw man.

the line has to be drawn somewhere.

Yes, but I don't agree with where you want to draw it.


PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>