innerHTML not good in Firefox?

[catorcio]

I'm trying to have some text in my page changed by clicking
a button. Googleing around I've discovered that innerText
doesn't work with every browser, so I've switched to
innerHTML. It works fine on IE and Opera, but nothing
happens on Firefox (just updated to version 1.0.4).

Any suggestions?

Thanks in advance! C.


....
<script type="text/javascript">

function changeText(newt ext)
{
text.innerHTML = newtext;
}


</script>

<p id="text">Old text</p>
<input type="button" onclick="change Text('New text')"
value="Change text" />
....

[Markus Fischer]

Re: innerHTML not good in Firefox?

catorcio wrote:[color=blue]
> I'm trying to have some text in my page changed by clicking a button.
> Googleing around I've discovered that innerText doesn't work with every
> browser, so I've switched to innerHTML. It works fine on IE and Opera,
> but nothing happens on Firefox (just updated to version 1.0.4).
>
> Any suggestions?
>
> Thanks in advance! C.
>
>
> ...
> <script type="text/javascript">
>
> function changeText(newt ext)
> {
> text.innerHTML = newtext;
> }[/color]

You have missed to get a reference to the paragraph. Put this line
before innerHTML:

var text = document.getEle mentById('text' );

HTH

[Jay]

Re: innerHTML not good in Firefox?


"catorcio" <c@torc.io> wrote in message
news:d65tj2$mnd $1@domitilla.ai oe.org...[color=blue]
> I'm trying to have some text in my page changed by clicking a button.
> Googleing around I've discovered that innerText doesn't work with every
> browser, so I've switched to innerHTML. It works fine on IE and Opera, but
> nothing happens on Firefox (just updated to version 1.0.4).
>
> Any suggestions?
>
> Thanks in advance! C.[/color]


Works for me 1.0.3

Jay
[color=blue]
> ...
> <script type="text/javascript">
>
> function changeText(newt ext)
> {
> text.innerHTML = newtext;
> }
>
>
> </script>
>
> <p id="text">Old text</p>
> <input type="button" onclick="change Text('New text')" value="Change text"
> />
> ...[/color]

[John W. Kennedy]

Re: innerHTML not good in Firefox?

catorcio wrote:[color=blue]
> I'm trying to have some text in my page changed by clicking a button.
> Googleing around I've discovered that innerText doesn't work with every
> browser, so I've switched to innerHTML. It works fine on IE and Opera,
> but nothing happens on Firefox (just updated to version 1.0.4).
>
> Any suggestions?
>
> Thanks in advance! C.
>
>
> ....
> <script type="text/javascript">
>
> function changeText(newt ext)
> {
> text.innerHTML = newtext;
> }
>
>
> </script>
>
> <p id="text">Old text</p>
> <input type="button" onclick="change Text('New text')" value="Change
> text" />
> ....[/color]

I notice that your code is XHTML. innerHTML does not work with XHTML,
and isn't supposed to.

Since Internet Explorer does not support XHTML, and since you say your
page works on Internet Explorer, it is obvious that your server is lying
to Internet Explorer, and saying that your file is HTML when it is
really XHTML.

But your server could still be telling the truth to Firefox. If so, then
Firefox is quite correctly refusing to do innerHTML. If this is the
case, then you must either convert your page to HTML 4, where innerHTML
will work, or use the standard DOM methods instead of innerHTML.

You can easily determine what your server is telling Firefox by using
Tools->Page Info. If it says the page is XHTML, then that's your problem.
--
John W. Kennedy
"The pathetic hope that the White House will turn a Caligula into a
Marcus Aurelius is as naïve as the fear that ultimate power inevitably
corrupts."
-- James D. Barber (1930-2004)

[Steve Sobol]

Re: innerHTML not good in Firefox?

John W. Kennedy wrote:
[color=blue]
> Since Internet Explorer does not support XHTML, and since you say your
> page works on Internet Explorer, it is obvious that your server is lying
> to Internet Explorer, and saying that your file is HTML when it is
> really XHTML.[/color]

The other option: you're wrong.

IE 6 DOES most definitely support XHTML and will even render it correctly
(well, 98% correctly, with a couple well-known bugs for with there are
workarounds) as long as you're not in Quirks mode, and including the proper
DOCTYPE declaration at the top of your page will put both FireFox and IE into
Standards mode...

The question is what version of IE is being discussed here. Forgive me if this
was already answered - I'm jumping into this discussion mid-thread.
[color=blue]
> You can easily determine what your server is telling Firefox by using
> Tools->Page Info. If it says the page is XHTML, then that's your problem.[/color]

Not including a DOCTYPE is very, very foolish these days. I would much rather
just include a DOCTYPE and know that the major browsers are going to pay
attention to it than leave them in Quirks mode and take my chances.

