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

[Jake Barnes]

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

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

The case is made that innerHTML should never be used. I'm wondering, If
I wanted all the content of BODY as a string, how else could I get
except through innerHTML?

[RobG]

Jake Barnes wrote:

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

http://www.developer-x.com/content/i...l/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.
--
Rob

[Richard Cornford]

Jake Barnes wrote:

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

http://www.developer-x.com/content/i...l/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.

[RobG]

RobG wrote:

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();">
--
Rob

[Thomas 'PointedEars' Lahn]

Jake Barnes wrote:

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

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

The case is made that innerHTML should never be used. I'm wondering, If
I wanted all the content of BODY as a string, how else could I get
except through innerHTML?

Making an XMLHTTP request, for example.
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 2/7/2006 8:35 PM:

Jake Barnes wrote:

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

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

The case is made that innerHTML should never be used. I'm wondering, If
I wanted all the content of BODY as a string, how else could I get
except through innerHTML?

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".

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[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.

--
Rob

[Jim Ley]

On Wed, 08 Feb 2006 23:45:16 GMT, RobG <rg***@iinet.net.au> wrote:

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.

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

On Wed, 08 Feb 2006 23:45:16 GMT, RobG <rg***@iinet.net.au> wrote:

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.

Indeed. I missed that too, thanks.

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?
PointedEars

[Jim Ley]

On Thu, 09 Feb 2006 17:17:24 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> 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.

This is a good thing.

Jim.

[Thomas 'PointedEars' Lahn]

Jim Ley wrote:

[...] 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?
PointedEars

[John Bokma]

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

Jim Ley wrote:

[...] 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?

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

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Jim Ley]

On Thu, 09 Feb 2006 17:39:24 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Jim Ley wrote:

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?

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.

[Lasse Reichstein Nielsen]

ji*@jibbering.com (Jim Ley) writes:

This is a fundamental problem with XHTML.

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.

On the other hand, WYSIWYG editors for XHTML will have all the
problems of WYSIWYG editors for HTML, so not writing it by hand
won't help a lot either.

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

[Thomas 'PointedEars' Lahn]

John Bokma wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

Jim Ley wrote:

[...] 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

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

ji*@jibbering.com (Jim Ley) writes:

This is a fundamental problem with XHTML.

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

[Ian Collins]

John Bokma wrote:

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

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

I don't use any WYSIWYG editors, so I can't comment on how well they
work with XHTML.

I have found that I get a lot more 'code' reuse once the two are separate.
--
Ian Collins.

[Jim Ley]

On Thu, 09 Feb 2006 19:22:36 +0100, Lasse Reichstein Nielsen
<lr*@hotpop.com> wrote:

ji*@jibbering.com (Jim Ley) writes:

This is a fundamental problem with XHTML.

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.

[Jim Ley]

On Fri, 10 Feb 2006 10:16:41 +1300, Ian Collins <ia******@hotmail.com>
wrote:

John Bokma wrote:

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

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.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

Lasse Reichstein Nielsen wrote:

ji*@jibbering.com (Jim Ley) writes:

This is a fundamental problem with XHTML.

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

[Randy Webb]

Jim Ley said the following on 2/9/2006 11:18 AM:

On Thu, 09 Feb 2006 17:17:24 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> 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.

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

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Ian Collins]

Jim Ley wrote:

On Fri, 10 Feb 2006 10:16:41 +1300, Ian Collins <ia******@hotmail.com>
wrote:

John Bokma wrote:

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

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.

True, my bad. I don't know why I said that, lack of caffeine I expect.

--
Ian Collins.

[John W. Kennedy]

Thomas 'PointedEars' Lahn wrote:

Jim Ley wrote:

[...] 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?

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"

[John W. Kennedy]

Jim Ley wrote:

On Thu, 09 Feb 2006 17:39:24 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Jim Ley wrote:

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?

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.

It is /not/ a fundamental problem with XHTML, it is a fundamental
problem with so-called "web browsers" that can't be bothered to follow
standards (in some cases, due to incompetence, but, in Microsoft's case,
because it is their deliberate policy to ignore and sabotage standards
wherever possible).

--
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"

[Jim Ley]

On Thu, 09 Feb 2006 17:47:48 -0500, "John W. Kennedy"
<jw*****@attglobal.net> wrote:

