Re: Putting DIV wrapper around all code in body

George Maicovschi wrote:

From personal experience I know that moving a LOT of elements (or
creating a LOT of new ones) can cause the browser to move slowly and
make a user experience not so nice, so this method shouldn't be used
on very large pages.

Couldn't we try an approach using the innerHTML? :-/

In any case browser need to remove all elements from body and insert them to DIV, but in the case of innerHTML here is additional conversion from DOM to HTML (text=body.innerHTML) and then back from HTML to DOM (div.innerHTML=text) so I don't think it's more fast then direct moving.
.

Relevant Pages

  • Re: InnerHTML question
    ... that IE and Firefox both handle .innerHTML differently. ... any more versions of HTML beyond 4.01, they then gout bogged down in XHTML ... HTML DOM for them to script. ...
    (comp.lang.javascript)
  • Re: Microsoft and attributes--will they ever figure them out?
    ... Would be full of DOM defaults, user input, ... Like innerHTML, the innerHTML replacement ... Per HTML 4.01, it only needs to ... That kind of emulation would need to be restricted to attributes ...
    (comp.lang.javascript)
  • Re: JS, DOM and tr... IE problems!
    ... I've got a problem with javascript and DOM. ... Capitalisation is often used in HTML markup, ... If you post what your browser is actually getting (e.g. using view ...
    (comp.lang.javascript)
  • Re: How do I know if theres a certain HTML element in an HTML string (without indexOf)?
    ... very hard to find the DOM element's attributes. ... If you are letting a user enter HTML into a text area, ... Create a DOM element (a div is likely best) then insert the text ... using innerHTML. ...
    (comp.lang.javascript)
  • Re: InnerHTML question
    ... that IE and Firefox both handle .innerHTML differently. ... Remember that the W3C took the stance that they were not going to release any more versions of HTML beyond 4.01, they then gout bogged down in XHTML 2.0 and are now working on HTML 5. ... Scripting with the assumption that scripts that now only ever interact with HTML DOM can be simply dropped into XHTML DOMs at some future time when all browser support XHTML is utterly unrealistic for anything but the most trivial scripts. ... If you are writing a script that can never successfully interact with an XHTML DOM you may as well accept that you are scripting HTML (no matter what the mark-up may resemble) and employ the features provided by an HTML DOM. ...
    (comp.lang.javascript)