--
JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638)
Steven J. Sobol, Geek In Charge / sjsobol@JustThe .net / PGP: 0xE3AE35ED

"The wisdom of a fool won't set you free"
--New Order, "Bizarre Love Triangle"

[Lasse Reichstein Nielsen]

Re: innerHTML not good in Firefox?

Steve Sobol <sjsobol@JustTh e.net> writes:
[color=blue]
> IE 6 DOES most definitely support XHTML[/color]

.... for some definition of "support". I prefer the defintion
where IE doesn't:
<URL:http://erik.eae.net/archives/2003/07/29/21.07.24/>

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

[Jay]

Re: innerHTML not good in Firefox?


"John W. Kennedy" <jwkenne@attglo bal.net> wrote in message
news:Y1Ahe.3446 $Bg4.2134@fe10. lga...[color=blue]
> catorcio wrote:[color=green]
>> I'm trying to have some text in my page changed by clicking a button.
>> Googleing around I've discovered that innerText doesn't work with every
>> browser, so I've switched to innerHTML. It works fine on IE and Opera,
>> but nothing happens on Firefox (just updated to version 1.0.4).
>>
>> Any suggestions?
>>
>> Thanks in advance! C.
>>
>>
>> ....
>> <script type="text/javascript">
>>
>> function changeText(newt ext)
>> {
>> text.innerHTML = newtext;
>> }
>>
>>
>> </script>
>>
>> <p id="text">Old text</p>
>> <input type="button" onclick="change Text('New text')" value="Change text"
>> />
>> ....[/color]
>
> I notice that your code is XHTML. innerHTML does not work with XHTML, and
> isn't supposed to.
>
> Since Internet Explorer does not support XHTML, and since you say your
> page works on Internet Explorer, it is obvious that your server is lying
> to Internet Explorer, and saying that your file is HTML when it is really
> XHTML.[/color]

IE does not support XHTML?
I'd like to read up on this if you have a URL as I wasn't led to believe
this.

Jay

[John W. Kennedy]

Re: innerHTML not good in Firefox?

Steve Sobol wrote:[color=blue]
> John W. Kennedy wrote:
>[color=green]
>> Since Internet Explorer does not support XHTML, and since you say your
>> page works on Internet Explorer, it is obvious that your server is
>> lying to Internet Explorer, and saying that your file is HTML when it
>> is really XHTML.[/color]
>
>
> The other option: you're wrong.
>
> IE 6 DOES most definitely support XHTML[/color]

No, it doesn't. It categorically refuses to, because Bill Gates is an
arrogant son of a bitch who refuses to cooperate with standards.

What it /will/ do is render what it thinks is HTML, even when the "HTML"
is actually XHTML 1.0.

--
John W. Kennedy
"Informatio n is light. Information, in itself, about anything, is light."
-- Tom Stoppard. "Night and Day"

[John W. Kennedy]

Re: innerHTML not good in Firefox?

Jay wrote:[color=blue]
> "John W. Kennedy" <jwkenne@attglo bal.net> wrote in message
> news:Y1Ahe.3446 $Bg4.2134@fe10. lga...
>[color=green]
>>catorcio wrote:
>>[color=darkred]
>>>I'm trying to have some text in my page changed by clicking a button.
>>>Googleing around I've discovered that innerText doesn't work with every
>>>browser, so I've switched to innerHTML. It works fine on IE and Opera,
>>>but nothing happens on Firefox (just updated to version 1.0.4).
>>>
>>>Any suggestions?
>>>
>>>Thanks in advance! C.
>>>
>>>
>>>....
>>><script type="text/javascript">
>>>
>>>function changeText(newt ext)
>>> {
>>> text.innerHTML = newtext;
>>> }
>>>
>>>
>>></script>
>>>
>>><p id="text">Old text</p>
>>><input type="button" onclick="change Text('New text')" value="Change text"
>>>/>
>>>....[/color]
>>
>>I notice that your code is XHTML. innerHTML does not work with XHTML, and
>>isn't supposed to.
>>
>>Since Internet Explorer does not support XHTML, and since you say your
>>page works on Internet Explorer, it is obvious that your server is lying
>>to Internet Explorer, and saying that your file is HTML when it is really
>>XHTML.[/color]
>
>
> IE does not support XHTML?
> I'd like to read up on this if you have a URL as I wasn't led to believe
> this.[/color]

Any number of places, such as
<URL:http://www.w3.org/MarkUp/2004/xhtml-faq#ie>

Or you can just try the experiment with a server that serves XHTML as
XHTML with no content negotiation.

--
John W. Kennedy
"I want everybody to be smart. As smart as they can be. A world of
ignorant people is too dangerous to live in."
-- Garson Kanin. "Born Yesterday"