Jim Ley wrote:

On Thu, 09 Feb 2006 17:39:24 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Jim Ley wrote:
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?

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.

It is /not/ a fundamental problem with XHTML, it is a fundamental
problem with so-called "web browsers" that can't be bothered to follow
standards (in some cases, due to incompetence, but, in Microsoft's case,
because it is their deliberate policy to ignore and sabotage standards
wherever possible).

Er, no, any standard which requires you to show users messages that
they are not equipped to understand is a failure which user agents
with non-technical users will not follow.

Which is why IE doesn't support XML mimetypes for XHTML, and Opera
ignores the requirement. Why do you prefer Operas behaviour than
IE's here?

Jim.

[John Bokma]

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

John Bokma wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

Jim Ley wrote:
[...] 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.
Do we need such a cornerstone? I have my doubts.
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.
MS is not Bill Gates sitting behind a desk. It's a huge organisation in
which people perfectly well can have different views on one matter.
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.

And it will probably (and hopefully) not happen. XHTML = XML, which
means that one tiny mistake might stop the parser. Remember the Netscape
3.x (IIRC) days, that you got white pages (or was it grey)?

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.

Oh, yes, there are if the document is not well-formed, the parser should
give up.
However, I have named both before
(here), and /this/ discussion is not on-topic and I will not continue
it here.

You could give a message-id :-D

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.

The major valid argument is that the parser is too strict to be
practically useful in the real world.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Thomas 'PointedEars' Lahn]

John W. Kennedy wrote:

Thomas 'PointedEars' Lahn wrote:

Jim Ley wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:
Jim Ley wrote:
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?

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."

Count me in :)
Regards,
PointedEars

[RobG]

Jim Ley wrote:

On Wed, 08 Feb 2006 23:45:16 GMT, RobG <rg***@iinet.net.au> wrote:

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.

Yes, a good point. Are there any specific issues with using the Firefox
(Gecko?) XMLserializer with HTML?

As far as I can tell, provided the closing tags of empty elements are
fixed (i.e. '/>' is replaced with '>' ) the results are valid HTML 4
strict. I tested a few pages by using the serializer to generate page
HTML source and running it through the W3C validator.

Tag names are capitalised, so it seems to understand HTML (I guess from
the DTD) even though it is an XML serializer.
--
Rob

[John Bokma]

Ian Collins <ia******@hotmail.com> wrote:

John Bokma wrote:

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
One I would tout is that XHTML forces you to separate the content form
the style, a good thing IMHO.

How does HTML 4.01 strict fail in this regard?
I don't use any WYSIWYG editors, so I can't comment on how well they
work with XHTML.

I have found that I get a lot more 'code' reuse once the two are
separate.

Is that because you chose to do it or because the language forces you to
do so? As a programmer I always have a good laugh when in a discussion
someone claims that language A is better compared to B, because A "forces*
things. IMO, you should do things because they have a good reason to be
done thus, not because some odd "force".

It might be that XHTML drops a lot of things that should never have been
in HTML in the first place, but it also adds a few kludges.

And in no way it stops someone creating a design horror, code-wise.

Not every HTML page that validates is a well thought out coded page.
And same holds for X(HT)ML

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[John Bokma]

ji*@jibbering.com (Jim Ley) wrote:

On Thu, 09 Feb 2006 19:22:36 +0100, Lasse Reichstein Nielsen
<lr*@hotpop.com> wrote:

ji*@jibbering.com (Jim Ley) writes:

This is a fundamental problem with XHTML.

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?

Yup, true. For pages with static content, one can validate, upload, and
the work is done. But more and more webpages are generated on the fly or
change too often.

How many people don't complain if a bug crashes their application?

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[John Bokma]

"John W. Kennedy" <jw*****@attglobal.net> wrote:

It is /not/ a fundamental problem with XHTML, it is a fundamental
problem with so-called "web browsers" that can't be bothered to follow
standards
The recommendation (it's not a standard) for XML is that if the document
is not well-formed, the parser should *stop* and report.

You really think my mom is waiting for stuff like:

Error at line #121 open tag found without close tag.
(in some cases, due to incompetence, but, in Microsoft's case,
because it is their deliberate policy to ignore and sabotage standards
wherever possible).

You're mistaken, most standards you call standards are recommendations and
working drafts.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Ian Collins]

