if I wanted to never use innerHTML, what else would I use?

R

RobG

Jake said:
In the course of my research I stumbled upon this article by Alex
Russel and Tim Scarfe:

http://www.developer-x.com/content/innerhtml/default.html

The case is made that innerHTML should never be used.

That's not what I understood from the article. I think it suggests that
innerHTML has its uses but should not be abused.

I'm wondering, If
I wanted all the content of BODY as a string, how else could I get
except through innerHTML?

There is the DOM 3 Load and Save module:

"...defines the Document Object Model Load and Save Level 3, a
platform- and language-neutral interface that allows programs and
scripts to dynamically load the content of an XML document into a
DOM document and serialize a DOM document into an XML document;"

<URL:http://www.w3.org/TR/DOM-Level-3-LS/>


Although it has reached recommendation status, it isn't widely
implemented yet.

You could iterate through all the nodes using DOM and build your own
string of nodes and properties... but I expect that is totally
impractical for anything other than trivial documents as each node has a
large number of attributes, many of which are not explicitly set in the
source HTML.
 
R

Richard Cornford

Jake said:
In the course of my research I stumbled upon this article
by Alex Russel and Tim Scarfe:

http://www.developer-x.com/content/innerhtml/default.html

The case is made that innerHTML should never be used.

That would be a stupid attitude. There is no reason to _never_ use any
feature that any environment offers. There may be very good reasons for
preferring to use other features, and any decision to use any given
feature has consequences, some of which may be negative. But every
project has a context, and some consequences vary in significance
depending upon the context in which a feature is used.

Ultimately what you need to be able to do is to make informed design
decisions appropriate to the context in which you are authoring. When
you can do that you will understand when and why not to use innerHTML,
and when it is appropriate to use it.
I'm wondering, If I wanted all the content of BODY as
a string,

For which the answer will depend on why you think you want the 'content
of the BODY' as a string, what you mean by the 'content of the BODY' and
what context you want to do this in/for. Using - innerHTML - may have
never been appropriate for the real task to start with.
how else could I get
except through innerHTML?

If all else fails you can serialize the DOM yourself (assuming the
browser environment exposes it, and in sufficient detail).

Richard.
 
R

RobG

RobG said:
Jake Barnes wrote: [...]
I'm wondering, If
I wanted all the content of BODY as a string, how else could I get
except through innerHTML?


There is the DOM 3 Load and Save module:

"...defines the Document Object Model Load and Save Level 3, a
platform- and language-neutral interface that allows programs and
scripts to dynamically load the content of an XML document into a
DOM document and serialize a DOM document into an XML document;"

<URL:http://www.w3.org/TR/DOM-Level-3-LS/>


Although it has reached recommendation status, it isn't widely
implemented yet.

Here's a small example that works in the latest Gecko browsers (and
maybe IE 7 if it's implemented the required bits of DOM 3 but I doubt it):

<script type="text/javascript">

function showIt()
{
var s;
if ( 'object' == typeof XMLSerializer
&& (s = new XMLSerializer()) )
{
var pageSrc = s.serializeToString(document).replace(/\</g,'&lt;');
var oWin = window.open('','source','');
oWin.document.write(
'<title>Source of page<\/title><pre>'
+ pageSrc
+ '<\/pre>'
);
oWin.document.close()
} else {
alert('Sorry, XMLSerializer() not supported');
}
}

</script>

<input type="button" value="Show page source" onclick="showIt();">
 
R

Randy Webb

Thomas 'PointedEars' Lahn said the following on 2/7/2006 8:35 PM:
Making an XMLHTTP request, for example.

Given the choice between an XMLHTTP request and using innerHTML,
innerHTML wins hands down though. As Richard pointed out, that article
is next to useless if it says "never use innerHTML".
 
R

RobG

Randy Webb wrote:
[...]
As Richard pointed out, that article
is next to useless if it says "never use innerHTML".

It doesn't.

It presents arguments for and against its use. Unfortunately it's more
"he said, she said" than a reasoned explanation of when to use it or
not, hence different readers will likely come away with different
opinions of whether it recommends the use if innerHTML or not.

One thing it does is to highlight that DOM 3 Load and Save does more
than innerHTML and outerHTML combined in a more robust and supportable
manner.

How much support for DOM 3 will be in IE 7? It's struggling to implement
DOM 2 fully.
 
J

Jim Ley

One thing it does is to highlight that DOM 3 Load and Save does more
than innerHTML and outerHTML combined in a more robust and supportable
manner.

But it's pretty irrelevant given that DOM 3 L&S is defined over XML
documents, and not HTML ones... so you're not actually comparing
apples and apples here.
How much support for DOM 3 will be in IE 7? It's struggling to implement
DOM 2 fully.

DOM 3 is about XML, IE7 is an HTML user agent.

Jim.
 
T

Thomas 'PointedEars' Lahn

Jim said:
But it's pretty irrelevant given that DOM 3 L&S is defined over XML
documents, and not HTML ones... so you're not actually comparing
apples and apples here.

Indeed. I missed that too, thanks.
DOM 3 is about XML, IE7 is an HTML user agent.

Well, AFAIK IE 7 Final has not been released yet. Are you saying
that IE 7 Beta 2 still does not support application/xhtml+xml and
XML document types like XHTML?


PointedEars
 
J

Jim Ley

Well, AFAIK IE 7 Final has not been released yet. Are you saying
that IE 7 Beta 2 still does not support application/xhtml+xml and
XML document types like XHTML?

