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

[John Bokma]

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

"John W. Kennedy" <jwkenne@attglo bal.net> wrote:
[color=blue]
> 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[/color]

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.
[color=blue]
> (in some cases, due to incompetence, but, in Microsoft's case,
> because it is their deliberate policy to ignore and sabotage standards
> wherever possible).[/color]

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]

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

John Bokma wrote:[color=blue][color=green]
>>
>>One I would tout is that XHTML forces you to separate the content form
>>the style, a good thing IMHO.[/color]
>
>
> How does HTML 4.01 strict fail in this regard?
>[/color]
It doesn't, I was in cloud cuckoo land this morning when I posted that...[color=blue]
>[color=green]
>>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.[/color]
>
>
> 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".
>[/color]
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.
[color=blue]
> 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
>[/color]
Indeed.

--
Ian Collins.

[Ian Collins]

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

John Bokma wrote:[color=blue][color=green]
>>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.[/color]
>
>
> Oh, yes, there are if the document is not well-formed, the parser should
> give up.
>[/color]
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.
[color=blue][color=green]
>>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.[/color]
>
>
> The major valid argument is that the parser is too strict to be
> practically useful in the real world.
>[/color]
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]

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

John Bokma wrote:
[color=blue]
> Thomas 'PointedEars' Lahn <PointedEars@we b.de> wrote:[color=green]
>> John Bokma wrote:[color=darkred]
>>> Thomas 'PointedEars' Lahn <PointedEars@we b.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?[/color]
>> 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.[/color]
>
> Do we need such a cornerstone? I have my doubts.[/color]

Watching not Valid documents to break in one HTML user agent but not in
another is a sure sign that it is needed.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
>>> You really think XHTML will become mainstream? I hope not.[/color]
>> 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.[/color]
>
> And it will probably (and hopefully) not happen. XHTML = XML, which
> means that one tiny mistake might stop the parser.[/color]

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.
[color=blue]
> Remember the Netscape 3.x (IIRC) days, that you got white pages (or
> was it grey)?[/color]

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.
[color=blue][color=green][color=darkred]
>>> Can you name the advantages XHTML has over HTML and the
>>> disadvantages?[/color]
>> 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.[/color]
>
> Oh, yes, there are if the document is not well-formed, the parser should
> give up.[/color]

That is not a disadvantage.
[color=blue][color=green]
>> However, I have named both before (here), and /this/ discussion is not
>> on-topic and I will not continue it here.[/color]
>
> You could give a message-id :-D[/color]

You could use Google Groups; search for "XHTML author:PointedE ars".
[color=blue][color=green][color=darkred]
>>> Most people currently using XHTML can't, I am afraid, list neither.[/color]
>> That is _their_ problem.
>>[color=darkred]
>>> I am afraid that most just use XHTML because it's newer compared to
>>> HTML 4.01[/color]
>>
>> 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.[/color]
>
> The major valid argument is that the parser is too strict to be
> practically useful in the real world.[/color]

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]

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

John W. Kennedy wrote:[color=blue]
> Thomas 'PointedEars' Lahn wrote:[color=green]
>> Jim Ley wrote:[/color][/color]
<snip>[color=blue][color=green][color=darkred]
>>> The IE7 team are on record saying that
>>> application/xhtml+xml will
>>> not be a supported type of IE7.[/color]
>>
>> D'oh.
>>[color=darkred]
>>> This is a good thing.[/color]
>>
>> Pardon?[/color]
>
> 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."[/color]

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]

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


Ian Collins wrote:[color=blue]
> If user agents were strict,
> poorly constructed sites would have to clean up their acts.[/color]

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]

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

Richard Cornford wrote:
[color=blue]
> John W. Kennedy wrote:[color=green]
>> Thomas 'PointedEars' Lahn wrote:[color=darkred]
>>> 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?[/color]
>>
>> 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."[/color]
>
> 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.[/color]

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]

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

Ian Collins <ian-news@hotmail.co m> wrote:
[color=blue]
> John Bokma wrote:[color=green][color=darkred]
>>>
>>>One I would tout is that XHTML forces you to separate the content
>>>form the style, a good thing IMHO.[/color]
>>
>>
>> How does HTML 4.01 strict fail in this regard?
>>[/color]
> It doesn't, I was in cloud cuckoo land this morning when I posted
> that...[/color]

:-) been there too (too often)
[color=blue]
> 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.[/color]

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]

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

Ian Collins <ian-news@hotmail.co m> wrote:
[color=blue]
> John Bokma wrote:[color=green][color=darkred]
>>>Yes, I can. And once XHTML as application/xhtml+xml, parsed by an
>>>XML parser, gets broad support by user agents, there are no
>>>disadvantage s of it left when compared to HTML.[/color]
>>
>>
>> Oh, yes, there are if the document is not well-formed, the parser
>> should give up.
>>[/color]
> Doesn't this encourage people to produce well formed mark-up?[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
>>>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.[/color]
>>
>> The major valid argument is that the parser is too strict to be
>> practically useful in the real world.[/color]
>
> We don't say that about our compilers :)[/color]

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).
[color=blue]
> If user agents were strict,[/color]

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 )
[color=blue]
> poorly constructed sites would have to clean up their acts. I know
> this is pie in the sky, but who knows?[/color]

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]

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