John Bokma wrote:

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

How does HTML 4.01 strict fail in this regard?

It doesn't, I was in cloud cuckoo land this morning when I posted that...

I don't use any WYSIWYG editors, so I can't comment on how well they
work with XHTML.

I have found that I get a lot more 'code' reuse once the two are
separate.

Is that because you chose to do it or because the language forces you to
do so? As a programmer I always have a good laugh when in a discussion
someone claims that language A is better compared to B, because A "forces*
things. IMO, you should do things because they have a good reason to be
done thus, not because some odd "force".

No, it's all down to the separation, I've found bits of XHTML without
any style included tend to get reused more often than those constrained
with a specific layout. Same goes for the CSS classes.
It might be that XHTML drops a lot of things that should never have been
in HTML in the first place, but it also adds a few kludges.

And in no way it stops someone creating a design horror, code-wise.

Not every HTML page that validates is a well thought out coded page.
And same holds for X(HT)ML

Indeed.

--
Ian Collins.

[Ian Collins]

John Bokma wrote:

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.

Oh, yes, there are if the document is not well-formed, the parser should
give up.

Doesn't this encourage people to produce well formed mark-up? This may
not be the be all and end all, but surely encouraging good practice is a
good thing and a basis for good design.

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.

The major valid argument is that the parser is too strict to be
practically useful in the real world.

We don't say that about our compilers :) If user agents were strict,
poorly constructed sites would have to clean up their acts. I know this
is pie in the sky, but who knows?

--
Ian Collins.

[Thomas 'PointedEars' Lahn]

John Bokma wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

John Bokma wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:
Jim Ley wrote:
> [...] 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.

Do we need such a cornerstone? I have my doubts.

Watching not Valid documents to break in one HTML user agent but not in
another is a sure sign that it is needed.

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.

MS is not Bill Gates sitting behind a desk. It's a huge organisation in
which people perfectly well can have different views on one matter.

I am aware of that. However, the management of an international company
such as Microsoft Corp. should have control over what employees propose
to standardization organizations and official statements of other employees
that counteract those efforts. It is called corporate information
management.

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.

And it will probably (and hopefully) not happen. XHTML = XML, which
means that one tiny mistake might stop the parser.

What would be so bad about that? Authors would be forced to write Valid,
interoperable documents. After all, they would be _forced_ to produce
_better_ code. I fail to see any drawback in that.
Remember the Netscape 3.x (IIRC) days, that you got white pages (or
was it grey)?

You are comparing apples and oranges.

When Netscape 3 was up to date (August 1996), the Web was far less
distributed than it is today. And there was not really an international
standardization organization, with members from numerous companies of the
industry (incl. Microsoft, BTW) and other organizations, to push Web
standards instead of proprietary approaches, for the benefit of _all_ Web
users and Web authors, no matter the user agent. (We have seen enough of
where this led to.) Now there is. The only pity is that so few people
recognize and appreciate that.

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.

Oh, yes, there are if the document is not well-formed, the parser should
give up.

That is not a disadvantage.

However, I have named both before (here), and /this/ discussion is not
on-topic and I will not continue it here.

You could give a message-id :-D

You could use Google Groups; search for "XHTML author:PointedEars".

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.

The major valid argument is that the parser is too strict to be
practically useful in the real world.

No, it is not. If the code quality is too low to be parsed by a compliant
parser, then the code quality has to improve, not the parser has to be less
strict. After all, it is a markup _language_ we are talking about, not
some drivel. Every language has its basic rules, and it is definitely a
Good Thing to enforce those rules so that everybody understands each other.
X-Post & F'up2 <ciwam/>

PointedEars

[Richard Cornford]

John W. Kennedy wrote:

Thomas 'PointedEars' Lahn wrote:

Jim Ley wrote: <snip>

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?

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."

Now try expressing that in terms that my mother will understand and care
enough about to stop her using IE 5.5 as a web browser.

Richard.

[VK]

Ian Collins wrote:

If user agents were strict,
poorly constructed sites would have to clean up their acts.

If user agents were too strict to get a satisfactory browsing
experience, users would screw on them and switch on lesser strict user
agents: and I assure you that the proposal would fit the demand within
few days.

Some people keep forgetting that browsers is a *business* and a *fight
for the market*.

