innerHTML support?

[kaeli]

Hey all,

AFAIR, innerHTML started as MS proprietary, but Mozilla implemented it
as well. Does anyone know if any other browsers support it? It is not in
the W3C DOM, is it? A quick GIS seemed to answer 'no' to that, but you
guys are better at finding these things than I am. ;)

This page seems to think Opera 7, Safari, and IE Mac are cool with it
too, and it seems to be faster. It also implies that innerHTML is NOT in
the W3C DOM. Is this right?
http://www.quirksmode.org/dom/innerhtml.html

Anyone have any caveats about innerHTML? When should it be used? When
should DOM methods be used instead?
Most importantly, do the browsers implement it the same?

TIA

--
--
~kaeli~
Do not taunt Happy Fun Ball!
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Lasse Reichstein Nielsen]

kaeli <ti******@NOSPA M.comcast.net> writes:

AFAIR, innerHTML started as MS proprietary, but Mozilla implemented it
as well. Does anyone know if any other browsers support it?
Opera 7 and Safari/Konqueror that I know of.
It is not in the W3C DOM, is it?
No.
This page seems to think Opera 7, Safari, and IE Mac are cool with it
too, and it seems to be faster.
Yes, IE (any version since IE 4), Mozilla (any Gecko based browser),
KHTML-based browsers (Konqueror and Safari) and Opera 7. That's the
ones I am certain of too.

Hmm. Faster than? :)
It also implies that innerHTML is NOT in the W3C DOM. Is this right?
http://www.quirksmode.org/dom/innerhtml.html
Absolutely.
Anyone have any caveats about innerHTML?
It's not standard. It could be slower than creating the nodes directly,
but in current Javascript, the interpretive overhead of the script
itself is worse than the parsing of HTML. That can change, probably
not significantly so.

My real dislike is for passing around unparsed HTML, for much the same
reason that I dislike using "eval": It's error prone.

You can make invalid HTML (or even plain syntactically wrong "HTML")
and enter it into an otherwise validating page, and *no* amount of
validation will tell you that. At least, when using DOM methods,
you can only make properly nested elements.

The method I recommend for adding predictable document fragments to a
page faster than with DOM methods, is to put them in the page to begin
with, inside a hidden element, and either move them or clone them when
you need it.

On the other hand, DOM methods work fine in most cases, unless you
are building humongous documents dynamically (and then innerHTML can
be slow too if used improperly).
When should it be used?
When you know the target audience will only use browsers that supports
it (including future browsers :)
When should DOM methods be used instead?
I'd say all the time, but I'm a known purist :)

On the other hand, I would never do large amounts of work with the DOM
methods directly. They are simply too verbose. I usually have utility
functions that makes it easier to build larger structures
Most importantly, do the browsers implement it the same?

Almost.

Error correction is ofcourse different, but for valid, tag-complete
HTML, the results are mostly the same. There are probably a few
more exceptions, but the only one I can remember is:
In IE, on most table-related elements the innerHTML property is
read-only (not TD and TH, but pretty much the rest).

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

[kaeli]

In article <y8**********@h otpop.com>, lr*@hotpop.com enlightened us
with...

This page seems to think Opera 7, Safari, and IE Mac are cool with it
too, and it seems to be faster.
Yes, IE (any version since IE 4), Mozilla (any Gecko based browser),
KHTML-based browsers (Konqueror and Safari) and Opera 7. That's the
ones I am certain of too.

Hmm. Faster than? :)

It also implies that innerHTML is NOT in the W3C DOM. Is this right?
http://www.quirksmode.org/dom/innerhtml.html

If you look at the page, it compared rendering times of innerHTML vs.
Dom methods. The innerHTML won for pretty much all of them.

My real dislike is for passing around unparsed HTML, for much the same
reason that I dislike using "eval": It's error prone.
I really didn't think of that. That's a great point.
I don't use it myself, but I see solutions posted here and in other
forums that use it and I am always wondering just how good those
solutions are.

When should it be used?
When you know the target audience will only use browsers that supports
it (including future browsers :)

Well, that about takes care of that, doesn't it? ;)

When should DOM methods be used instead?

I'd say all the time, but I'm a known purist :)

Yeah, me too, that's why I was wondering. Sometimes, I'm TOO much of a
code-snob, for want of a better term. I'm really good at
overcomplicatin g things sometimes. *heh*

--
--
~kaeli~
When a clock is hungry, it goes back four seconds.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Jim Ley]

On Mon, 19 Jul 2004 22:16:53 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

You can make invalid HTML (or even plain syntactically wrong "HTML")
and enter it into an otherwise validating page, and *no* amount of
validation will tell you that. At least, when using DOM methods,
you can only make properly nested elements.