The IE7 team are on record saying that application/xhtml+xml will not
be a supported type of IE7.

This is a good thing.

Jim.
 
T

Thomas 'PointedEars' Lahn

Jim said:
The IE7 team are on record saying that application/xhtml+xml will
not be a supported type of IE7.
D'oh.

This is a good thing.

Pardon?


PointedEars
 
J

John Bokma

Thomas 'PointedEars' Lahn said:

You really think XHTML will become mainstream? I hope not. Can you name
the advantages XHTML has over HTML and the disadvantages? Most people
currently using XHTML can't, I am afraid, list neither. I am afraid that
most just use XHTML because it's newer compared to HTML 4.01
 
J

Jim Ley


The mandatory requirements of XML processing are not good for users,
the fail with incomprehensible error that Mozilla does is nothing but
confusing to the user.

This is a fundamental problem with XHTML.

Jim.
 
T

Thomas 'PointedEars' Lahn

John said:
Thomas 'PointedEars' Lahn said:
Jim said:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Jim Ley wrote:
How much support for DOM 3 will be in IE 7? It's struggling to
implement DOM 2 fully.
DOM 3 is about XML, IE7 is an HTML user agent.
Well, AFAIK IE 7 Final has not been released yet. Are you saying
that IE 7 Beta 2 still does not support application/xhtml+xml and
XML document types like XHTML?
The IE7 team are on record saying that application/xhtml+xml will
not be a supported type of IE7. D'oh.

This is a good thing.

Pardon?

JFTR: I think it is definitely a Bad Thing, for it keeps XHTML a corner
language instead of helping it to become a cornerstone language of Web
authoring. The contradiction and -- I must say -- hypocrisy expressed
by Microsoft in this matter becomes obvious when you look at the
wannabe-X(HT)ML code they produce (e.g. in the MSDN Library) and
serve that as text/html to IE's tag soup parser.
You really think XHTML will become mainstream? I hope not.

Yes, I hope so. But only if there is proper support in all widely
distributed user agents. So far that is not the case, and it is a
pity that it appears to stay so, 6 years after the first XHTML
specification to which also several Microsoft people contributed to.
Can you name the advantages XHTML has over HTML and the disadvantages?

Yes, I can. And once XHTML as application/xhtml+xml, parsed by an XML
parser, gets broad support by user agents, there are no disadvantages of
it left when compared to HTML. However, I have named both before (here),
and /this/ discussion is not on-topic and I will not continue it here.
Most people currently using XHTML can't, I am afraid, list neither.

That is _their_ problem.
I am afraid that most just use XHTML because it's newer compared to
HTML 4.01

True, however that is not a valid argument against XHTML as a hopefully
_future_ "mainstream" markup language. And I was talking about a possible,
and for me desirable, future only.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Lasse said:
The fundamental problem with XHTML is the people trying to write it
by hand, just as they try any other XML. That's something XML is
not optimized for, and was never very good at.

Utter nonsense. It is not that hard to write Valid markup, may it be HTML,
XML, or XHTML, if you put a little effort in it. The fundamental problem
with any markup language, and especially SGML-based ones, is that many
people think it does not follow any rules. The drawback of the fact
that everyone can be an author on the Web is that everyone thinks he is
qualified for that without learning, with almost always devastating
results. There are people out there, myself included, who can write
Valid XHTML by hand, too. Those people are called Web authors.


PointedEars
 
J

Jim Ley

The fundamental problem with XHTML is the people trying to write it
by hand, just as they try any other XML. That's something XML is
not optimized for, and was never very good at.

but authoring webpages is something people do by hand - or by other
non machine repeatable processes - ie you plug together a load of
components that tie together content from DB's etc.

Given that all code has bugs, why should we prevent users getting
content simply because of a minor bug in a piece of software?

Jim.
 
J

Jim Ley

One I would tout is that XHTML forces you to separate the content form
the style, a good thing IMHO.

It doesn't force you to do any such thing. And given it's absolutely
identical in terms of the elements it contains are also in HTML 4.01
it's pretty obvious that even if it was true, it would be just as true
with HTML 4.01.

HTML 4.01 doesn't have the silly conformance requirement on non WF
mark-up though.

Jim.
 
T

Thomas 'PointedEars' Lahn

Thomas said:
Lasse said:
The fundamental problem with XHTML is the people trying to write it
by hand, just as they try any other XML. That's something XML is
not optimized for, and was never very good at.

[...] The drawback of the fact that everyone can be an author on the Web
is that everyone thinks he is qualified for that without learning, with
almost always devastating results. [...]

That was a bit harsh. Replace "everyone thinks he is" with "many think they
are". I do not want to preclude the possibility of reason among want-to-be
and hopefully will-be Web authors. In fact, I got to know several people to
which the more general assessment does not apply.


PointedEars
 
R

Randy Webb

Jim Ley said the following on 2/9/2006 11:18 AM:
The IE7 team are on record saying that application/xhtml+xml will not
be a supported type of IE7.

Part of that team are also on record as saying that the HTTPRequest
Object is a native object in IE7 but it isn't.
 
J

John W. Kennedy

Thomas said:

It means it's time to start the official campaign:

"Microsoft is deliberately sabotaging the Web."

"Microsoft's brand-new IE7 is already six years out of date."

"Microsoft Internet Explorer is not a web browser."

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top