innerHTML not good in Firefox?

Discussion in 'Javascript' started by catorcio, May 14, 2005.

  1. catorcio

    catorcio Guest

    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(newtext)
    {
    text.innerHTML = newtext;
    }


    </script>

    <p id="text">Old text</p>
    <input type="button" onclick="changeText('New text')"
    value="Change text" />
    ....
     
    catorcio, May 14, 2005
    #1
    1. Advertising

  2. catorcio wrote:
    > 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(newtext)
    > {
    > text.innerHTML = newtext;
    > }


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

    var text = document.getElementById('text');

    HTH
     
    Markus Fischer, May 14, 2005
    #2
    1. Advertising

  3. catorcio

    Jay Guest

    "catorcio" <> wrote in message
    news:d65tj2$mnd$...
    > 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.



    Works for me 1.0.3

    Jay

    > ...
    > <script type="text/javascript">
    >
    > function changeText(newtext)
    > {
    > text.innerHTML = newtext;
    > }
    >
    >
    > </script>
    >
    > <p id="text">Old text</p>
    > <input type="button" onclick="changeText('New text')" value="Change text"
    > />
    > ...
     
    Jay, May 15, 2005
    #3
  4. catorcio wrote:
    > 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(newtext)
    > {
    > text.innerHTML = newtext;
    > }
    >
    >
    > </script>
    >
    > <p id="text">Old text</p>
    > <input type="button" onclick="changeText('New text')" value="Change
    > text" />
    > ....


    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)
     
    John W. Kennedy, May 15, 2005
    #4
  5. Steve Sobol <> writes:

    > IE 6 DOES most definitely support XHTML


    .... 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 -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, May 15, 2005
    #5
  6. catorcio

    Jay Guest

    "John W. Kennedy" <> wrote in message
    news:Y1Ahe.3446$...
    > catorcio wrote:
    >> 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(newtext)
    >> {
    >> text.innerHTML = newtext;
    >> }
    >>
    >>
    >> </script>
    >>
    >> <p id="text">Old text</p>
    >> <input type="button" onclick="changeText('New text')" value="Change text"
    >> />
    >> ....

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


    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
     
    Jay, May 15, 2005
    #6
  7. Steve Sobol wrote:
    > John W. Kennedy wrote:
    >
    >> 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.

    >
    >
    > The other option: you're wrong.
    >
    > IE 6 DOES most definitely support XHTML


    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
    "Information is light. Information, in itself, about anything, is light."
    -- Tom Stoppard. "Night and Day"
     
    John W. Kennedy, May 15, 2005
    #7
  8. Jay wrote:
    > "John W. Kennedy" <> wrote in message
    > news:Y1Ahe.3446$...
    >
    >>catorcio wrote:
    >>
    >>>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(newtext)
    >>> {
    >>> text.innerHTML = newtext;
    >>> }
    >>>
    >>>
    >>></script>
    >>>
    >>><p id="text">Old text</p>
    >>><input type="button" onclick="changeText('New text')" value="Change text"
    >>>/>
    >>>....

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

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


    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"
     
    John W. Kennedy, May 15, 2005
    #8
  9. Jay wrote:
    > John W. Kennedy wrote:

    <snip>
    >> Since Internet Explorer does not support XHTML, ...

    <snip>
    > IE does not support XHTML?


    No it does not. Internet Explorer is an HTML web browser.

    > I'd like to read up on this if you have a URL as I
    > wasn't led to believe this.


    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.
     
    Richard Cornford, May 15, 2005
    #9
  10. catorcio

    catorcio Guest

    catorcio wrote:
    > I'm trying to have some text in my page changed by
    > clicking a button...


    Thanks everybody!

    C.
     
    catorcio, May 15, 2005
    #10
  11. Steve Sobol wrote:

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


    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/
     
    Martin Honnen, May 15, 2005
    #11
  12. Steve Sobol wrote:
    > Martin Honnen wrote:
    >
    >> The Content-Type HTTP response header the server sends is
    >> decisive, ...

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


    So they have been HTML documents all along.

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

    <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.
     
    Richard Cornford, May 15, 2005
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. webdev

    innerHTML not working in Firefox

    webdev, Oct 3, 2004, in forum: Javascript
    Replies:
    3
    Views:
    349
    Fred Oz
    Oct 3, 2004
  2. McKirahan
    Replies:
    8
    Views:
    184
    McKirahan
    Oct 12, 2005
  3. sonic
    Replies:
    5
    Views:
    301
    Randy Webb
    Jul 11, 2006
  4. Derek Basch
    Replies:
    1
    Views:
    136
  5. Derek Basch
    Replies:
    0
    Views:
    175
    Derek Basch
    May 24, 2007
Loading...

Share This Page