No you can't, you can easily make an invalid DOM - for example we
often got people complaining about the TBODY required when making a
table in IE - that's not because it errored when it appended a TR to a
TABLE (which isn't valid in HTML) but because it just didn't display.
That isn't possible with innerHTML - since innerHTML will use the
implied rules from the dtd to include it.

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

[Lasse Reichstein Nielsen]

ji*@jibbering.c om (Jim Ley) writes:

On Mon, 19 Jul 2004 22:16:53 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

At least, when using DOM methods, you can only make properly nested
elements.
No you can't, you can easily make an invalid DOM

When I said "properly nested", I only meant that you can't create
the equivalent of "<b><i>somethin g</b></i>". You can easily
create (properly) nested elements that are not valid HTML, like
the <tr> not inside a <tbody> (which have also bitten me once :).
That isn't possible with innerHTML - since innerHTML will use the
implied rules from the dtd to include it.

True. So innerHTML allows people to write HTML as they are used
to, without understanding the structure of the HTML DOM. Whether
that is good or not, I'm not sure. Obviously, people like it :)
Something that does annoy me with innerHTML is that it doesn't
allow for appending. Doing "element.innerH TML+='<some html>';"
unparse and reparses the current content of the element, removing
any non-standard properties that might have been assigned to
the DOM nodes. IE has insertAdjacentH TML which solves that
problem, but which isn't implemented in, e.g., Mozilla.

The optimal combination of DOM and innerHTML would be a function:
parseHTML(Strin g) : DocumentFragmen t
(I've said that before, and you pointed out that it exists in the
Adobe SVG DOM (and probably will be in SVG DOM 1.2) as parseXML[1],
right?)

/L
[1] I can see that it historically belongs to the "window" object,
but it would be much prettier as a method of the document object,
so it doesn't need the documnet as argument.
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Jim Ley]

On Mon, 19 Jul 2004 23:41:55 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

When I said "properly nested", I only meant that you can't create
the equivalent of "<b><i>somethin g</b></i>".
Ah, but with innerHTML, that would get fixed up so the DOM structure
you were entering would be a valid DOM (if ridiculous)
Something that does annoy me with innerHTML is that it doesn't
allow for appending. Doing "element.innerH TML+='<some html>';"
+1
Adobe SVG DOM (and probably will be in SVG DOM 1.2) as parseXML[1],
right?)
[1] I can see that it historically belongs to the "window" object,
but it would be much prettier as a method of the document object,
so it doesn't need the documnet as argument.

Then you couldn't use it to create a new document in one go. parseXML
takes a 2nd property which is the document to parse it in the context
of, if you leave it off you get a newly created one.

so:
doc=parseXML("< svg><!-- stuff --></svg>");

is the same as what would you'd get with something like

doc=new SVGDocument();
doc.parseXML("< svg><!-- stuff --></svg>");

so you still need some non-document interface to create the new
object, so I think you might aswell have it one go.

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

[Richard Cornford]

Lasse Reichstein Nielsen wrote:

kaeli writes:

AFAIR, innerHTML started as MS proprietary, but Mozilla
implemented it as well. Does anyone know if any other
browsers support it?

Opera 7 and Safari/Konqueror that I know of.

<snip>

You can definitely add IceBrowser 5 to that list.

When should it be used?

When you know the target audience will only use
browsers that supports it (including future browsers :)

<snip>

With designed clean degradation and an effective/reliable test for
(dynamic) innerHTML support surly there is no need to know that the
client browser supports it.

Richard.

[Lasse Reichstein Nielsen]

ji*@jibbering.c om (Jim Ley) writes:

On Mon, 19 Jul 2004 23:41:55 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

When I said "properly nested", I only meant that you can't create
the equivalent of "<b><i>somethin g</b></i>".
Ah, but with innerHTML, that would get fixed up so the DOM structure
you were entering would be a valid DOM (if ridiculous)

I wish. IE 6 actually creates a royal mess, where a node can end up
being the sibling of its grandfather (example at:
<URL:http://ln.hixie.ch/?start=10379104 67&count=1>).
Then you couldn't use it to create a new document in one go. parseXML
takes a 2nd property which is the document to parse it in the context
of, if you leave it off you get a newly created one.
So parseXML can either return a DocumentFragmen t or a Document. I
would prefer consistency rather than brevity, but I can accept it as a
reason :)
so:
doc=parseXML("< svg><!-- stuff --></svg>");

is the same as what would you'd get with something like

doc=new SVGDocument();
doc.parseXML("< svg><!-- stuff --></svg>");
The last line would probably be:
doc.appendChild (doc,parseXML(" <svg><!-- stuff --></svg>"));
(which doesn't help my point :)
so you still need some non-document interface to create the new
object, so I think you might aswell have it one go.

But now you have two ways to create a new document, and one of them
only creates a new document some times.

What happens if the argument is not a valid SVG document content,
but still a valid fragment? No, I still prefer one function for
each distinct operation, and only one. It makes mistakes harder
to make.

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

[Jim Ley]

On Tue, 20 Jul 2004 02:24:58 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

What happens if the argument is not a valid SVG document content,
but still a valid fragment?
Not sure what you mean, they're all just XML document - there's no
restriction on XML - SVG has little notion of a valid document, since
any SVG can contain any WF XML.
No, I still prefer one function for
each distinct operation, and only one. It makes mistakes harder
to make.

Your scripts just get too big, and too slow. I want convenience
methods - you're going to write them anyway, better then be in native.

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

[Lasse Reichstein Nielsen]

ji*@jibbering.c om (Jim Ley) writes:

On Tue, 20 Jul 2004 02:24:58 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

What happens if the argument is not a valid SVG document content,
but still a valid fragment?
Not sure what you mean, they're all just XML document - there's no
restriction on XML - SVG has little notion of a valid document, since
any SVG can contain any WF XML.

I thought an SVG-fragment should be delimited by <svg> and </svg> tags.
So the question would be, what is:
parseXML("<g></g>")
?
It's easy to parse "<g></g>" into a DocumentFragmen t, but can it be
an SVGDocument (and will parseXML generate an SVGDocument and not
some other Document)?
Your scripts just get too big, and too slow. I want convenience
methods - you're going to write them anyway, better then be in native.

Indeed, it's all about hitting the right level of abstraction.
I prefer clear boundaries between features to overloaded convenience
operations, but I can see why convenience is convenient :)

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