locked
IE11 - DOM elements saved in arrays have no innerHTML when recalled RRS feed

  • Question

  • I have a cascading drop-down plugin for jQuery that creates an array of every filterable <option> in the child <select>, and when the parent is changed, the child is purged and then every matching <option> is re-added.  Hasn't had any issues anywhere... until IE11, which doesn't save the innerHTML. The child *does* filter correctly, as each <option>'s value is preserved, but the text isn't, resulting in this: http://i.imgur.com/FVNJybj.png

    Similarly, you may notice that the pager says there are 4 items, but nothing is displayed. That data is loaded via an AJAX call, and an HTML string is constructed, then inserted with jQuery.html(). I've put in debug code to verify that IE11 is in fact constructing the string correctly, however, only the <tr> elements are actually injected into the DOM. This can be seen here: http://i.imgur.com/AxFYc7J.png

    The selected line in the console is the constructed HTML string printed via console.log() the line prior to inserting into the DOM. From my chair, it looks to me like IE11 is simply implementing HTML control functions incorrectly. The exact same behavior is apparent when using either HTML strings or qualified objects.

    This is a system-breaking problem. Our CRM is unusable in IE11 because of this, and this is functionality that IE6 didn't even have a problem with. Firefox and Chrome predictably work as expected.


    • Edited by timeshifter Friday, February 7, 2014 8:11 PM links
    Friday, February 7, 2014 8:09 PM

