Thierry Koblentz wrote:
I'd like to get some feedback on this before I publish it and make a
fool of myself ;)
http://www.tjkdesign.com/articles/a_possible_alternative_to_innerHTML.asp
Demo page: http://www.tjkdesign.com/articles/TJK_moveNodes_demo.asp
That doesn't seem to be a true alternative to innerHTML, it only seems
to fulfil one particular use case by moving childNodes from one parent
to another.
innerHTML does several things and has both getter and setter functions.
Getter: returns the markup representation as a string.
Setter: Parses the provided string into a DocumentFragment, removes all
children from the element appends the new fragment.
It's working with a string that seems to be the controversial part of
innerHTML. I wrote an alternative for its getter function which returns
a document fragment instead of a string. The setter function can then
be replaced by a function that removes all child nodes and appends that
fragment.
Node.prototype.cloneChildNodes = function() {
var df = document.createDocumentFragment();
for (var i = 0; i < this.childNodes.length; i++) {
df.appendChild(this.childNodes[i].cloneNode(true));
}
return df;
}
Note: That script is just a demonstration of the concept and, while it
will work in modern browsers, it won't work in IE. That script was
originally written in this comment:
http://www.456bereastreet.com/archive/200609/automatic_pullquotes_with_javascript_and_css/#comment12
As for the arguments against innerHTML that you referred to in your article:
* It's not a standard...
Many features started their lives as non-standard extensions and that is
changing.
http://www.whatwg.org/specs/web-apps/current-work/#dynamic0
* Since it's not a standard, it isn't terribly future proof. It's not
supposed to work under the application/xhtml+xml MIME type that XHTML
documents are supposed to be served under. (Firefox 1.5 changed this
by allowing it for some reason)
Although it wasn't originally designed by MS to only work in HHTML
(probably because IE doesn't support XHTML), there is no reason it can't
work as long as the string is well-formed. It is going to be defined by
the WHATWG.
http://www.whatwg.org/specs/web-apps/current-work/#dynamic1
* innerHTML is a string. The DOM is not a string, it's a hierarchal
object structure....
That's true, but markup starts as a string in a file and when a file is
loaded that string is parsed into the DOM structure. What makes parsing
a file acceptable, but parsing a string during a script execution
unacceptable?
* It makes for some nearly illegible code in a lot of instances, with
escaped quotes and plus signs all over the place appending data to
the string, which in my opinion makes it difficult to maintain.
I agree that building markup in scripts by concatenating strings is bad
practice and that is not an ideal use of innerHTML. However, innerHTML
is perfect for when you receive a string of HTML from an another source
(e.g. via XHR or input from a textarea)
--
Lachlan Hunt
http://lachy.id.au/
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
