Changing built in methods for browser compatibility

[Trenqo 0]

Instead of doing repetitive checks throughout my code, or defining new
methods that won't work unless they are included, I have taken the
approach of redefining existing methods in order to make them as cross
browser compatible as possible.

For example:

if(!document.getElementById)
{
if(document.all)
document.getElementById = function(id) { return document.all[id]; }
else if(document.layers)
document.getElementById = function(id) { return
document.layers[id]; }
else
browserUnsupported()
}

I have a few other similar methods in a crossbrowser.js file, which I
include in every html file I create.

However, I am stumped on how to make a similar redefined method for
"addEventListener" and other methods to be added to each html element.

I was hoping to be able to add it through a prototype to the root
HTMLElement type. Unfortunately, that doesn't seem to propagate the
changes to all the subtypes such as "span" (HTMLSpanElement). I can
however add it directly to the HTMLSpanElement and it works.

I guess that I can make an array of all the element prototypes, and
then cycle through that adding whatever methods I want to each element.
However, if there is a better, less kludgy way to do this, I'd like to
know about it.

Also, I'm curious of other's opinions of this approach and its
disadvantages compared to traditional cross browser compatibility
approaches.

Finally, if someone else has done something similar, it could be very
helpful if they uploaded to linked to their code, so that I don't
repeat something that has already been done.

 

[ASM]

Instead of doing repetitive checks throughout my code, or defining new
methods that won't work unless they are included, I have taken the
approach of redefining existing methods in order to make them as cross
browser compatible as possible.

For example:

n=document.all?'ie':document.getElementById?'dom':document.layers?'nn':'';

function getElemByDiv(divId) {
var d = n=='ie'&&n!=dom? document.all(divname) :
n=='dom'? document.getElementById(divname) :
n=='nn'? document.layers[divname] :
'';
return d
}

function changeStyleDiv(divId,styl,attr,u) {
var d = getElemByDiv(divname);
d = n='nn'? d : d.style;
u = n='nn'? '' : u;
d.styl = attr+u;
}

then you need to know if you're addressing to tree of :
- images
- links
- forms

I do not think you can reach a span with NN4 ( ? )

I have a few other similar methods in a crossbrowser.js file, which I
include in every html file I create.

if the are few -> OK
(not join a lot)

Finally, if someone else has done something similar, it could be very
helpful if they uploaded to linked to their code, so that I don't
repeat something that has already been done.

It'll not me
I prefer specific funtions

 

[ASM]

Your identifiers are misleading in that IE is not the only browser that
supports document.all

Did somebody says that 'ie' means "There is IE" ? ?
it means what it means : "supports document.all"

function getElemByDiv(divId) {
var d = n=='ie'&&n!=dom? document.all(divname) :
n=='dom'? document.getElementById(divname) :
n=='nn'? document.layers[divname] :
'';
return d
}

That function, as written, will not work in NN4.xx series browsers on a
layer tag that is nested within another layer.

right :-(

then you need to know if you're addressing to tree of :
- images

document.images['imageName']. no need for any other code as just about
every JS browser supports the images collection.

I would have to say
firstable you need to adress to correct tree if exits
then, if not, you try to call by ID

But, who supports NN4 anymore?

Nigerian people ? south south-america ?
Me ?

 

[fox]

Instead of doing repetitive checks throughout my code, or defining new
methods that won't work unless they are included, I have taken the
approach of redefining existing methods in order to make them as cross
browser compatible as possible.

For example:

if(!document.getElementById)
{
if(document.all)
document.getElementById = function(id) { return document.all[id]; }
else if(document.layers)
document.getElementById = function(id) { return
document.layers[id]; }
else
browserUnsupported()
}

I have a few other similar methods in a crossbrowser.js file, which I
include in every html file I create.

However, I am stumped on how to make a similar redefined method for
"addEventListener" and other methods to be added to each html element.

Here's a demo:

http://fxmahoney.com/demo/layer_addlistener.htm

view source...
and visit with NN4...

there's a version of document.getElementById that recurses all layers
(just in case you have embedded layers)

as for other "methods" in NN4, use *watch* (there is an example of using
style.left and setting clientLeft at the same time). When you click on
the rectangle, it will move +5 to the right by setting
layerref.style.left as you would newer browsers. You should be able to
take it from there... just pay attention to how attributes work in
modern browsers.

I was hoping to be able to add it through a prototype to the root
HTMLElement type. Unfortunately, that doesn't seem to propagate the
changes to all the subtypes such as "span" (HTMLSpanElement). I can
however add it directly to the HTMLSpanElement and it works.

I guess that I can make an array of all the element prototypes, and
then cycle through that adding whatever methods I want to each element.
However, if there is a better, less kludgy way to do this, I'd like to
know about it.

Also, I'm curious of other's opinions of this approach and its
disadvantages compared to traditional cross browser compatibility
approaches.

Bob Clary at Netscape, back in '02, thought this was the "way to go" too.

 

[Michael Winter]

Instead of [...] defining new methods that won't work unless they are
included, I have taken the approach of redefining existing methods in
order to make them as cross browser compatible as possible.

Exactly how do these two things differ? If you don't include either set
of code - the wrappers or new methods - then you're likely to end up
with failure. A well-designed collection of re-usable code can be small
and fast, so there's no reason why you can't include it wherever necessary.

For example:

if(!document.getElementById)
{
if(document.all)
[...]
else
browserUnsupported()
}

Exactly what do you intend for this browserUnsupported function? It
certainly doesn't seem to be a flexible way of affording graceful
degradation, which is certainly something you should provide if you're
designing for cross-browser compatibility.

To me, the final else clause should always return null so that a call is
still meaningful, even if it doesn't provide you with the object
reference you were looking for. When that failure condition occurs, the
calling code can then choose how to handle it. You could also attach a
flag to this final function to indicate that it never succeed, which
might be useful when you need to distinguish between failure due to lack
of support, and failure due to a missing element.

[snip]

However, I am stumped on how to make a similar redefined method for
"addEventListener" and other methods to be added to each html
element.

You cannot, at least not if you're goal is compatibility.

I was hoping to be able to add it through a prototype to the root
HTMLElement type.

As far as I know, only Mozilla and Opera 8 allow modification of host
objects through a prototype object, and these browsers will already
support much (perhaps all) of what you will try to emulate anyway.

Unfortunately, that doesn't seem to propagate the changes to all the
subtypes such as "span" (HTMLSpanElement).

It does in at least the two browsers I mention, but IE, for example,
doesn't provide either a HTMLElement interface, or a prototype property,
on its host objects.

[snip]

Also, I'm curious of other's opinions of this approach and its
disadvantages compared to traditional cross browser compatibility
approaches.

Well I'd say it's doomed to failure as the browsers which do not support
DOM methods are typically the ones that don't allow extensions to their
host objects. You're limited to defining new objects and methods in
those cases.

As has been mentioned in other recent threads, you need to be careful
that you don't end up producing massive libraries and sending them
as-is. I do have some code which is similar to what you have in mind,
but whenever it's used, it's trimmed down to only what's needed, then
run through a code minimiser to strip out the comments and whitespace
that existed in the original.

[snip]

Mike