Thomas 'PointedEars' Lahn <PointedEars@we b.de> wrote:
[color=blue]
> John Bokma wrote:[/color]
[color=blue][color=green]
>> Do we need such a cornerstone? I have my doubts.[/color]
>
> Watching not Valid documents to break in one HTML user agent but not
> in another is a sure sign that it is needed.[/color]

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 :-)
[color=blue][color=green]
>> 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.[/color]
>
> 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[/color]

You mean ECMA? I had the idea that the standardization .NET worked ok.
[color=blue]
> and official
> statements of other employees that counteract those efforts. It is
> called corporate information management.[/color]

But you're now talking at the level of: several employees decided not to
use paper brand x, but paper brand y instead.
[color=blue][color=green]
>> And it will probably (and hopefully) not happen. XHTML = XML, which
>> means that one tiny mistake might stop the parser.[/color]
>
> What would be so bad about that? Authors would be forced to write
> Valid, interoperable documents.[/color]

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?
[color=blue]
> After all, they would be _forced_ to
> produce _better_ code.[/color]

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.
[color=blue]
> I fail to see any drawback in that.[/color]

mismatched tag at line 142, column 14, byte 9088 :-D
[color=blue][color=green]
>> Remember the Netscape 3.x (IIRC) days, that you got white pages (or
>> was it grey)?[/color]
>
> You are comparing apples and oranges.[/color]

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)
[color=blue]
> 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,[/color]

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 .
[color=blue]
> with members from numerous
> companies of the industry (incl. Microsoft, BTW) and other
> organizations, to push Web standards[/color]

recommendations
[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
>>>> 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.[/color]
>>
>> Oh, yes, there are if the document is not well-formed, the parser
>> should give up.[/color]
>
> That is not a disadvantage.[/color]

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).
[color=blue][color=green][color=darkred]
>>> However, I have named both before (here), and /this/ discussion is
>>> not on-topic and I will not continue it here.[/color]
>>
>> You could give a message-id :-D[/color]
>
> You could use Google Groups; search for "XHTML author:PointedE ars".[/color]

Thanks.
[color=blue][color=green]
>> The major valid argument is that the parser is too strict to be
>> practically useful in the real world.[/color]
>
> No, it is not.[/color]

Says who :-D
[color=blue]
> If the code quality is too low to be parsed by a
> compliant parser,[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> X-Post & F'up2 <ciwam/>[/color]

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]

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

John Bokma wrote:[color=blue]
> Ian Collins <ian-news@hotmail.co m> wrote:
>[color=green]
>>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.[/color]
>
>
> Yup, true, but you can do the same with HTML 4.01 strict. It all comes
> down (again) to the person typing the code.
>[/color]
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]

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

Ian Collins <ian-news@hotmail.co m> wrote:
[color=blue]
> 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.[/color]

Ok, I know too little about that to comment on it.
[color=blue]
> 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.[/color]

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
[color=blue]
> If the internet is to move on, we have to look beyond HTML. The
> combination of XML/CSS and JavaScript offers unlimited potential.[/color]

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.
[color=blue]
> Perhaps if there was a good application for XML in porn, there would be
> better support :)[/color]

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]

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

John Bokma wrote:[color=blue]
> Ian Collins <ian-news@hotmail.co m> wrote:
>[color=green]
>>If the internet is to move on, we have to look beyond HTML. The
>>combination of XML/CSS and JavaScript offers unlimited potential.[/color]
>
>
> 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.
>[/color]
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.
[color=blue]
> 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.
>[/color]
Yes it was a pain to get the deck of cards back with an error message...

--
Ian Collins.

[Thomas 'PointedEars' Lahn]

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

John Bokma wrote:
[color=blue][color=green][color=darkred]
> >> X-Post & F'up2 <ciwam/>[/color][/color]
>
> Element not in my DTD, so I hacked it back (be happy, I
> could have given you a parser error and an empy post)[/color]

PLONK

[John W. Kennedy]

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

Jim Ley wrote:[color=blue]
> On Thu, 09 Feb 2006 17:47:48 -0500, "John W. Kennedy"
> <jwkenne@attglo bal.net> wrote:
>[color=green]
>> Jim Ley wrote:[color=darkred]
>>> On Thu, 09 Feb 2006 17:39:24 +0100, Thomas 'PointedEars' Lahn
>>> <PointedEars@we b.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 incomprehensibl e error that Mozilla does is nothing but
>>> confusing to the user.
>>>
>>> This is a fundamental problem with XHTML.[/color]
>> 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).[/color]
>
> 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.[/color]

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"