Browser compatibility

[Simon Wigzell]

I cobbled together the following function from examples on the internet to
set named spanned items in the parent form. It works fine for IE but not at
all for netscape. What other browser conditions do I need to test for and
what is the correct syntax for the
sode so that I am covered for all cases? Thanks!

function WriteContent(na me, newText)
{
var browser=navigat or.appName
var version=parseIn t(navigator.app Version)

if (browser=="Micr osoft Internet Explorer")
eval("self.open er.document.all ."+name+".inner HTML='"+newText +"'");
else
{
self.opener.doc ument.layers[name].document.close ();
self.opener.doc ument.layers[name].document.write (newText);
self.opener.doc ument.layers[name].document.close ();
}
}

[HikksNotAtHome]

Re: Browser compatibility

In article <3fytb.399968$6 C4.164347@pd7tw 1no>, "Simon Wigzell"
<simonwigzell@s haw.ca> writes:
[color=blue]
>
>I cobbled together the following function from examples on the internet to
>set named spanned items in the parent form. It works fine for IE but not at
>all for netscape. What other browser conditions do I need to test for and
>what is the correct syntax for the
>sode so that I am covered for all cases? Thanks!
>
>function WriteContent(na me, newText)
> {
> var browser=navigat or.appName
> var version=parseIn t(navigator.app Version)[/color]

ditch the unreliable .appName and .appVersion
[color=blue]
> if (browser=="Micr osoft Internet Explorer")
> eval("self.open er.document.all ."+name+".inner HTML='"+newText +"'");[/color]

no eval needed:
self.opener.doc ument.all[name].innerHTML =
[color=blue]
> else
> {
> self.opener.doc ument.layers[name].document.close ();
> self.opener.doc ument.layers[name].document.write (newText);
> self.opener.doc ument.layers[name].document.close ();
> }
> }
>
>[/color]

You cover document.all and document.layers , what about the modern browsers that
use getElementById?

Note the lack of concern about the browser:

function WriteContent(na me, newText){
if (document.getEl ementById)
{
//use getElementById
self.opener.doc ument.getElemen tById(name).inn erHTML = newText;
//inserting text via innerHTML is inefficient when compared to DOM
//methods.
}
else
{
if (document.all)
{
self.opener.doc ument.all[name].innerHTML = newText;
}
else
{
if (document.layer s)
{
//document.layers statements here
}
else
{
alert('You're browser seems not to support dynamic content insertion');
}
}
}

And absolutely *no* concern about what browser it is, but what features it
supports.

http://www.jibbering.com/faq/#FAQ4_26

As a side note:
alert(navigator .appName)

when executed in the AOL browser gives "Microsoft Internet Explorer" but it is
far from being the same browser. And goes to show the fallacy of relying on
..appName when trying to determine my browser.
--
Randy

[Simon Wigzell]

Re: Browser compatibility


"HikksNotAtHome " <hikksnotathome @aol.com> wrote in message
news:2003111518 2907.29815.0000 1725@mb-m21.aol.com...[color=blue]
> In article <3fytb.399968$6 C4.164347@pd7tw 1no>, "Simon Wigzell"
> <simonwigzell@s haw.ca> writes:
>[color=green]
> >
> >I cobbled together the following function from examples on the internet[/color][/color]
to[color=blue][color=green]
> >set named spanned items in the parent form. It works fine for IE but not[/color][/color]
at[color=blue][color=green]
> >all for netscape. What other browser conditions do I need to test for and
> >what is the correct syntax for the
> >sode so that I am covered for all cases? Thanks!
> >
> >function WriteContent(na me, newText)
> > {
> > var browser=navigat or.appName
> > var version=parseIn t(navigator.app Version)[/color]
>
> ditch the unreliable .appName and .appVersion
>[color=green]
> > if (browser=="Micr osoft Internet Explorer")
> > eval("self.open er.document.all ."+name+".inner HTML='"+newText +"'");[/color]
>
> no eval needed:
> self.opener.doc ument.all[name].innerHTML =
>[color=green]
> > else
> > {
> > self.opener.doc ument.layers[name].document.close ();
> > self.opener.doc ument.layers[name].document.write (newText);
> > self.opener.doc ument.layers[name].document.close ();
> > }
> > }
> >
> >[/color]
>
> You cover document.all and document.layers , what about the modern browsers[/color]
that[color=blue]
> use getElementById?
>
> Note the lack of concern about the browser:
>
> function WriteContent(na me, newText){
> if (document.getEl ementById)
> {
> //use getElementById
> self.opener.doc ument.getElemen tById(name).inn erHTML = newText;
> //inserting text via innerHTML is inefficient when compared to DOM
> //methods.
> }
> else
> {
> if (document.all)
> {
> self.opener.doc ument.all[name].innerHTML = newText;
> }
> else
> {
> if (document.layer s)
> {
> //document.layers statements here
> }
> else
> {
> alert('You're browser seems not to support dynamic content[/color]
insertion');[color=blue]
> }
> }
> }
>
> And absolutely *no* concern about what browser it is, but what features it
> supports.
> http://www.jibbering.com/faq/#FAQ4_26
>
> As a side note:
> alert(navigator .appName)
>
> when executed in the AOL browser gives "Microsoft Internet Explorer" but[/color]
it is[color=blue]
> far from being the same browser. And goes to show the fallacy of relying[/color]
on[color=blue]
> .appName when trying to determine my browser.
> --
> Randy[/color]

Thanks! Looks like a big improvement on what I had.

[Lasse Reichstein Nielsen]

Re: Browser compatibility

"Simon Wigzell" <simonwigzell@s haw.ca> writes:
[color=blue]
> I cobbled together the following function from examples on the internet to
> set named spanned items in the parent form.[/color]

The worst part of the internet is that there is no quality control :)
[color=blue]
> It works fine for IE but not at all for netscape. What other browser
> conditions do I need to test for and what is the correct syntax for
> the sode so that I am covered for all cases?[/color]

All cases would include Javascript not being available, or that
changing the document content isn't possible at all. I guess you are
excluding these cases.
[color=blue]
> function WriteContent(na me, newText)
> {
> var browser=navigat or.appName
> var version=parseIn t(navigator.app Version)[/color]

If you want to use a property or object, test for it specifically
instead of trying to guess the browser version.
[color=blue]
>
> if (browser=="Micr osoft Internet Explorer")
> eval("self.open er.document.all ."+name+".inner HTML='"+newText +"'");[/color]

You should never use eval for accessing properties or variables. You
will probably never need to use eval at all. The exceptions are few
and rare, and it is a safe bet that you won't hit them.
This is (almost) equivalent and *much* more effective:
self.opener.doc ument.all[name].innerHTML=newT ext;

The "almost" refers to the case where the value of newText contains a
single quote ('). In that case, the eval version fails.
[color=blue]
> else
> {
> self.opener.doc ument.layers[name].document.close ();[/color]

document.layers only exist in Netscape 4. Netscape 6+ is a complete
rewrite (it is a branded version of the Mozilla browser) and is not
compatible with Netscape 4.
[color=blue]
> self.opener.doc ument.layers[name].document.write (newText);
> self.opener.doc ument.layers[name].document.close ();
> }
> }[/color]

If newText contains a text string, and not HTML, then use the following:

---
function getElem(doc,id) {
if (doc.getElement ById) {
return doc.getElementB yId(id);
} else if (doc.all) {
return doc.all[id];
} else if (doc.layers) {
return doc.layers[id];
}
return null; // this is not happening
}

function writeContent(na me,newText) {
var doc = opener.document ;
var elem = getElem(doc,nam e);
if (doc.createText Node) { // Modern browsers
var text = doc.createTextN ode(newText);
while(elem.hasC hildNodes()) {
elem.removeChil d(elem.lastChil d);
}
elem.appendChil d(text);
} else if (elem.innerHTML ) { // IE 4
elem.innerHTML = newText; // Maybe use .innerText
} else if (elem.document != doc) { // NS 4
elem.document.o pen();
elem.document.w rite(newText);
elem.document.c lose();
}
}
---
No reference to browser name or version.
If newText contains HTML, you will have to drop the first method,
or parse the HTML yourself.
Tested in Netscape 4, Mozilla FB 0.7, IE 6, and Opera 7

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[David Leverton]

Re: Browser compatibility

HikksNotAtHome wrote:

[snip][color=blue]
> if (document.getEl ementById)
> {
> //use getElementById
> self.opener.doc ument.getElemen tById(name).inn erHTML = newText;
> //inserting text via innerHTML is inefficient when compared to DOM
> //methods.
> }[/color]
[snip]

Where in the DOM standard is innerHTML defined? I can't find it anywhere.

[Lasse Reichstein Nielsen]

Re: Browser compatibility

David Leverton <u01drl3@abdn.a c.uk> writes:
[color=blue]
> Where in the DOM standard is innerHTML defined? I can't find it anywhere.[/color]

It isn't. The property "innerHTML" was invented by Microsoft. Web
authors liked it, so some other browsers (Mozilla and Opera 7) have
also implemented it to preserve compatability with existing pages.
It is not official DOM.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Douglas Crockford]

Re: Browser compatibility

> Where in the DOM standard is innerHTML defined? I can't find it anywhere.

It is not a standard DOM feature, but it is necessary feature because it give
you access to the HTML parser. It is a Microsoft feature, which has also been
adopted by Mozilla and others.

http://www.crockford.com/

[Lasse Reichstein Nielsen]

Re: Browser compatibility

"Douglas Crockford" <nospam@laserli nk.net> writes:

[innerHTML][color=blue]
> It is not a standard DOM feature, but it is necessary feature because it give
> you access to the HTML parser.[/color]

I don't see why that is necessary. Handy, yes, but necessary?

I would prefer a function with a type like:
DocumentFragmen t parseHTML(Strin g)
That would fit much better with the official DOM functions.

Well, maybe in DOM v3 :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[HikksNotAtHome]

Re: Browser compatibility

In article <bp7ldn$oo2$1@n ews.abdn.ac.uk> , David Leverton <u01drl3@abdn.a c.uk>
writes:
[color=blue]
>Where in the DOM standard is innerHTML defined? I can't find it anywhere.[/color]

You can't find it because its an addon that was initiated by MS and adopted by
several other browser manufacturers.
--
Randy

[HikksNotAtHome]

Re: Browser compatibility

In article <oevcw66z.fsf@h otpop.com>, Lasse Reichstein Nielsen <lrn@hotpop.com >
writes:
[color=blue]
>[innerHTML][color=green]
>> It is not a standard DOM feature, but it is necessary feature because it[/color]
>give[color=green]
>> you access to the HTML parser.[/color]
>
>I don't see why that is necessary. Handy, yes, but necessary?
>
>I would prefer a function with a type like:
> DocumentFragmen t parseHTML(Strin g)
>That would fit much better with the official DOM functions.[/color]

I would too. But until one comes about, we are kind of stuck with what we have
to use :-(
--
Randy

[Yann-Erwan Perio]

Re: Browser compatibility

Lasse Reichstein Nielsen wrote:
[color=blue]
> [innerHTML][/color]
[color=blue]
> I would prefer a function with a type like:
> DocumentFragmen t parseHTML(Strin g)
> That would fit much better with the official DOM functions.[/color]

Though I really like innerHTML, I can only agree to your suggestion.
FWIW, Mozilla has extended the Range model adding several useful
features, like the createContextua lFragment method, which does exactly
what you suggest.

<URL: http://www.mozilla.org/docs/dom/domref/dom_range_ref26 .html#1005287>


Regards,
Yep.

[Jim Ley]

Re: Browser compatibility

On Sun, 16 Nov 2003 18:53:40 +0100, Lasse Reichstein Nielsen
<lrn@hotpop.com > wrote:
[color=blue]
>"Douglas Crockford" <nospam@laserli nk.net> writes:[color=green]
>> It is not a standard DOM feature, but it is necessary feature because it give
>> you access to the HTML parser.[/color]
>
>I don't see why that is necessary. Handy, yes, but necessary?[/color]
[color=blue]
>I would prefer a function with a type like:
> DocumentFragmen t parseHTML(Strin g)[/color]

You would also need a serialiser... Which is the other thing it does
of course. DocumentFragmen t is also problematical (at least it's
proven so in SVG where parseXML exists), then you'd need to provide a
document context, which would mean you'd naturally need the method off
document, or maybe on every single element? none of it sounds that
neat from a JS perspective, I'm sure if it was simple we wouldn't be
waiting until DOM 3 - of course DOM-3 isn't that relevant to HTML
authoring, but in XML based stuff.
[color=blue]
>That would fit much better with the official DOM functions.[/color]

Yes, but remember the official DOM are language agnostic, so they
often have to fit with things that don't make for neat javascript.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/