Lachlan Hunt wrote:
> 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,
That's why I called it "a possible alternative"... ;)
> it only seems
> to fulfil one particular use case by moving childNodes from one parent
> to another.
I think it eases the job of wrapping all the children of a node into a new
element inside that same node.
Like in this simple example (using an A element):
<h1>This is the <em>Title</em></h1>
<h1><a>This is the <em>Title</em></a></h1>
> 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
It says in these comments that the author did not find a DOM alternative and
instead went with a CSS solution.
> 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.
> 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.
>> * 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)
I think I need to remove this link from there, I'm getting too much feedback
about something I didn't even wrote ;)
As a side note, I came across a comment of yours on
http://domscripting.com/blog/display/35 (the very first one) and I'm
surprised how that comment differs from the feedback you're giving me
here...
---
Regards,
Thierry | www.TJKDesign.com
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