John Doe and ACME, Inc do not give a crap how profoundly hierarchical
page structure is or how well the content is separated from the layout.

John Doe wants secure browsing will all cool twists he just saw at
Jonsons' - and self-made page for his little daughter w/o getting
associate degree in web development.

ACME, Inc. wants the best cost/effectiveness solution with minimum
maintenance cost.

Both of them are absolutely indifferent how will you deliver it: by
separating layout and content or by mixing them through a text
randomizer.

You manage to satisfy _both_ - you get the market (or a good part of
share).

You disappoint anyone of both - you name goes to the history. And no
one will remember in one year how standard was your browser at the
moment of its death.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

John W. Kennedy wrote:

Thomas 'PointedEars' Lahn wrote:

Jim Ley wrote:
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?

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."

Now try expressing that in terms that my mother will understand and care
enough about to stop her using IE 5.5 as a web browser.

You misunderstood. The demand is _not_ that HTML should cease to exist to
be a markup language on the Web. It is that XHTML and other XML document
types should be properly supported _too_ by the most widely distributed
browser (well, it remains to be seen if that holds true for IE7 too), 6
years(!) after the first XHTML specification has been published, instead
of continuing to parse XHTML markup with the same old tag soup parser and
pretending XHTML and XML compliance.

Did I mention that strictly conforming XHTML 1.0 documents and XHTML 1.1
documents MUST NOT be served as text/html at all?
X-Post & F'up2 <ciwam/>

PointedEars

[John Bokma]

Ian Collins <ia******@hotmail.com> wrote:

John Bokma wrote:

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

How does HTML 4.01 strict fail in this regard?

It doesn't, I was in cloud cuckoo land this morning when I posted
that...

:-) been there too (too often)
No, it's all down to the separation, I've found bits of XHTML without
any style included tend to get reused more often than those
constrained with a specific layout. Same goes for the CSS classes.

Yup, true, but you can do the same with HTML 4.01 strict. It all comes
down (again) to the person typing the code.

I have no idea how XHTML could help http://johnbokma.com/ , for example.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[John Bokma]

Ian Collins <ia******@hotmail.com> wrote:

John Bokma wrote:

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.

Oh, yes, there are if the document is not well-formed, the parser
should give up.

Doesn't this encourage people to produce well formed mark-up?

Yes, just well-formed. The problem is not the human generated static
pages, but pages that come out of CMS etc. systems. IIRC phpBB uses XHTML,
but I don't even want to think about how many pages generated by it fail,
maybe even before people have been tweaking the templates.
This
may not be the be all and end all, but surely encouraging good
practice is a good thing and a basis for good design.
IMNSHO, with all coding, it depends on the person doing the coding, not
what the language forces. If one makes a mess in HTML 4.01, the person
will make a mess in XHTML. Maybe not the same kind of mess, but a mess it
will be.

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.

The major valid argument is that the parser is too strict to be
practically useful in the real world.

We don't say that about our compilers :)

True, but my mom is not using a compiler, for example. Nor are most of my
friends. Yet they will be confronted with compiler warnings if XHTML
becomes mainstream (which I guess will never happen).
If user agents were strict,
Netscape 3.x was, IIRC. Ages ago I tested my pages with Netscape just for
that reason (on an Indy :-p, had to buy extra memory to keep NC going for
several minutes more )
poorly constructed sites would have to clean up their acts. I know
this is pie in the sky, but who knows?

Netscape, because they changed the parser in 4.x (or later? Can't recall).

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[John Bokma]

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

John Bokma wrote:

Do we need such a cornerstone? I have my doubts.

Watching not Valid documents to break in one HTML user agent but not
in another is a sure sign that it is needed.

break is very different from having to stare at:

mismatched tag at line 142, column 14, byte 9088

My site (see sig, jb one) is generated from a bunch of XML files, and
pfft, I get too often messages like the above one. Some are even quite
hard to find :-)

MS is not Bill Gates sitting behind a desk. It's a huge organisation
in which people perfectly well can have different views on one
matter.

I am aware of that. However, the management of an international
company such as Microsoft Corp. should have control over what
employees propose to standardization organizations

You mean ECMA? I had the idea that the standardization .NET worked ok.
and official
statements of other employees that counteract those efforts. It is
called corporate information management.
But you're now talking at the level of: several employees decided not to
use paper brand x, but paper brand y instead.