All replies

  • Hi,

    Have you tried a more recent version of jQuery or jQuery.ui or support.jquery.com or the support portal of your CRM vendor?

    to save confusion please include a link to your website or a mashup with your questions to this forum for questions about html, css and scripting for website developers... Importantly you did not mention your jQuery version, nor your plugin name or its version. We can read code better than pretty screen-shots. This screen shot http://i.imgur.com/AxFYc7J.png shows that you have not validated your markup and correct the obvious errors. (validator.w3.org)... I see that you are using asp.net (what version? have you updated the browser caps file? IE11 sends a different uas string).

    You best avenue for support is to contact your CRM vendor.

    Compatibility Changes in IE11


    Rob^_^

    Saturday, February 8, 2014 12:10 AM
  • Hi, again....

    I see that you are using helvical fonts...

    Tools>Internet Options>General tab, 'Accessibility' button. Ignore font styles specified on web pages.

    you must have some Adobe software installed on your development machine.


    Rob^_^

    Saturday, February 8, 2014 12:30 AM
  • >> "IE11 - DOM elements saved in arrays have no innerHTML when recalled"

        sel = document.createElement('select');
        <select></select>

        sel.canHaveHTML;
        false

    Saturday, February 8, 2014 10:31 PM
  • @ifiredog, @banneduser @flatsem @Domitri Nickolas @curiously idle

    shill-be wrong eating wind again.


    Rob^_^


    Sunday, February 9, 2014 3:18 AM
  • Hi,

    Have you tried a more recent version of jQuery or jQuery.ui or support.jquery.com or the support portal of your CRM vendor?

    to save confusion please include a link to your website or a mashup with your questions to this forum for questions about html, css and scripting for website developers... Importantly you did not mention your jQuery version, nor your plugin name or its version. We can read code better than pretty screen-shots. This screen shot http://i.imgur.com/AxFYc7J.png shows that you have not validated your markup and correct the obvious errors. (validator.w3.org)... I see that you are using asp.net (what version? have you updated the browser caps file? IE11 sends a different uas string).

    You best avenue for support is to contact your CRM vendor.

    Compatibility Changes in IE11


    Rob^_^

    Most recent version of jQuery, ASP.Net 4.0, browser file has been updated, and I am my CRM vendor.

    I've built a functional demo here.


    The "obvious errors" you're mentioning are actually jQuery Migrate alerting me to the fact that I'm using a deprecated function. There are no markup or script errors.

    • Edited by timeshifter Monday, February 10, 2014 3:17 PM
    Monday, February 10, 2014 3:11 PM
  • Hi, again....

    I see that you are using helvical fonts...

    Tools>Internet Options>General tab, 'Accessibility' button. Ignore font styles specified on web pages.

    you must have some Adobe software installed on your development machine.


    Rob^_^

    And that's relevant... how? You didn't even notice that it's coming from bootstrap.css?

    • Edited by timeshifter Monday, February 10, 2014 3:18 PM
    Monday, February 10, 2014 3:16 PM
  • I have a cascading drop-down plugin for jQuery that creates an array of every filterable <option> in the child <select>, and when the parent is changed, the child is purged and then every matching <option> is re-added.  Hasn't had any issues anywhere... until IE11, which doesn't save the innerHTML. The child *does* filter correctly, as each <option>'s value is preserved, but the text isn't, resulting in this: http://i.imgur.com/FVNJybj.png

    Similarly, you may notice that the pager says there are 4 items, but nothing is displayed. That data is loaded via an AJAX call, and an HTML string is constructed, then inserted with jQuery.html(). I've put in debug code to verify that IE11 is in fact constructing the string correctly, however, only the <tr> elements are actually injected into the DOM. This can be seen here: http://i.imgur.com/AxFYc7J.png

    The selected line in the console is the constructed HTML string printed via console.log() the line prior to inserting into the DOM. From my chair, it looks to me like IE11 is simply implementing HTML control functions incorrectly. The exact same behavior is apparent when using either HTML strings or qualified objects.

    This is a system-breaking problem. Our CRM is unusable in IE11 because of this, and this is functionality that IE6 didn't even have a problem with. Firefox and Chrome predictably work as expected.

    We can't fix jQuerry. You sould report this and or ask for help at jQuerry forums.

    You should also pay attention to these:

       File: demo4.html
       SEC7111: HTTPS security is compromised by http://code.jquery.com/jquery-latest.min.js
       File: demo4.html
       SCRIPT5009: '$' is undefined
       File: demo4.html, Line: 129, Column: 3
       HTML1114: Codepage us-ascii from (HTTP header) overrides conflicting codepage utf-8 from (META tag)
       File: demo4.html

    p.s.:

    You should never use DHTML methods on browser controls such as form elements and similar. Browsers who have true or native support for DHTML, will not re-invoke or reinitialize those controls. You have to use proper DOM methods for that.

    Monday, February 10, 2014 10:13 PM
  • I'm not asking you to fix jQuery. jQuery works perfectly well. I'm *telling* you that there is a fundamental flaw in IE11, and I've provided a demonstration of it. This is basic script stuff; every GUI browser made in the past 13 years knows how to do it. IE11 is simply ignoring innerHTML here. I don't see how you can view that as anything other than a massive implementation flaw.
    Monday, February 10, 2014 10:17 PM
  • I'm not asking you to fix jQuery. jQuery works perfectly well. I'm *telling* you that there is a fundamental flaw in IE11, and I've provided a demonstration of it. This is basic script stuff; every GUI browser made in the past 13 years knows how to do it. IE11 is simply ignoring innerHTML here. I don't see how you can view that as anything other than a massive implementation flaw.

    You are completely wrong. It is not ignoring innerHTML, on contrary. But you don't understand the difference.

    DHTML methods should not be used on browser controls, since they are not plain html elements, you are required to use proper DOM methods to instantiate browser controls. Or if you like to stick to DHTML even when rewriting browser control html code, than you'll have to step back to using document write instead. Otherwise controls will not re-initialize by themselves.

    Furthermore your arr.push($(this)), is returning a function body of some jQuerry method, for each element when inspected with arr[0].text; for there is a: function(e){return x.access(this,function(e){return e===t?x.text(this):this.empty().append((this[0]&&this[0].ownerDocument||a).createTextNode(e))},null,e,arguments.length)}  instead.

    Monday, February 10, 2014 11:09 PM
  • Hi, again....

    I see that you are using helvical fonts...

    Tools>Internet Options>General tab, 'Accessibility' button. Ignore font styles specified on web pages.

    you must have some Adobe software installed on your development machine.


    Rob^_^

    And that's relevant... how? You didn't even notice that it's coming from bootstrap.css?

    There are known conflicts with Adobe Helvical fonts...

    Do you have any Adobe software installed?


    Rob^_^

    Tuesday, February 11, 2014 1:57 AM
  • Hi,

    Have you tried a more recent version of jQuery or jQuery.ui or support.jquery.com or the support portal of your CRM vendor?

    to save confusion please include a link to your website or a mashup with your questions to this forum for questions about html, css and scripting for website developers... Importantly you did not mention your jQuery version, nor your plugin name or its version. We can read code better than pretty screen-shots. This screen shot http://i.imgur.com/AxFYc7J.png shows that you have not validated your markup and correct the obvious errors. (validator.w3.org)... I see that you are using asp.net (what version? have you updated the browser caps file? IE11 sends a different uas string).

    You best avenue for support is to contact your CRM vendor.

    Compatibility Changes in IE11


    Rob^_^

    Most recent version of jQuery, ASP.Net 4.0, browser file has been updated, and I am my CRM vendor.

    I've built a functional demo here.


    The "obvious errors" you're mentioning are actually jQuery Migrate alerting me to the fact that I'm using a deprecated function. There are no markup or script errors.

    see http://www.texotela.co.uk/code/jquery/select/

    or other offered solutions from this web search

    http://www.bing.com/search?q=populate+a+select+based+on+the+selected+option+in+another+select&src=IE-SearchBox&FORM=IE11SR


    Rob^_^

    Tuesday, February 11, 2014 3:30 AM
  • I'm not asking you to fix jQuery. jQuery works perfectly well. I'm *telling* you that there is a fundamental flaw in IE11, and I've provided a demonstration of it. This is basic script stuff; every GUI browser made in the past 13 years knows how to do it. IE11 is simply ignoring innerHTML here. I don't see how you can view that as anything other than a massive implementation flaw.

    You are completely wrong. It is not ignoring innerHTML, on contrary. But you don't understand the difference.

    DHTML methods should not be used on browser controls, since they are not plain html elements, you are required to use proper DOM methods to instantiate browser controls. Or if you like to stick to DHTML even when rewriting browser control html code, than you'll have to step back to using document write instead. Otherwise controls will not re-initialize by themselves.

    Furthermore your arr.push($(this)), is returning a function body of some jQuerry method, for each element when inspected with arr[0].text; for there is a: function(e){return x.access(this,function(e){return e===t?x.text(this):this.empty().append((this[0]&&this[0].ownerDocument||a).createTextNode(e))},null,e,arguments.length)}  instead.

    Alright, I've de-jQuery-ified all the select manipulation code on the demo found here, but if you access the cascades object in the console, you'll see exactly the same behavior as originally seen: the stored options simply have no innerHTML. Is there something else I'm missing here? Again, this works perfectly in Firefox and Chrome.
    Tuesday, February 11, 2014 3:44 PM
  • Well sure, because none of the script is executing. It won't filter, and that's the whole point.
    Tuesday, February 11, 2014 4:44 PM
  • ......yeah, that's the subject of this entire thread. But inspect it, and you'll see that the filter *does* work, but the matching options simply don't maintain their innerHTML.
    Tuesday, February 11, 2014 4:51 PM
  • Maybe try my demo in a browser that doesn't suck? It's called *cascade*. Select an option from the first, and the second filters accordingly. I've seen that demo, and I'm not sure why it works, but mine doesn't. I've tried HTML strings, jQuery objects, and the raw DOM objects, and IE11 simply will not cooperate.
    Tuesday, February 11, 2014 4:58 PM
  • "Yours fails." Gee, that's helpful. *Why?* It works perfectly in any other browser. It worked perfectly in IE8. Why does it fail in IE11?

    Anyone else? Maybe somebody who actually understands the problem?

    Tuesday, February 11, 2014 5:30 PM
  • Because my script needs to preserve the entire state of each original option. String concatenation is not the correct answer when that's a requirement.
    Tuesday, February 11, 2014 7:13 PM
  • Why don't you look down a few lines to the part where I add options back in? Or would you rather I just assume you're 11 and explain it line by line?
    • Edited by timeshifter Tuesday, February 11, 2014 7:40 PM
    Tuesday, February 11, 2014 7:38 PM
  • Um... because I'm not *calling* innerHTML after that. That is there only to clear the child select of its options. Immediately after that, the original option list is scanned and all options that match are added back in, via child.appendChild(data[i]). If you would bother to *look* at the code I provided, the filtering *works*. The issue is that IE11 is not saving the innerHTML of the options when it first builds the array. Look at the cascades object in console to verify this.

    Screenshot: http://i.imgur.com/4DymoGT.png

    The filter works. IE11 is simply not storing the original options' innerHTML.


    • Edited by timeshifter Tuesday, February 11, 2014 8:00 PM
    Tuesday, February 11, 2014 7:57 PM
  • Dude.. you're completely missing the point. I'm clearing out the select so I can add back in the appropriate options. Look at that last screenshot. The correct options *are* being put back in! IE11 simply isn't preserving the option's innerHTML when I create the initial data array, which happens before any filtering, again, as shown in my screenshot.

    You are not looking at my code. And if you are, you are miserably failing to understand it. And you continue to address something that is not the issue at hand. If you can't comprehend the simple problem here, please don't bother replying. I don't need the raised blood pressure.

    Tuesday, February 11, 2014 8:41 PM
  • Originally it was HTML string concatenation. Then I created an array from the source <option> elements. Now, my demo page creates entirely new elements based on the source options, no cloning or references to the original markup.

    And IE11 *still* kills the innerHTML of every option in the array.

    Tuesday, February 11, 2014 10:04 PM
  • Clear your cache. I was trying both. And I should mention, Firefox works fine with either method. IE11 fails with both.
    • Edited by timeshifter Tuesday, February 11, 2014 10:33 PM
    Tuesday, February 11, 2014 10:30 PM

  • You're angry at innerHTML for doing what you instructed?

    You used it to nuke that <select>.

    Did you expect any content to remain after that?


    He did... He still does, because firefox is not able to destroy elements using: this.innerHTML="";

    Which once again comes as a result of the fact that firefox doesn't have native support for DHTML methods such as innerHTML, and it doesn't because firefox is a rebranded NN.

    Tuesday, February 11, 2014 11:33 PM
  • Alright, fine, I'll accept that setting innerHTML may be my only solution. But... *why*? Look at my sample page; currently, it constructs entirely new elements to store into the cascades array before nuking the <select>, which only happens on change. There is nothing referential being stored, so why is IE doing the exact same thing?
    Wednesday, February 12, 2014 3:01 PM
  • Verified: https://dl.dropboxusercontent.com/u/7820717/html/demo5.html

    A bit of object abuse and innerHTML and it works as expected. Of course, I'd still like to know why IE behaves the way it does...

    Wednesday, February 12, 2014 3:53 PM
  • var child= document.getElementById($(this).attr('data-child'));

    The onus is on me as the developer to ensure that it's always a unique pointer. In my demo, it's very easy to verify that it is.

    Again, IE is the only browser that exhibits this behavior. Firefox and Chrome handle it as expected.

    Wednesday, February 12, 2014 4:34 PM
  • var child= document.getElementById($(this).attr('data-child'));

    The onus is on me as the developer to ensure that it's always a unique pointer. In my demo, it's very easy to verify that it is.

    Again, IE is the only browser that exhibits this behavior. Firefox and Chrome handle it as expected.

    1. You are relying on gecko bug of half-baked superficial imitation of a true native innerHTML method.
    2. You are treating this erroneous implementation as if it was some sort of a legitimate behavior!   

    The innerHTML method, amongst other (no-DOM) specific DHTML characteristics, is also a low level destructive method. 

    An expression such as: this.innerHTML=""; is not a joke. It will destroy all its corresponding child elements for real!

    Any future reference to them will be void.

    Here is what a true support for DHTML methods should be able to do:

    Page Links Destroy

           a = document.links;

           while( a[0] ){ a[0].outerHTML = a[0].innerHTML };

           delete a; //if necessary.

    After this JavaScript short Spartan expression has executed, no link tags should exist on the target page anymore. (Yet, leaving their inner content intact). But if a browser doesn't have a true native DHTML support - the result of this powerful expression will be somewhat less than satisfactory.

    Here, -test it on Google search Result, [copy-paste it in your browser Console, and hit execute] you'll begin to understand what DHTML methods really are. And hopefully never get them mixed up with DOM methods again.

    have fun.




    Wednesday, February 12, 2014 6:37 PM
  • >An expression such as: this.innerHTML=""; is not a joke. It will destroy all its corresponding child elements for real!


    Yes, but my demo4 page shows the cache array being created entirely from scratch, no references to the child select at all, and IE still destroys the innerHTML of every element in that cache array. Again, entirely objects created dynamically, not a single reference to a DOM element. That demo shows that IE is modifying an entirely detached array without being told to. That is what I want an explanation for.

    Wednesday, February 12, 2014 7:23 PM
  • no no no...

    it doesn't matter if you've put some child element object references on an array,
    once you've done >> its_parent_element. innereHTML = ""; your array members will contain void elements. That is: nothing!

    Because you are not putting copies or duplicates of them in an array but, the concrete object references of true elements of interest. So, once they are annihilated, - they are no more.
    Your array will be full of nothingness from that point forward.

    Wednesday, February 12, 2014 7:45 PM
  • So you're saying that the
    n.innerHTML = c.options[i].innerHTML;

    is a referential assignment? If so, that makes sense then. Rather, it explains the issue.. it doesn't make sense from a usability standpoint.
    Wednesday, February 12, 2014 9:00 PM
  • So you're saying that the
    n.innerHTML = c.options[i].innerHTML;

    is a referential assignment? If so, that makes sense then. Rather, it explains the issue.. it doesn't make sense from a usability standpoint.

    which side of the assgnment?

    if options[i] were destroyed by purging their parent from its child elements by using the webs most powerful method, innerHTML, than yes. -Your c.[empty][i].innerHTML, is void, because c got robbed as a consequence of the fact that someone emptied his 'bank' (and that that's where his actual 'money' is).  

    Wednesday, February 12, 2014 9:33 PM
  • So you're saying that the

    n.innerHTML = c.options[i].innerHTML;

    is a referential assignment? If so, that makes sense then. Rather, it explains the issue.. it doesn't make sense from a usability standpoint.


    No, that was fine.  I tested it.  I mentioned it earler.


    It is easy to check.  After the page is fully loaded, just write "HELLO" into (the innerHTML of) one of the <option>s visible in the lower <select>.  Then view the corresponding cascades array object.  It is unaffected.  That's proof.


    The cascades array's objects seemed ok until the onchange handler is invoked.  Then, as seen in this online alert demo (two alerts sandwiching that child.innerHTML=''), somehow cascades objects were being affected by it.  As I said in my last post above, that indicates the "child" in child.innerHTML is pointing into cascades, or else jquery is somehow intervening.


    I don't have jquery skills, and the F12 debugger crashes in the onchange handler.  But it'd be straightforward to continue patching tests into that "alert sandwich" location to determine the culprit.  Maybe one of you two, timeshifter or aeneas will be motivated to actually conduct some tests.


    aeneas just likes to talk authoritatively without testing or verifying anything he says.

    Eg, here and here to name just a few examples.


    Mr record number of accounts multiple personality disorder and the only banned but also most banned trolling agent.

    what is your latest account nick name mister agamemnus, why don't you simply propose your answers for answer as usually and get on with it.

    Thursday, February 13, 2014 1:19 AM

  • Here, I patched in data[i].cloneNode and it appears to fix the bug.

    online demo


    What bug , Mr. Sigmund Freud?

    What bug?

    Thursday, February 13, 2014 10:28 PM
  • Verified: https://dl.dropboxusercontent.com/u/7820717/html/demo5.html

    A bit of object abuse and innerHTML and it works as expected. Of course, I'd still like to know why IE behaves the way it does...

    Your demo5 code only works on IE 10 and 11...

    I thought that jQuery's excuse of existence or for being that ugly and slow, was to simplify things; especially to smoothen up some browser incompatibilities if not all; or to at least shorten up your scripts. But all I can see here, there, everywhere, is that the ugly kid of historical browser incompatibilities is simply growing uglier and uglier as the days pass by.

    Here is an example of pure JavaScript solution that not only works on IE11 and 10 but also on IE9,8,7,6 and as it seems 5; At least 3 to 4 times shorter; no additional 100KB download; and no security warning; and most probably 5 times faster.

    	var arr = [], ddl = ddlChild, v, i=0;
    	while( ddl[i] )arr.push( ddl[i++]);
    	ddlParent.onchange = function() 
         {  v = this.value;
    	while( ddl[0] )ddl.removeChild( ddl[0] ); ddl.appendChild( arr[0] );
    	for( i in arr )( v==="" ) ? ddl.appendChild( arr[i] ):
    	( arr[i].getAttribute('data-fk') == v ) ? ddl.appendChild( arr[i] ) : 0;
    	ddl[0].selected = !0;
         }
    and here is the showcase.

    Have fun.

    • Proposed as answer by aeneas dardanus Saturday, February 15, 2014 12:45 AM
    Friday, February 14, 2014 10:02 PM
  • First of, why would you be wasting the cloneNode method unless you are creating a new and separate drop-down options list which contains some already existing html code saving yourself and your client from few more bytes hardcoding elements, -bad practice.

    Secondly, your code is not suitable for production because it doesn't support IE 7 which is still quite popular. 

    On top of that, your client would still be facing the security warning, and content filtering and will be forced to click on "show all content" in order to actually be able to use the option filtering.  

    But on top of the tops, your code is also damaging the structure, since your filtered dropdown is loosing its cap "select an option" too. Even worst if  you bring it back your filter will fail miserably.

    With all these bugs and errors, I think that you too will agree that your code is unusable. 

    Friday, February 14, 2014 10:42 PM
  • I wish you knew what you were talking about, aeneas.

    It would make conversation with you so... possible.

    I'm not here to chat with you or anybody, nor to feed the trolls for that matter. I'm here to offer  powerful solutions such as this:


    var arr = [], ddl = ddlChild, v, i=0; while( ddl[i] )arr.push( ddl[i++]); ddlParent.onchange = function() { v = this.value; while( ddl[0] )ddl.removeChild( ddl[0] ); ddl.appendChild( arr[0] ); for( i in arr )( v==="" ) ? ddl.appendChild( arr[i] ): ( arr[i].getAttribute('data-fk') == v ) ? ddl.appendChild( arr[i] ) : 0; ddl[0].selected = !0; }


    the power of experience
     



    • Edited by aeneas dardanus Friday, February 14, 2014 11:59 PM illustration
    • Proposed as answer by aeneas dardanus Saturday, February 15, 2014 12:46 AM
    Friday, February 14, 2014 11:50 PM
  • Stop trolling, start learning!
    Saturday, February 15, 2014 12:05 AM
  • Start here:

    I'm not here to chat with you or anybody, nor to feed the trolls for that matter. I'm here to offer  powerful solutions such as this:


    var arr = [], ddl = ddlChild, v, i=0; while( ddl[i] )arr.push( ddl[i++]); ddlParent.onchange = function() { v = this.value; while( ddl[0] )ddl.removeChild( ddl[0] ); ddl.appendChild( arr[0] ); for( i in arr )( v==="" ) ? ddl.appendChild( arr[i] ): ( arr[i].getAttribute('data-fk') == v ) ? ddl.appendChild( arr[i] ) : 0; ddl[0].selected = !0; }


    the power of experience
     




    • Proposed as answer by aeneas dardanus Saturday, February 15, 2014 12:47 AM
    Saturday, February 15, 2014 12:07 AM
  • Misinforming Trolling gibberish, as usual!

    My universal fully independent concise browser-unaware fully HTML5 standard-compliant efficient working code solution  is using appendChild. And it's working on IE5 through IE11 forward guaranteed. Liar.

    Start by learning the fact that:

    I including the timeshifter and all other coders who's threads you've hijacked until now are  not here to chat with you -especially , nor to feed your trolling appetite. We are here for powerful solutions such as this:


    var arr = [], ddl = ddlChild, v, i=0; while( ddl[i] )arr.push( ddl[i++]); ddlParent.onchange = function() { v = this.value; while( ddl[0] )ddl.removeChild( ddl[0] ); ddl.appendChild( arr[0] ); for( i in arr )( v==="" ) ? ddl.appendChild( arr[i] ): ( arr[i].getAttribute('data-fk') == v ) ? ddl.appendChild( arr[i] ) : 0; ddl[0].selected = !0; }


    the power of experience
     
    • Proposed as answer by aeneas dardanus Saturday, February 15, 2014 12:47 AM
    Saturday, February 15, 2014 12:42 AM
  • Somebody needs to do the right thing and ban this Troll by blocking his IP, because he already has over 20 usernames, which is a great violation on its own.

    Regards.

    Saturday, February 15, 2014 12:55 AM
  • var arr = [], ddl = ddlChild, v, i=0;
    while( ddl[i] )arr.push( ddl[i++]);
    ddlParent
    .onchange = function()
        
    {  v = this.value;
    while( ddl[0] )ddl.removeChild( ddl[0] ); ddl.appendChild( arr[0] );
    for( i in arr )( v==="" ) ? ddl.appendChild( arr[i] ):
    ( arr[i].getAttribute('data-fk') == v ) ? ddl.appendChild( arr[i] ) : 0;
    ddl
    [0].selected = !0;
        
    }

    universal browser solution working case using appendChild as the core programming functionality including IE5.

    Here:


    Saturday, February 15, 2014 1:08 AM
  • var arr = [], ddl = ddlChild, v, i=0;
    while( ddl[i] )arr.push( ddl[i++]);
    ddlParent
    .onchange = function()
        
    {  v = this.value;
    while( ddl[0] )ddl.removeChild( ddl[0] ); ddl.appendChild( arr[0] );
    for( i in arr )( v==="" ) ? ddl.appendChild( arr[i] ):
    ( arr[i].getAttribute('data-fk') == v ) ? ddl.appendChild( arr[i] ) : 0;
    ddl
    [0].selected = !0;
        
    }

    universal browser solution working case using appendChild as the core programming functionality including IE5.

    Here:

    Saturday, February 15, 2014 1:30 AM

  • Here is a thread which takes several minutes to load with IE8-IE11.

    But only takes about 10 seconds with Firefox or Chrome.

    (this symptom will stop if you view it not signed-in, or if they lock that extra-long thread).


    The problem IE has with it can be seen via F12 tools to be in appendChild.

    Again, thanks for providing additional insight, timeshifter.




    How do you explain it, aeneas?  Deny that loooong IE delay.  You can't.

    How do you explain the IE8 innerHTML bug shown above?

    By having a tantrum and evading it?    : P



    var arr = [], ddl = ddlChild, v, i=0;
    while( ddl[i] )arr.push( ddl[i++]);
    ddlParent
    .onchange = function()
        
    {  v = this.value;
    while( ddl[0] )ddl.removeChild( ddl[0] ); ddl.appendChild( arr[0] );
    for( i in arr )( v==="" ) ? ddl.appendChild( arr[i] ):
    ( arr[i].getAttribute('data-fk') == v ) ? ddl.appendChild( arr[i] ) : 0;
    ddl
    [0].selected = !0;
        
    }

    universal browser solution working case using appendChild as the core programming functionality including IE5.

    Here:

    Unable to read? - go back to elementary school, troll.

    this production ready efficient and most powerful code you've ever seen alive, is using exactly the appendChild method three time in a row! But you're still trolling on the same subject. What you need is a therapist.

    And Stop hijacking other peoples threads.

    Saturday, February 15, 2014 1:58 AM
  • @Moderators

    It is becoming impossible to come by a single bit of some useful information because of this mans excessive trolling activity flooding threads with meaningless and lengthy off-topic replies throwing useless pictures burying good answers deep within his spamming posts hijacking other peoples threads deviating every relevant subject and undermining every useful post a starter may come by so that he can miss the needed information.

    Please ban this trolling nuisance and block his IP address because he already has more than 20 active accounts in his current use.

    Regards

    Saturday, February 15, 2014 3:35 AM