|
Prev: still hoping for a little help!
Next: Appending Events
From: Holger Jeromin on 5 May 2008 10:12 sheldonlg schrieb am 05.05.2008 15:39: > Ugo wrote: >>>>> What can I do about it? >>>> Mmmm, do you wait for onloading the page? >>> The page is already loaded. This occurs when clicking a button on the >>> page that brings up the div (making it visible, that is). This line is >>> part of that javascript that presents the box. >> You add the text when the table is hidden? and then you make it visible? >> If it is so, IE could get angry... > I create the entire block and have visibility:hidden. In that creation, > the innerHTML is "". When I activate the script, a number of things try " " > happen. As currently coded, the last list is to set the > visibility:visible. Right before that I have the two lines (find the > element by ID and set its innerHTML). > > I will try reversing that order, setting it visible and then changing > the innerHTML, and see what happens. -- Mit freundlichen Gr��en Holger Jeromin
From: sheldonlg on 5 May 2008 10:25 sheldonlg wrote: > Ugo wrote: >>>>> What can I do about it? >>>> Mmmm, do you wait for onloading the page? >>> The page is already loaded. This occurs when clicking a button on >>> the page that brings up the div (making it visible, that is). This >>> line is part of that javascript that presents the box. >> >> You add the text when the table is hidden? and then you make it visible? >> If it is so, IE could get angry... > > I create the entire block and have visibility:hidden. In that creation, > the innerHTML is "". When I activate the script, a number of things > happen. As currently coded, the last list is to set the > visibility:visible. Right before that I have the two lines (find the > element by ID and set its innerHTML). > > I will try reversing that order, setting it visible and then changing > the innerHTML, and see what happens. Thank you for your suggestion. When I made that change, all hell broke loose in the rendering of the table. Investigating, I found that my error had nothing to do with this problem. There was an <input type="hidden"> in the table. I had failed to close that with the " />". Apparently, Firefox was smart to enough to say "Dummy, you forgot to close this so I will do it for you", and rendered the table as I wanted it. When I fixed the error, IE also displayed properly and without a JS error. Thanks again.
From: Thomas 'PointedEars' Lahn on 6 May 2008 15:36 nobody(a)nowhere.net wrote: > Ever tried to use MS VS.NET for debugging JS? Try it, and you'll > never want to use anything else. I have tried it, and I prefer the MS Script Debugger for JScript, for its not being evaluation software that cannot be registered, and its comparably small memory footprint. Never wanting to use anything else would be nonsense anyway because MS VS.NET can only debug JScript, not JavaScript or other ECMAScript implementations. > [...] > And to see dynamically built object html, try entering into IE address > bar javascript:alert(document.getElementById('some id').innerHTML); > Works with FF, too. I prefer Firebug for debugging scripts in Firefox; you definitely should try that. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Dr J R Stockton on 5 May 2008 13:48 In comp.lang.javascript message <-5KdnXsg_YpthYLVnZ2dnUVZ_hudnZ2d(a)gigane ws.com>, Mon, 5 May 2008 10:25:28, sheldonlg <sheldonlg@?.?.invalid> posted: > >Thank you for your suggestion. When I made that change, all hell broke >loose in the rendering of the table. Investigating, I found that my >error had nothing to do with this problem. There was an <input >type="hidden"> in the table. I had failed to close that with the " >/>". Apparently, Firefox was smart to enough to say "Dummy, you forgot >to close this so I will do it for you", and rendered the table as I >wanted it. When I fixed the error, IE also displayed properly and >without a JS error. Restore the error, then see what W3's downloadable TIDY (used as a checker) and also an on-line tester say about it. I predict that you will then form the habit of using them. <FAQENTRY> Section 2.3. Add something on the desirability of verifying HTML before worrying about what the script seems to do; particularly before posting. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
From: sheldonlg on 5 May 2008 21:12
Dr J R Stockton wrote: > In comp.lang.javascript message <-5KdnXsg_YpthYLVnZ2dnUVZ_hudnZ2d(a)gigane > ws.com>, Mon, 5 May 2008 10:25:28, sheldonlg <sheldonlg@?.?.invalid> > posted: >> Thank you for your suggestion. When I made that change, all hell broke >> loose in the rendering of the table. Investigating, I found that my >> error had nothing to do with this problem. There was an <input >> type="hidden"> in the table. I had failed to close that with the " >> />". Apparently, Firefox was smart to enough to say "Dummy, you forgot >> to close this so I will do it for you", and rendered the table as I >> wanted it. When I fixed the error, IE also displayed properly and >> without a JS error. > > Restore the error, then see what W3's downloadable TIDY (used as a > checker) and also an on-line tester say about it. I predict that you > will then form the habit of using them. > > <FAQENTRY> Section 2.3. > Add something on the desirability of verifying HTML before worrying > about what the script seems to do; particularly before posting. > I wish I could do that. However, if I do a "view source", all I see is the template. This is on an AJAX foundation using php to write the html. From what I have researched on the web, the validator can't be used with php, let alone html that is written at run time via AJAX. If I am wrong, them please enlighten me. I would love to check for errors by validations. As it is, I found this by taking my code and cutting and pasting into a dreamweaver window and then manually indenting and examining it line by line. (I just indented the print statements as I would have done for the tage). |