And it will probably (and hopefully) not happen. XHTML = XML, which
means that one tiny mistake might stop the parser.

What would be so bad about that? Authors would be forced to write
Valid, interoperable documents.

A lot of documents one can see nowadays are *generated* To get that
level of validation you need very extensive regression testing, which
will cost a lot of money. Who's going to pay for all that?
After all, they would be _forced_ to
produce _better_ code.
Wrong. They would be forced to produce well-formed code. Moreover, I
doubt if browsers are going to be validating as well. So where does
well-formed leave us? It just means a few simple things about open and
closing, and one root element, etc. It tells *nothing* about the actual
quality of code.

It's the same for HTML: a validating document doesn't say the code is
better.
I fail to see any drawback in that.
mismatched tag at line 142, column 14, byte 9088 :-D

Remember the Netscape 3.x (IIRC) days, that you got white pages (or
was it grey)?

You are comparing apples and oranges.

Am I? Netscape 3.x had quite a strict parser for HTML. It returned a
blank page for each page that it couldn't handle. I see no difference
between that and "mismatched tag at line 142, column 14, byte 9088"
(OK, the latter gives me some info, but it would scare my mom)
When Netscape 3 was up to date (August 1996), the Web was far less
distributed than it is today. And there was not really an
international standardization organization,
You're not talking about w3c I hope? Since I am not aware that they have
become a standardization organization. Last time I checked they had
working drafts and recommendations.
with members from numerous
companies of the industry (incl. Microsoft, BTW) and other
organizations, to push Web standards
recommendations
instead of proprietary
approaches, for the benefit of _all_ Web users and Web authors, no
matter the user agent. (We have seen enough of where this led to.)
Now there is. The only pity is that so few people recognize and
appreciate that.
OK, but how does that make it apples and oranges?

The *reason* Netscape changed their parser, IMO, is that too many people
saw a white (grey more likely) page when browsing.

The fact is: if you bring now a browser on the market that reports an
error when a page is invalid (or not well-formed), only a very small
group of webdevelopers probably is going to use it.

How do you want to make everybody change his/her website into XHTML?
It's not going to happen. IMNSHO W3C should drop XHTML and focus on HTML
5.0. XHTML is a failure, and every minute people put in it, is a waste
of time.

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.

Oh, yes, there are if the document is not well-formed, the parser
should give up.

That is not a disadvantage.

Not for a developer, no. But if you're into that, you mark up your
content in XML, transform it into HTML (and maybe validate the latter).

However, I have named both before (here), and /this/ discussion is
not on-topic and I will not continue it here.

You could give a message-id :-D

You could use Google Groups; search for "XHTML author:PointedEars".

Thanks.

The major valid argument is that the parser is too strict to be
practically useful in the real world.

No, it is not.

Says who :-D
If the code quality is too low to be parsed by a
compliant parser,
Well-formed is just an extremely simple requirement. It says extremely
little about code quality. Unless you want each and every UA also to be
validating? (Which still says little about the quality).

It's a silly argument, it's like saying: if your program compiles, the
code is of not of low quality, while if it doesn't, it's low quality.
then the code quality has to improve, not the parser
has to be less strict. After all, it is a markup _language_ we are
talking about, not some drivel. Every language has its basic rules,
and it is definitely a Good Thing to enforce those rules so that
everybody understands each other.
My mom is not going to understand:
mismatched tag at line 142, column 14, byte 9088

So there it already fails.

IMNSHO, what a developer does is her/his business. Developers should
talk the same language, and use validation tools. But if something
fails, should the visitor see a silly error message, or perhaps a page
that looks a bit odd, but is 98% usable?

Imagine receiving a free magazine, and due to a printing error on page
20, you only get blank pages.
X-Post & F'up2 <ciwam/>

Element not in my DTD, so I hacked it back (be happy, I could have given
you a parser error and an empy post)

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Ian Collins]

John Bokma wrote:

Ian Collins <ia******@hotmail.com> wrote:

No, it's all down to the separation, I've found bits of XHTML without
any style included tend to get reused more often than those
constrained with a specific layout. Same goes for the CSS classes.

Yup, true, but you can do the same with HTML 4.01 strict. It all comes
down (again) to the person typing the code.

