Strictly, that should be this.document, which is why I always assign
that to a variable named "doc" at the top of each module.
[begin quotations from a previous post]
David said:
One reason is that it is shorter than this.document. Referring to it
as "document" alone implies that such a global property exists
(typically a good assumption in a browser, but not the best practice
as it will error otherwise.)
[end quotations from a previous post]
I don't understand your argument for a few reasons but most
importantly there seems to be a logical inconstancy. If you write "var
doc = this.document" in the global scope and then check for "doc"
later you are doing exactly what I am doing when I check "typeof
document != 'undefined'". If there is any chance that your "doc" could
be shadowed in another scope, the same chance exists for "document".
You also state that "this is typically a good assumption in a browser"
and this is a body of code specifically for browsers.
I think that all of these functions should pass JSLint.
I don't.
JSLint is not an ECMAScript v3 validator.
For example, give JSLint the script "new Foo();" and it actually
cannot continue even though the script is a valid ExpressionStatement.
I know it will complain that is an implied global.
If I give JSLint the script "alert('a')" it complains about an implied
global. I don't think writing that script is risky for a browser
environment.
If you click the "Assume a brower" box in JSLint then the implied
global warnings for "document" and "alert" go away.
Give JSLint the script "var a = new Foo();" and it complains about an
implied global but I may know that my target host has a "Foo" or that
I declared it elsewhere.
Obviously in the context of a
function running in the global context that already checked the
existence of a global document property, it is a moot point, but I
still think it should be made to pass. That way there is no need to
document any ignored errors.
JSLint "errors" are not necessarily ECMAScript errors. I wouldn't
document what JSLint has to say. Try turning on Firefox's strict
warnings and see all its warnings about the valid ECMAScript.
Development tools should help develop code but not dictate the code.
Another style point is that variables shouldn't be declared inside if
blocks. I think JSLint complains about that too.
I believe JSLint used to complain about this but it doesn't today. For
example,
function a() {
if (true) {
var b = 1;
}
}
seems to be ok with JSLint. So if my memory is correct, JSLint is a
moving target.
The only reason I can see to avoid declaring variables inside a set of
curly brackets that are not a function body, is because of experience/
baggage coming from programming in another language.
I also think assignment in conditionals can be very handy and elegant
for if-else-else... statements.
JSLint is a great tool to learn what another JavaScript programmer
thinks is good style but I certainly don't agree with many of
Crockford's opinions.
// -------------------------------------
// (I know I went a bit extreme on the short identifiers)
if (typeof document != 'undefined') {
var getAnElement = (function() {
var g = 'getElementsByTagName',
t = d.documentElement ||
// The following line doesn't seem to add any benefit
// in any of the tested browsers.
// ((t=d.all) && t.tags && (t=t.tags('html')) && t[0])
||
(d[g] && d[g]('html')[0]);
if (!t && d.all && (t=d.all[0])) {
t = d.all[(t.tagName == '!')?1:0] || null;
if (t &&
t.tagName.toLowerCase() != 'html' &&
// for during load in IE4
t.tagName.toLowerCase() != 'head') {
I changed my version of htmlElement to check that a second parameter
(bAnyElement) isn't truthy here, which allows it to return anything it
finds at position 1. If you want to keep it as getAnElement, you
could use a tag parameter that if present would dictate what tag is
allowed. Or perhaps you want to break this up into two functions?
I would break this into two functions.
And speaking of base functions, I do think we should have wrappers for
gEBI
NOOOOOOOOOOoooooooooo............. ;-)
[begin quotations from a previous post]
I'd say that makes sense.
[end quotations from a previous post]
You can see my confusion on your stance here. This will likely not a
affect many functions but this is an important design decision. This
is the perfect place for me to lean on the "many implementations"
philosophy.
A web page is going to work with just plain HTML and no JavaScirpt
because that is the right way to build a web page. We choose to
enhance some web pages with JavaScript if the features of the browser
meet some feature threshold. We decide what features are required
based on what we know about the history of browsers.
Browsers without document.getElementById are old and/or not common. By
choosing to not enhance pages in these browsers we are reducing the
code base size and complexity with almost no impact on the user
population. Other than trivial enhancements supporting fallbacks to
document.getElementById will not result in enhanced pages anyway as
the more modern feature requirements will not exist. I also agree with
Thomas Lahn (I can't believe I wrote that!) that if the code supports
IE4 it should probably also support NN4.
Not that this should necessarily mean much but worrying about
fallbacks for document.getElementById will make the code look archaic.
So this is where multiple implementations come in. It is possible to
have implementations of functions that do and don't allow for
document.getElementById fallbacks. This doubles the code in the
repository for some functions. Unfortunately that means more
maintenance and it is more maintanence for no real practical benefit
in my mind.
For the time being, I am going to commit code to the repository that
follows this design principle.
==============
Code in this repository should not make any special concessions to
enable functionality in browsers older than IE5 or NN6.
==============
I hope this doesn't scare anyone off but it seems well within the
range of sensible to me given how few users this will impact. By the
way, I lay awake thinking about this for quite a while.
By the time this repository is ready (>8 years after IE5 and NN6 were
released), if implementations of functions that do support IE4 and NN4
are really wanted by the group then they can be added to the
repository.
[snip]
Peter
;