Various DOM-related wrappers (Code Worth Recommending Project)

[Peter Michaux]

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]

 

[Peter Michaux]

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.

 

[David Mark]

On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <[email protected]>
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.

 

[Peter Michaux]

[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 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]

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.

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]

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 Michaux]

[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 Michaux]

On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <[email protected]>
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]

 

[Evertjan.]

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

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);
};
};

 

[Peter Michaux]

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




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.

 

[David Mark]

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

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.

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]

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.

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.

 

[Thomas 'PointedEars' Lahn]

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

 

[Peter Michaux]

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.

Above you stated you feature test "where you know there can be a
problem". Have you ever witnessed a problem with
document.getElementById not being callable?

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.


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.

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

[snip]

Straw man.


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

Fair enough and inevitable. I doubt we will ever agree on this.

 

[David Mark]

[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

That's interesting. How will that work?

help greatly. A documentation format has not be worked out. These are
both just as important to the project as the actual code.

It would be good a good idea to make the inline documentation as parse-
friendly as possible. Any build process for this library will require
a relational database for the meta data. It will be very time
consuming and error-prone to populate such a database manually.

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

The newsgroup never sleeps. I don't know if it hurts anything to
discuss code ahead of its introduction to the repository (even if it
turns out to be way ahead.)

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


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

I somewhat disagree with that. Skipping cookies and plug-in detection
is certainly not an issue (as those aren't requirements for most
modules.) However, I think the items related to feature detection
should be in place before the modules that will rely on them are
considered.

helps us answer frequently asked questions like "Which Ajax library

A basic Ajax module is virtually stand-alone. I don't think mine
relies on more than a couple of common functions.

should I use?" Ajax and event modules seem to be the first logical

Events are pretty much stand-alone as well. Once we get that module
in place, which should include a DOMContentLoaded simulation, it opens
up additional possibilities for feature testing. As we will see, some
functionality cannot be created reliably before the document is ready
(e.g. anything that has to add a dummy element to the body to test for
defective CSS implementations.)

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.

Post your take on XHR when you get a chance. I briefly looked at the
code in the repository and it appears you test for a couple of things
that I didn't consider in my implementation.

If we are going to talk about two things at once, I propose that the
rest of the feature detection code should be discussed at the same
time. It isn't particularly extensive and most of it was already
posted with my gEBI/gEBTN examples (e.g. isStyleCapable,
canAdjustStyle, xmlParseMode, etc.)

 

[David Mark]

On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <[email protected]>
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);
};

}

You lost me there. I was talking about the split gEBTN
implementation. I don't understand what that snippet is doing.

 

[Thomas 'PointedEars' Lahn]

On Dec 9, 1:39 am, Thomas 'PointedEars' Lahn <[email protected]>
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.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.

Above you stated you feature test "where you know there can be a
problem". Have you ever witnessed a problem with document.getElementById
not being callable?

Understand this as "where I know there is the possibility of a problem".
I don't have to have observed that event to do my best to avoid it if I
already know it is technically possible, meaning inherent to the system
I am working with. That is what I mean with your approach producing (and
promoting) non-interoperable and therefore error-prone code.

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

IIRC, Randy Webb is using or has used such one. Besides, Web browsers are
only a subset of scriptable HTML user agents which are only a subset of
scriptable user agents. Meaning also that testing something positive in a
few browsers means nothing. Secundum quid.


PointedEars

 

[David Mark]

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








Seems a bit stupid to me, Peter.

Not at all. Feature testing code in higher-level modules (and
applications) is far more concise and easier to maintain when it only
has to consider the the lower-level API interfaces. This will become
more apparent when more complex abstractions are added.

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

I don't know what that means.

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);
};

};

I definitely don't follow that.

 

[David Mark]