Well I think we are agreed that it isn't which standard one adheres to,
but the adherence that matters.

Also I'm sure no one would disagree that separation of content and style
is a good thing.

Drifting back on topic, one benefit I'd like to see form strong
XML/XHTML support for user agents is better DOM conformance, to make the
job of us poor JavaScript authors easier. From what I've seen, the two
go hand in hand.

It may not be common on the public internet, but have worked with XML
interfaces that work well for machine to machine communication and with
matching CSS, for humans.

If the internet is to move on, we have to look beyond HTML. The
combination of XML/CSS and JavaScript offers unlimited potential.
Perhaps if there was a good application for XML in porn, there would be
better support :)

--
Ian Collins.

[John Bokma]

Ian Collins <ia******@hotmail.com> wrote:

Drifting back on topic, one benefit I'd like to see form strong
XML/XHTML support for user agents is better DOM conformance, to make the
job of us poor JavaScript authors easier. From what I've seen, the two
go hand in hand.
Ok, I know too little about that to comment on it.
It may not be common on the public internet, but have worked with XML
interfaces that work well for machine to machine communication and with
matching CSS, for humans.
Yes, I use XML internally ((almost) my whole jb site is marked up in XML
files, which are turned into HTML) and I know the advantages from a
developers point of view, and the disadvantages to my mom :-D
If the internet is to move on, we have to look beyond HTML. The
combination of XML/CSS and JavaScript offers unlimited potential.
Can you explain why HTML + JavaScript can't offer such a thing? Also,
because I see no reason why a HTML parser can't fix errors instead of
dying at the first one, and create a parse tree that is well formed.

XML parsing reminds me too often of the first compilers I used (or wrote
myself), that stopped at the first error. Recompile, next error,
recompile, next error.
Perhaps if there was a good application for XML in porn, there would be
better support :)

A Porn application that now and then doesn't show porn, but "Parse error
at line 12123". Uhm....

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Ian Collins]

John Bokma wrote:

Ian Collins <ia******@hotmail.com> wrote:

If the internet is to move on, we have to look beyond HTML. The
combination of XML/CSS and JavaScript offers unlimited potential.

Can you explain why HTML + JavaScript can't offer such a thing? Also,
because I see no reason why a HTML parser can't fix errors instead of
dying at the first one, and create a parse tree that is well formed.

You're freed from the constraints of the HTML DTD.

I have a page that is the XML description (with as stylesheet) of an
application's database that my client can access directly. I could
transform it to HTML, but why bother? We are considering adding some
scripting to enable them to update the document in their browser.

The best way to prevent parser hiccups it to use HTML tidy.
XML parsing reminds me too often of the first compilers I used (or wrote
myself), that stopped at the first error. Recompile, next error,
recompile, next error.

Yes it was a pain to get the deck of cards back with an error message...

--
Ian Collins.

[Thomas 'PointedEars' Lahn]

John Bokma wrote:

X-Post & F'up2 <ciwam/>

Element not in my DTD, so I hacked it back (be happy, I
could have given you a parser error and an empy post)

PLONK

[John W. Kennedy]

Jim Ley wrote:

On Thu, 09 Feb 2006 17:47:48 -0500, "John W. Kennedy"
<jw*****@attglobal.net> wrote:

Jim Ley wrote:

On Thu, 09 Feb 2006 17:39:24 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:

Jim Ley wrote:
> 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?
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.

It is /not/ a fundamental problem with XHTML, it is a fundamental
problem with so-called "web browsers" that can't be bothered to follow
standards (in some cases, due to incompetence, but, in Microsoft's case,
because it is their deliberate policy to ignore and sabotage standards
wherever possible).

Er, no, any standard which requires you to show users messages that
they are not equipped to understand is a failure which user agents
with non-technical users will not follow.

Like TCP/IP? This is a strawman. Get it right, or don't do it.

--
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"

[John W. Kennedy]

John Bokma wrote:

"John W. Kennedy" <jw*****@attglobal.net> wrote:

It is /not/ a fundamental problem with XHTML, it is a fundamental
problem with so-called "web browsers" that can't be bothered to follow
standards

