innerHTML

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • PaPa

    innerHTML

    I'm not sure this is a javascript issue or an HTML issue. I notice
    that when I extract the contents of a div using the innerHTML property
    (?), that I wind up with a literal variable (?) which exactly matches
    the contents of the div with one exception.

    It seems that whenever the code includes a tag which uses the forward
    slash against the closing bracket (say the break tag ..... />) that
    the browser, or HTML, or javascript, or something else, removes the
    forward slash.

    I've tried this on safari, chrome, mozilla, and IE and they all seem
    to do the same thing.

    Can someone tell my why this is happening and if there is a way to get
    around it?

    Regards,
    PaPa

    Here is some code which demonstrates the issue.

    <body >

    <div id="test1">
    <p>This is a test to see if the / symbol is recreated here </p>
    <pnow we will add a break tag </p><br />
    </div>

    <script type="text/javascript">
    var lit=document.ge tElementById("t est1").innerHTM L;
    alert(lit);

    </script>


    </body>

    In the alert box, you should see all the forward slashes in the
    "test1" div, except for the forward slash in the br tag.
  • Conrad Lender

    #2
    Re: innerHTML

    On 2008-10-12 17:05, PaPa wrote:
    I'm not sure this is a javascript issue or an HTML issue. I notice
    that when I extract the contents of a div using the innerHTML property
    (?), that I wind up with a literal variable (?) which exactly matches
    the contents of the div with one exception.
    >
    It seems that whenever the code includes a tag which uses the forward
    slash against the closing bracket (say the break tag ..... />) that
    the browser, or HTML, or javascript, or something else, removes the
    forward slash.
    I don't know what a "literal variable" is, but your assumption that the
    innerHTML property holds the div contents exactly as you wrote them is
    incorrect, and not only in the case of empty elements like <br/>. Try
    this, for example (in an HTML document, not XHTML):

    <div><table><tr ><td>hello</table></div>

    The innerHTML of the <divwill include the implicit <tbodyelement as
    well the closing tags for <tdand <tr>:

    <table><tbody>< tr><td>hello</td></tr></tbody></table>

    innerHTML returns the parsed and modified HTML contents of an element,
    the way the browser sees it.
    Can someone tell my why this is happening and if there is a way to get
    around it?
    Why do you want to get around it? In current browsers, even if your
    document is XHTML, you can assign what you retrieved from one element's
    innerHTML property to another element's innerHTML property without
    errors. The contents will be automatically converted to a valid XHTML
    fragment. You can even do something like this:

    node.innerHTML = "<u><i>hey</u></i>";

    which will automagically be fixed to "<u><i>hey</i></u>". Older browsers
    like Firefox v1 or Safari v? did not support innerHTML as a setter in
    XML documents, even though reading the value would work.

    I don't think there's any way to get the literal markup contents of an
    element, at least not through the DOM.


    - Conrad

    Comment

    • Thomas 'PointedEars' Lahn

      #3
      Re: innerHTML

      PaPa wrote:
      On Oct 12, 11:47 am, Conrad Lender <crlen...@yahoo .comwrote:
      >[...] In current browsers, even if your document is XHTML, you can
      >assign what you retrieved from one element's innerHTML property to
      >another element's innerHTML property without errors.
      Of course you cannot. That is only possible when the XHTML markup
      is not regarded XHTML but tag soup in the first place.
      >The contents will be automatically converted to a valid XHTML fragment.
      >You can even do something like this:
      >>
      >node.innerHT ML = "<u><i>hey</u></i>";
      >>
      >which will automagically be fixed to "<u><i>hey</i></u>". Older
      >browsers like Firefox v1 or Safari v? did not support innerHTML as a
      >setter in XML documents, even though reading the value would work.
      It is not a matter of the browser but of the used markup parser. But even
      if writing or reading the property would work there, it would accomplish
      nothing useful, given that the languages in question are largely incompatible.
      >I don't think there's any way to get the literal markup contents of an
      >element, at least not through the DOM.
      >[...]
      It is possible.
      Thanks for the reply Conrad.
      Thanks for trimming your quotes next time, especially for not quoting
      signatures anymore.

      <http://jibbering.com/faq/#FAQ2_3>
      The reason I want to get "around it" is that I am using the data to show
      the code that actually exists in the div. I have created a (rather
      labyrinthine) function that receives the data from the innerHTML
      property(?) and transforms it into the raw XHTML so the viewer can see
      the code that created the div.
      Since the property is called `innerHTML', and not `innerXHTML', on purpose,
      and the parsing of `<br/>' like `<br>' by tag-soup parsers is merely based
      on false error-correction (correct would have been to parse it the same as
      `<br>&gt;'), you cannot solve this with `innerHTML'.

      Existing editors have either attempted to correct the false result of
      error-corrected markup to XHTML back again (which would involve rather
      extensive user-defined parsing), or employed an XML serializer if the
      content really is an XHTML fragment.
      [...]
      [atrocious code snipped]
      No, thanks.


      PointedEars
      --
      Use any version of Microsoft Frontpage to create your site.
      (This won't prevent people from viewing your source, but no one
      will want to steal it.)
      -- from <http://www.vortex-webdesign.com/help/hidesource.htm>

      Comment

      • Conrad Lender

        #4
        Re: innerHTML

        On 2008-10-12 19:03, Thomas 'PointedEars' Lahn wrote:
        >>[...] In current browsers, even if your document is XHTML, you
        >>can assign what you retrieved from one element's innerHTML
        >>property to another element's innerHTML property without errors.
        >
        Of course you cannot. That is only possible when the XHTML markup is
        not regarded XHTML but tag soup in the first place.
        Did you actually test that? Then give me a counter example where you get
        an error when at 'node2.innerHTM L = node1.innerHTML '. And yes,
        definitely is possible in valid XHTML documents.
        There are a number of caveats, of course: copying content in this way
        may lead to duplicate id attributes; setting innerHTML on an img element
        isn't going to do anything useful; inserting the innerHTML of a tbody
        into a div won't create table rows there; etc. But you get the point.
        >>Older browsers like Firefox v1 or Safari v? did not support
        >>innerHTML as a setter in XML documents, even though reading the
        >>value would work.
        >
        It is not a matter of the browser but of the used markup parser. But
        even if writing or reading the property would work there, it would
        accomplish nothing useful, given that the languages in question are
        largely incompatible.
        I was under the impression that the same parser was used for both HTML
        and XHTML, only running in different modes. And you can verify for
        yourself that using innerHTML as a setter in XHTML documents does in
        fact work. Whether you think that's "useful" is up to you.

        I assume (without having checked the source), that the value returned by
        innerHTML will never be a "tag soup", but the browser's parsed and
        prepared representation of the source (X)HTML. The other way around,
        when using innerHTML as a setter, the engine will do its best to convert
        whatever it's given to a valid (X)HTML fragment.
        >>I don't think there's any way to get the literal markup contents
        >>of an element, at least not through the DOM. [...]
        >
        It is possible.
        How?
        Since the property is called `innerHTML', and not `innerXHTML', on
        purpose, and the parsing of `<br/>' like `<br>' by tag-soup parsers
        is merely based on false error-correction (correct would have been to
        parse it the same as `<br>&gt;') [..]
        It appears that in current implementations the methods that implement
        innerHTML are aware of the document language, and are transparently
        converting between HTML and XHTML. At the time when Microsoft created
        innerHTML, XHTML was still a few years away from being a standard, which
        would explain the name and the way it behaves.


        - Conrad

        Comment

        • PaPa

          #5
          Re: innerHTML

          Thanks Conrad and Thomas,

          You've helped me understand how much work I have to do. And thanks
          for the tip on TagSoup. I had never heard of that and it looks like a
          tool that I might use if I can figure out how to use it.

          Regards to both,
          PaPa

          Comment

          • David Mark

            #6
            Re: innerHTML

            On Oct 12, 3:50 pm, Conrad Lender <crlen...@yahoo .comwrote:
            On 2008-10-12 19:03, Thomas 'PointedEars' Lahn wrote:
            >
            >[...] In current browsers, even if your document is XHTML, you
            >can assign what you retrieved from one element's innerHTML
            >property to another element's innerHTML property without errors.
            >
            Of course you cannot.  That is only possible when the XHTML markup is
            not regarded XHTML but tag soup in the first place.
            >
            Did you actually test that? Then give me a counter example where you get
            No need. He is right (at least in the case of several major
            browsers.) Don't use innerHTML with an XHTML DOM.
            an error when at 'node2.innerHTM L = node1.innerHTML '. And yes,
            Try it in an XHTML document (a real XHTML document.)

            definitely is possible in valid XHTML documents.
            Certainly it would have to be a valid XHTML document. You can't even
            see invalid ones.
            There are a number of caveats, of course: copying content in this way
            may lead to duplicate id attributes; setting innerHTML on an img element
            isn't going to do anything useful; inserting the innerHTML of a tbody
            into a div won't create table rows there; etc. But you get the point.
            Those are not the issue at hand.
            >
            >Older browsers like Firefox v1 or Safari v? did not support
            >innerHTML as a setter in XML documents, even though reading the
            >value would work.
            Did you test that?
            >
            It is not a matter of the browser but of the used markup parser.  But
            even if writing or reading the property would work there, it would
            accomplish nothing useful, given that the languages in question are
            largely incompatible.
            >
            I was under the impression that the same parser was used for both HTML
            and XHTML, only running in different modes. And you can verify for
            Aha! Therein lies the basic misconception.
            yourself that using innerHTML as a setter in XHTML documents does in
            fact work. Whether you think that's "useful" is up to you.
            You only thought you were using XHTML and it isn't useful.
            >
            I assume (without having checked the source), that the value returned by
            Always a bad move.
            innerHTML will never be a "tag soup", but the browser's parsed and
            prepared representation of the source (X)HTML. The other way around,
            Sort of.
            when using innerHTML as a setter, the engine will do its best to convert
            whatever it's given to a valid (X)HTML fragment.
            More or less. Except when XML parse mode is in use and then the
            browser will likely deny your request with an exception.

            [snip]
            >
            It appears that in current implementations the methods that implement
            innerHTML are aware of the document language, and are transparently
            converting between HTML and XHTML. At the time when Microsoft created
            innerHTML, XHTML was still a few years away from being a standard, which
            would explain the name and the way it behaves.
            You are lost. In FireFox 3, Tools | Page Info, second item (type.)
            What does it say on every page you ever tested with innerHTML?

            Comment

            • Conrad Lender

              #7
              Re: innerHTML

              On 2008-10-12 21:50, Conrad Lender wrote:
              >Of course you cannot. That is only possible when the XHTML markup is
              >not regarded XHTML but tag soup in the first place.
              >
              Did you actually test that? Then give me a counter example where you get
              an error when at 'node2.innerHTM L = node1.innerHTML '. And yes,
              definitely is possible in valid XHTML documents.
              Yikes, did I really write that? I did some more testing with other
              implementations , and there will in fact be errors. That makes three
              mistakes in a single paragraph, two grammatical and one factual, so...

              ....please disregard the whole post. Using innerHTML as a setter in XML
              documents is not a good idea.


              - Conrad

              Comment

              Working...