P
Peter Michaux
I simply check to see if the element to be returned actually has the
appropriate id.
Ahh, ok. I thought you might be doing an elaborate DOM walk to find
the element that really has the correct id. This would have saved me
from a problem in a mashup that burned about an hour of my time last
week. In fact I think this would be a good function to have because it
fixes a bug in recent browsers. You win
But we already broke that rule with the opacity function.
The rule was a result of that experience.
It wasn't
much extra effort and I think it was worth it to make that basic
function optionally work for IE4.
I think that the time to enabled opacity on IE4 was plenty. I had to
figure out about document.all.tags and document.all[] during page load
and after. I had all sorts of browsers fired up. This sort of testing
isn't free.
[snip]
For the most part I agree. In this case, I think the name vs. id
issue is sufficient to warrant a wrapper for gEBI.
I agree. I had never even thought about writing code to fix that
problem before. It is a good idea. That is a bug that can be fixed.
It isn't exactly the question for me. But I think we've already
answered it to some extent. When it is simple to include an
additional version of a function that enables IE4
This is a grey area with the "simple". I'm looking for a consistent
rule for what to include. If a bit of code in the repository happens
to work on IE4 great but if not that is ok with me.
and somebody is
willing to write it, then it makes sense to include it. Most
applications won't need it, but why not have it available for those
that do?
I suppose it comes down to the fact that I'll probably have to write
the documentation, tests and almost certainly maintain it. These are
big time commitments. I'm not interested for IE4 having enhanced
JavaScript pages. Just HTML is fine.
Those who don't use the alternate versions of getAnElement, etc. won't
incur the extra download time. Other than that one and the gEBI
wrapper, I don't have any additional functions that warrant
alternative IE4-friendly versions. My gEBTN wrapper fixes a problem
with IE5.x as well. And other than that, I can't think of anything
else I've written that specifically addresses pre-IE6 issues.
Ok! I see a solution. So you need only two functions to help you
support IE4 at the level that satisfies you (but perhaps not someone
else). If the gEBID wrapper is included in the library to fix the IE5+
bug then there is only one issue for you: getAnElement.
I never intended that the repository would have all the multiple
implementations possible. The repository should have the ones that are
commonly used. A developer using the repository may have extenuating
circumstances that require an implementation not suitable to whatever
the guidelines are for the repository. The developer is free to
maintain an implementation of a particular function outside the
repository and include it in his build process. This is what I
envisioned from the beginning.
So if you were going to use the repository you would just maintain
your own getAnElement. That is just one function outside the
repository. How does that sound?
I kind of mucked up that explanation. You would need to maintain your
own gEBID and getAnElement to have your level of support for IE4. The
logic that a developer with uncommon requirements maintains his own
implementations was the point.
Peter