[Richard Cornford]

Re: innerHTML not good in Firefox?

Jay wrote:[color=blue]
> John W. Kennedy wrote:[/color]
<snip>[color=blue][color=green]
>> Since Internet Explorer does not support XHTML, ...[/color][/color]
<snip>[color=blue]
> IE does not support XHTML?[/color]

No it does not. Internet Explorer is an HTML web browser.
[color=blue]
> I'd like to read up on this if you have a URL as I
> wasn't led to believe this.[/color]

It is easy enough to verify the veracity of the claim by pointing IE at
a resource serving XHTML, with an XHTML content type header
(application/xhtml+xml). IE will likely offer you the option of
downloading the file and saving it to disk (which is how it handles most
things that it doesn't support, either directly or indirectly).

In the original XHTML specification (1.0) there is a section - Appendix
C:-

<quote cite="XHTML 1.0: The Extensible HyperText Markup Language">
Appendix C. HTML Compatibility Guidelines

This appendix is informative.

This appendix summarizes design guidelines for authors who wish their
XHTML documents to render on existing HTML user agents.
....
</quote>

- which proposes a series of measures that can be taken to allow a
formally correct XHTML 1.0 document to be interpreted as an (erroneous)
HTML document. Key among these measures is the sending of an HTTP
content-type header of 'text/html'. That content type header is an
assertion that the document is an HTML document, and every user agent
(including those that support XHTML) has no choice but interpret a
document sent as text/html as an HTML document.

XHTML and HTML are in some respects very similar, and in others very
different. The similarities allow the HTML user agent to interpret the
results as HTML but the differences can get in the way of that so
Appendix C goes on to propose strategies for negating the effect of the
differences. For example, is XML you can use a shorthand to describe
elements that have no contents:-

<something></somthing>

- and be written as:-

<something/>

- and have exactly the same meaning. As an application of XML, XHTML
also allows this. For an HTML browser that penultimate slash in
<something/> would have a different meaning. Older HTML browser tended
to regard it as a part of the element name, so Appendix C proposes that
the penultimate slash be separated from the element name by at least one
space character. This avoids confusion as to the actual element name,
but the slash is still meaningless in HTML (in SGML it means something
completely different, but that is another mater). Fortunately HTML user
agents have long become accustomed to being presented with meaningless
constructs in HTML (due to the abysmal standards of technical competence
common in web development) so they have facilities for
'error-correction'. Thus the HTML browser sees the penultimate slash as
an error (akin to a typo) and disregards it.

This works fine because:-

<br />

- is error corrected back to:-

<br>

- which is meaningful in HTML.

Problems start to occur when other elements are treated to the XML
shorthand, such as:-

<div></div>
-becoming:-

<div />

- because it would be error-corrected to:-

<div>

- which is an opening HTML DIV tag without a corresponding closing DIV
tag. While that is not strictly allowed in HTML it is a common error and
will itself be subject to error correction. The HTML user agent will
infer the closing DIV tag at the last location in which it should have
occurred; either just before the closing tag for any containing element,
or just before the opening tag of any element that it could not contain.
The result is very different from an XHTML interpretation of the same
original mark-up.

To avoid this issue Appendix C proposes that only elements that are
empty in HTML should use the shorthand syntax. Thus; <img />, <br />,
etc, but not <script />.

The same applies in reverse as XHTML allows empty elements to be
expresses with both opening and closing tags, E.G. <br></br>, is a
single line break in XHTML, but the error-corrected HTML interpretation
is two BR elements (or the second tag is an opening tag for an element
with an unrecognised name).

The above, and the other proposals in Appendix C, result in a syntax
that is a subset of XHTML that is within the ability of known HTML user
agents to error-correct back to HTML, if served as text/html. And when
served as text/html those documents will be interpreted as erroneous
HTML. Only documents served with an XHTML content type header will ever
be interpreted as XHTML.

Because IE cannot understand XHTML it is necessary to send Appendix C
XHTML mark-up to IE with the text/html content type, and most of the
time this means sensing Appendix C XHTML to all user agents with a
text/html header. So Appendix C XHTML is usually in reality a flavour of
formally malformed HTML.

On alternative is for the server to do content negotiation and serve
Appendix C (or separate real) XHTML with an XHTML content type header to
user agents that assert their acceptance of it, and to send only
Appendix C XHTML (or separate HTML) with a text/html content type header
to user agents that do not claim to recognise XHTML.

Obviously sending two different versions depending on the user agent's
ability to accept contents is at least slightly more effort than not
doing so. Making Appendix C XHTML look appealing as it is capable of
being sent as both HTML and XHTML. However, we have a particular
interest in the scripting of web browsers and so an interest in whether
the browser's DOM is an XHTML DOM (case sensitive, interested in
namespaces, preferring slightly different approaches, such as using
setAttribute, lacking some convenience and shortcut properties) or an
HTML DOM (case insensitive, ignorant of namespaces, preferring different
approaches, such as direct assignment to element properties, and filled
with convenience properties and non-standard shortcuts).

