Setting the innerHTML of a TBODY element, triggers a “Unknown run-time error”
RSS <script type="text/javascript">
function emptyTable() {
document.getElementById('theTable').innerHTML=' '
}
</script>
<table>
<thead></thead>
<tfoot></tfoot>
<tbody id="theTable">
</tbody>
</table>
It’s that simple.
If you need to empty a table TBODY, use
while (tbody.childNodes.length > 0) {
tbody.removeChild(tbody.firstChild);
}
OK, here is another one.
You dinamically create a checkbox and then put its state to checked. Then, you append your new checkbox to its parent. In firefox there’s nothing wrong with that. But Internet Explorer DOES NOT check the box. Why? Well, FIRST you have to show the checkbox and THEN check it.
So:
chk = document.createElement('INPUT')
chk.type='checkbox'
chk.checked=true
document.getElementById('container').appendChild(chk)
Does not work in IE. You have to rewrite this as:
chk = document.createElement('INPUT')
chk.type='checkbox'
document.getElementById('container').appendChild(chk)
chk.checked=true
While I was spotting another strange IE mis-behaviour (but I can’t reproduce it by now), I’ve wrote some code to create HTML tables with DOM manipulation (domanipulation?) that I’d like to share.
Code is heavy commented because of some IE weirdness… CSS, HTML and JavaScript are reduced to the bare minimum.
First the CSS part:
table {
border-collapse: collapse;
border: 1px solid black;
}
/* Despite having the collapse model for the
table, IE does not support borders directly on TR.
So we use TD */
td { border-bottom: 1px solid silver; }
.odd { background-color: #D9F2AC; }
.even { background-color: #F9F2AC; }
Here comes the HTML
<body onload="test()">
<table>
<!-- We can't build dinamically a table starting
from the TABLE element as the outermost
parent, because Internet Explorer can't add TRs to it.
So, instead, we point out the TBODY -->
<tbody id="theTable">
</tbody>
</table>
</body>
Finally, Here comes the JavaScript
/* We create 15 rows with 3 columns each */
function test() {
testText=document.createTextNode('This is a text for a test')
table=document.getElementById('theTable')
for (var i=0; i < 15; i++) {
tr=document.createElement('TR')
/* IE does not support :hover on nothing else than A element. So,
we rely on hooking the onmouseout and onmouseover, setting the
row (this) background. Note that you should better add and
remove a class name, instead of directly modifying the style.
In some weird conditions IE will eat up a top border pixel, if you
don't (this is the bug I've tried to reproduce)
*/
tr.onmouseover = function() { this.style.backgroundColor="green"; }
tr.onmouseout = function() { this.style.backgroundColor=""; }
tr.className = ((i % 2) == 0 ? 'odd': 'even')
for (var c=0; c < 3; c++)
/* To reduce code to the minimum, you can create a
row, a td and its inner text with a line only! Note that you
NEED the cloneNode, because one textNode can be used
ONE time only...
*/
tr.appendChild(document.createElement('TD').appendChild(testText.cloneNode(false)).parentNode)
table.appendChild(tr)
}
}
Guess what? Another destruptive IE fallacy.
You have an input field in a form. A simple, linear text field.
You read the value of the input from a server side script… the script (yes, maybe wrongly) returns null when the string is empty (better: when there is a NULL field in the corresponding field of the database table).
So the code should be something like:
var field = getValueFromServer()
document.getElementById('theFormInputField').value = field
When the field is null, then, what you’d expect to see in the actual form field? In Firefox NOTHING. Null is null… null is nothing… NULL is not “NULL”!
In Internet Explorer what you see is a shiny… “null” string inside the field.
Now, think of a script that works with MANY of those server side set strings…
I strongly believe that while developing, your editor is like your right arm when you’re shooting: you must be very confident with it or things will shortly get fucked up.
I’ve used so many editors from DOS, through Windows, to GNU/Linux and OSX. Let me enjoy myself writing a list, more or less cronologically ordered (ascending…):
Tested, but not used much: Eclipse, gedit, NOTEPAD!
Is this list complete? Maybe. I do not mention, though, some IDEs or RADs (Visual BlahBlah, or Delphishsm).
I’m currently developing a very complex web application, that mixes in the same “page”, jsp taglibs, HTML, CSS and a lot of javascript. In GNU/Linux I’m fine with jEdit. This editor really rocks, and its syntax hilighting is superior (maybe, only a bit under vim’s one).
The “problem” is that now I need to do some work in OSX, for the same project. I do not “fell in love” with an editor, not much as I can do with other tools, so being this a not trivial editing need I asked myself: which editor could serve me better under OSX? Am I sure Jedit is the best, here?
My “special” needs are:
First in the list comes Textmate. It seems that it is a must. So I tried it.
No way. Syntax hilighting sucks. Keyboard shortcuts are not (easily?) configurable. Default keyboard mapping screwed my brain. Maybe the best editor for one-language purpose for all-day OSX users. I’m not. And Textmate is not free software (bad bad!)
OK, there’s the BBEdit thing. Bleah. I tried an old version, I admit. Quite the same problems as for Textmate, but without the highlights. And BBEdit is not free software (bad bad!)
There’s also Smultron. It’s free software! Syntax highlight is QUITE right… no markers, configurability is SO poor… I’ll give it another try when it will be more old.
So, the winner?
The winner is JEDIT. You get the same functionalities as in GNU/Linux or Windows and no one beats it.
By now.
I contenuti di questo sito sono distribuiti con una licenza Creative Commons 2.5 eccetto dove diversamente specificato.
Tema WordPress Punto5 sviluppato da Claudio Cicali; icone del set famfamfam silk e komodomedia.