The recommendation (it's not a standard) for XML is that if the document
is not well-formed, the parser should *stop* and report.

You really think my mom is waiting for stuff like:

Error at line #121 open tag found without close tag.

No, I think your mom is waiting for websites coded by the competent.

(in some cases, due to incompetence, but, in Microsoft's case,
because it is their deliberate policy to ignore and sabotage standards
wherever possible).

You're mistaken, most standards you call standards are recommendations and
working drafts.

A verbal quibble to pass off Microsoft's vicious behavior as acceptable,
and you know it.

--
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"

[Jim Ley]

On Fri, 10 Feb 2006 12:00:19 -0500, "John W. Kennedy"
<jw*****@attglobal.net> wrote:

Jim Ley wrote:

Er, no, any standard which requires you to show users messages that
they are not equipped to understand is a failure which user agents
with non-technical users will not follow.

Like TCP/IP? This is a strawman. Get it right, or don't do it.

Er, no TCP/IP does not require you to show the user any particular
error condition.

Jim.

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Lasse Reichstein Nielsen wrote:

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.

It's not *hard* in any way. Anybody who can close the parentheses
correctly on a Lisp program should have no problem writing XML.

You do have to stay attentive, making sure you don't misspell a tag or
attribute name, that you remember the "/>" on empty elements, that you
write only correct values into attributes, etc. That's not hard, just
demanding.

XML is also quite verbose, especially if you try to give tags
meaningfull (and thereby more easily readable) names. And you have to
write the end tag every time, even if the name is exactly the same as
the start tag. An assisting editor could help you here, filling in
the tag name when you start a closing tag.

If your editor doesn't understand the document definition (defined by,
e.g., DTD or XMLSchema), then it can't help you correct typos. If it
also assist you filling ind end tags, you will even create correctly
matched tags when you misspell a start tag.

All this means that writing XML soon becomes mindnumbingly boring.
The combination of requireing attention to detail *and* being boring
is the classic recipy for making stupid errors.

Possible? Absolutely. Hard? Hardly! Slow and errorprone? Check!

So, to make writing XML even remotely pleasent, the editor should
at least be able to check the syntax against a document definition.
Syntax highlighting is also important, since black-on-white XML
isn't very readable either.

XML is the lowest common denominator of formats. It is extremely well
suited for machine reading, and just as unsuitable for human
reading. Sure, it's easy to learn the basic structure, since
everything is really the same. It's also very hard to read any larger
document *because* it all looks the same. Having to pick out the tag
names, i.e., words, in a block of text, i.e., other words, begs for
syntax highlighting, at the least. HTML was actually better, since it
allowed you to write your tags with capital letters if you so
preferred.
But I guess the verbosity is really the killer for me. The boredom.

It's not like parsers are hard to build these days. Dumbing everything
down to XML makes sense for machine-to-machine communication, but for
humans writing information to computers, a language specific to the
application domain can make everything so much easier that it is
ridiculous.
(The development of syntax:

Math:
x |-> x * 2

Scheme:
(lambda (x) (* x 2))

MathML:
<lambda>
<bvar><ci> x </ci></bvar>
<apply>
<times/>
<ci> x </ci>
<cn> 2 </cn>
</apply>
</lambda>

:)

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

[John Bokma]

Ian Collins <ia******@hotmail.com> wrote:

John Bokma wrote:

Ian Collins <ia******@hotmail.com> wrote:

If the internet is to move on, we have to look beyond HTML. The
combination of XML/CSS and JavaScript offers unlimited potential.

Can you explain why HTML + JavaScript can't offer such a thing? Also,
because I see no reason why a HTML parser can't fix errors instead of
dying at the first one, and create a parse tree that is well formed.

You're freed from the constraints of the HTML DTD.

I was always under the impression that the HTML DTD could be extended.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[John Bokma]

Thomas 'PointedEars' Lahn <Po*********@web.de> wrote:

John Bokma wrote:

>> X-Post & F'up2 <ciwam/>

Element not in my DTD, so I hacked it back (be happy, I
could have given you a parser error and an empy post)

PLONK

[a] Don't post childish plonk messages
[b] I consider kicking a posting out of a group extremely rude, so if
there was anyone giving a reason for ploinking it was you, not me.

Maybe you're new to Usenet, but breaking a thread in pieces is stupid. The
discussion is here, and altough it's partially offtopic, it doesn't make
sense to run a part of it in a group you picked, while the other part goes
on here.

Get a life.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html