If a document is served as text/html it is interpreted as HTML and it is
an HTML DOM that the browser builds for it, while if it is served as
application/xhtml+xml it is interpreted as XHTML and it is an XHTML DOM
that the browser builds for it. A very significant proportion of scripts
are not interoperable between the two DOMs, and writing interoperable
scripts adds an entirely new level of testing and branching if the
script is anything but the most trivial. So Appendix C XHTML doesn't
really remove the issue of serving alternative content to different user
agents, it just moves the problem to a different place; the choice of
accompanying script files

However, that general lack of technical competence in web development
that lead to the HTML browsers using such extreme error-correction also
manifests itself in the use of XHTML. Many having no appreciation of
HTTP headers, or sending all of their XHTML as text/html, and finding
that it is completely successful to script these documents as if they
were HTML (possibly not even being aware that an XHTML DOM would need be
scripted differently), because in reality they are HTML (if malformed).
Which means that if the future ever offers an opportunity for the viable
commercial use of XHTML an awful lot of people are going to be very
disappointed to find that all their scripts suddenly stop working.

Probably the most sensible reaction to all of this is that if you want
to script a document you should probably write it in, and serve it as
formally valid HTML, only.

Richard.

[catorcio]

Re: innerHTML not good in Firefox?

catorcio wrote:[color=blue]
> I'm trying to have some text in my page changed by
> clicking a button...[/color]

Thanks everybody!

C.

[Steve Sobol]

Re: innerHTML not good in Firefox?

John W. Kennedy wrote:
[color=blue]
> Or you can just try the experiment with a server that serves XHTML as
> XHTML with no content negotiation.[/color]

I've not had any problems with IE6 and a proper XHTML Transitional or Strict
DOCTYPE.

--
JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638)
Steven J. Sobol, Geek In Charge / sjsobol@JustThe .net / PGP: 0xE3AE35ED

"The wisdom of a fool won't set you free"
--New Order, "Bizarre Love Triangle"

[Martin Honnen]

Re: innerHTML not good in Firefox?



Steve Sobol wrote:
[color=blue]
> I've not had any problems with IE6 and a proper XHTML Transitional or
> Strict DOCTYPE.[/color]

The Content-Type HTTP response header the server sends is decisive, if
you serve up your XHTML as application/xhtml+xml then IE does not render
it. Only if you serve up the XHTML as text/html then IE can render it
but of course then it is not treated as XML at all but parsed according
to HTML/SGML rules.

--

Martin Honnen

http://JavaScript.FAQTs.com/

[Steve Sobol]

Re: innerHTML not good in Firefox?

Martin Honnen wrote:
[color=blue]
> The Content-Type HTTP response header the server sends is decisive, if
> you serve up your XHTML as application/xhtml+xml then IE does not render
> it. Only if you serve up the XHTML as text/html then IE can render it
> but of course then it is not treated as XML at all but parsed according
> to HTML/SGML rules.[/color]

Heh, y'all are right... the xhtml pages I've created seem to render just fine,
but they *are* all being served as text/html.

It shouldn't be hard to create an IE plugin that properly handles
application/xhtml+xml, even if the plugin just makes IE *think* it's rendering
text/html...

....on the other hand, we shouldn't have to do that.

(Cool! More brokenness in IE!)

--
JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638)
Steven J. Sobol, Geek In Charge / sjsobol@JustThe .net / PGP: 0xE3AE35ED

"The wisdom of a fool won't set you free"
--New Order, "Bizarre Love Triangle"

[Richard Cornford]

Re: innerHTML not good in Firefox?

Steve Sobol wrote:[color=blue]
> Martin Honnen wrote:
>[color=green]
>> The Content-Type HTTP response header the server sends is
>> decisive, ...[/color][/color]
<snip>[color=blue]
> Heh, y'all are right... the xhtml pages I've created seem
> to render just fine, but they *are* all being served as
> text/html.[/color]

So they have been HTML documents all along.
[color=blue]
> It shouldn't be hard to create an IE plugin that properly
> handles application/xhtml+xml, even if the plugin just
> makes IE *think* it's rendering text/html...[/color]
<snip>

That would be a seriously bad idea. As it is the server is in a position
to dictate how the document will be interpreted, and arrange that it is
accompanied by other content (i.e. scripts) appropriate to that
interpretation. If the client is allowed to decide to interpret XHTML as
HTML it becomes impossible to determine which type of DOM the browser is
going to create, and so impossible to serve scripts tailored to that
DOM.

Richard.