[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. Encapsulating these tests in a common
function seems like the most robust and concise solution.

And BTW, for some odd reason, Google keeps changing the thread subject
every time I reply. I personally don't care what it is called.

 

[Peter Michaux]

[snip]

Yes. I am working on an automated testing system now and that will

That's interesting. How will that work?

The interesting part is that the testing framework needs to limit how
much client side scripting is used as it is testing a client side
scripting library. This is so even very old browsers can be tested.

I'm using a series of communications between the client and server.
The server orchestrates everything with a series redirects from test
page to test page using redirects until all test pages have been run.

The client logs test assertions (pass and fail) to the server by
setting (new Image()).src since this is the oldest(?) way to
communicate with the server. There will be extremely old browsers that
can't do this and those browsers will require manual testing if they
are to be tested at all.

The only other requirement is that the browser can set
window.location.

I think this is the ultimate in a low tech automated system for
testing.

It would be good a good idea to make the inline documentation as parse-
friendly as possible.

Yes.

Testing has higher priority than documentation.

[snip]

I somewhat disagree with that. Skipping cookies and plug-in detection
is certainly not an issue (as those aren't requirements for most
modules.) However, I think the items related to feature detection
should be in place before the modules that will rely on them are
considered.

What I'm trying to do is focus which lower level functionality goes in
first. Lower level functionality that is required by the higher level
modules should have priority. The lower level functionality
prerequisite to a particular module will necessarily be included
before or at the time the higher level module is included.

A basic Ajax module is virtually stand-alone. I don't think mine
relies on more than a couple of common functions.


Events are pretty much stand-alone as well. Once we get that module
in place, which should include a DOMContentLoaded simulation,

I no longer think that is even possible and window.onload is the only
option.

it opens
up additional possibilities for feature testing. As we will see, some
functionality cannot be created reliably before the document is ready
(e.g. anything that has to add a dummy element to the body to test for
defective CSS implementations.)


Post your take on XHR when you get a chance.

In the next lull in the threads for the project I will post.

I briefly looked at the
code in the repository and it appears you test for a couple of things
that I didn't consider in my implementation.

If we are going to talk about two things at once, I propose that the
rest of the feature detection code should be discussed at the same
time. It isn't particularly extensive and most of it was already
posted with my gEBI/gEBTN examples (e.g. isStyleCapable,
canAdjustStyle, xmlParseMode, etc.)

I can't keep up on more than is going on right now. I didn't think
think this project would be so popular!

 

[Peter Michaux]

On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <[email protected]>
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);
};

}

You lost me there. I was talking about the split gEBTN
implementation. I don't understand what that snippet is doing.

Copy and paste got me. I think I meant the following.

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

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

}

Since the getElementById method is specified separately for Document
and Element in the DOM2 spec, a feature test for one does not assure
the other is present. A test for both is necessary if the getEBI
function is to be documented as suitable for both.

 

[David Mark]

On Dec 9, 4:39 am, Thomas 'PointedEars' Lahn <[email protected]>
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);
};
}

You lost me there. I was talking about the split gEBTN
implementation. I don't understand what that snippet is doing.

Copy and paste got me. I think I meant the following.

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

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

}

Since the getElementById method is specified separately for Document
and Element in the DOM2 spec, a feature test for one does not assure
the other is present. A test for both is necessary if the getEBI
function is to be documented as suitable for both.

I didn't split gEBI as I agree with the idea that it is useless for
anything but document nodes. gEBTN is another story, so the above
strategy would make sense for that one.

 

[Thomas 'PointedEars' Lahn]

[...] David Mark [...] wrote:
[...] Peter Michaux [...] wrote:
[...] David Mark [...] wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...]
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.)

JFTR: I was not referring to that at all.

[...] I think I meant the following.

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

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

}

The nonsense gets worse.

Since the getElementById method is specified separately for Document
and Element in the DOM2 spec,

No, it is not. I don't know which DOM 2 Spec you have been reading,
but the one I have been reading specifies only:

,-<http://www.w3.org/TR/DOM-Level-2-Core/core.html#i-Document>
|
| [...]
| interface Document : Node {
| [...]
| // Introduced in DOM Level 2:
| Element getElementById(in DOMString elementId);
| };

,-<http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-745549614>
|
| [...]
| interface Element : Node {
| readonly attribute DOMString tagName;
| DOMString getAttribute(in DOMString name);
| void setAttribute(in DOMString name,
| in DOMString value)
| raises(DOMException);
| void removeAttribute(in DOMString name)
| raises(DOMException);
| Attr getAttributeNode(in DOMString name);
| Attr setAttributeNode(in Attr newAttr)
| raises(DOMException);
| Attr removeAttributeNode(in Attr oldAttr)
| raises(DOMException);
| NodeList getElementsByTagName(in DOMString name);
| // Introduced in DOM Level 2:
| DOMString getAttributeNS(in DOMString namespaceURI,
| in DOMString localName);
| // Introduced in DOM Level 2:
| void setAttributeNS(in DOMString namespaceURI,
| in DOMString qualifiedName,
| in DOMString value)
| raises(DOMException);
| // Introduced in DOM Level 2:
| void removeAttributeNS(in DOMString namespaceURI,
| in DOMString localName)
| raises(DOMException);
| // Introduced in DOM Level 2:
| Attr getAttributeNodeNS(in DOMString namespaceURI,
| in DOMString localName);
| // Introduced in DOM Level 2:
| Attr setAttributeNodeNS(in Attr newAttr)
| raises(DOMException);
| // Introduced in DOM Level 2:
| NodeList getElementsByTagNameNS(in DOMString namespaceURI,
| in DOMString localName);
| // Introduced in DOM Level 2:
| boolean hasAttribute(in DOMString name);
| // Introduced in DOM Level 2:
| boolean hasAttributeNS(in DOMString namespaceURI,
| in DOMString localName);
| };

The item on the left is the *return type* of the method, not its
(additional) owner.

a feature test for one does not assure the other is present.
A test for both is necessary if the getEBI
function is to be documented as suitable for both.

If what you stated above were the case, a test on an arbitrary element
object would not be sufficient. But it is not the case, so that point
is rather moot.


PointedEars