Dynamic Tables: IE vs Everyone Else

I just came off a full day fighting with a dynamic table addition, and I thought I'd go ahead and save someone else the pain.

I have a table, and I want to add rows via JavaScript when the user clicks a button. I created a function that did this. Since I develop against FireFox, I usually cross my fingers, load in IE for testing, and hope for the best.

Well, hope is, as they say, as hollow as fear.

the following function worked in FF, Opera, and Safari

JavaScript:
  1. function addRow() {
  2.   var tbl = document.getElementById('mytable');
  3.   var row = document.createElement("tr");
  4.   var td = document.createElement("td");
  5.   var input = document.createElement('input');
  6.  
  7.   td.appendChild(input);
  8.   row.appendChild(td);
  9.   tbl.appendChild(row);
  10. }

This created a new row in my table in FireFox and the like with a textfield in it. I've stripped out a lot of the extraneous properties and such, although I did add an onkeypress event to the field, twelve different fields, two select elements, and three text nodes.
Then I ran it in IE7, and nothing happened when I clicked the button. Or so it seemed. When I posted the form these were contained in, the new fields were there in the POST array, but nothing appeared on the screen.

After spending hours upon hours puzzling, googling, and trying different things, I found this:

http://msdn2.microsoft.com/en-us/library/ms532998.aspx

Which basically tells you what I am about to, but they do it in more detail. IE7 exposes a TOM (Table Object Model) that allows you to do what I wanted to very easily, except that the TOM doesn't work in any other browser. They also offer a standard DOM methodology, which is what my problem was. Here's the code that works in both IE and FireFox (untested in the others):

JavaScript:
  1. function addRow() {
  2.  
  3.   var tbl = document.getElementById('mytable');
  4.   var tbody = document.createElement('tbody');
  5.   var row = document.createElement('tr');
  6.   var td = document.createElement('td');
  7.   var input = document.createElement('input');
  8.  
  9.   td.appendChild(input);
  10.   row.appendChild(td);
  11.   // Thanks to Keith over at Etheric Arts for pointing out this line had a typo:
  12.   // tbody.appendChild(td); (Oddly enough, Firefox will add the row for you, IE will not)
  13.  
  14.   // It should be:
  15.   tbody.appendChild(tr);
  16.  
  17.   tbl.appendChild(tbody);
  18. }

Hat-tip: Keith Moulton (Link:Etheric Arts)
See, the problem here was that I was adding a tr, td, and cell contents, but no tbody element to contain them. IE 7 was enforcing standards on me that FireFox and the others overlook.

While it was a frustrating lesson, it was a powerful one. Hope it helps someone else in need.

~A!

Who Should I be Mad at? IE or Firefox

It's funny, because when something "doesn't work" in IE7, I'm finding more and more it is because IE7 doesn't hold a developer's hand as much as FireFox 2 does. I'm maintaining several code bases I didn't write, so I want to see exactly what's wrong.

Developers who still want to put VBScript in their web pages, unbelievable though that may be, give me one headache after another. Here's a tip:

VBScript works in exactly one browser, Microsoft Internet Explorer. And it only works there for legacy support. No one is writing for a single browser any more. If you are using VBScript on the client side, stop. JavaScript is universally understood for the most part in all of the major browsers.

Right, so the page breaks in IE, because there's bad VBScript on the client side, but it doesn't break in Firefox, because FireFox ignores it. I'm a little disappointed that FireFox doesn't pop me some kind of error in the status window, javascript console, wherever, saying something like "Un-supported script type: VBScript on line {blah}".

Now, here's the part where things get hairy for IE. When you run IE7, script debugging is disabled by default. That makes a lot of sense, because this is a consumer product, after all, and not a development tool for the main base of its users. However, once you clear the checkbox for the script debugger (clearing the checkbox turns it on, isn't that intuitive?), you get an alert when there is a script error, and it asks you if you want to debug. If you don't have Visual Studio installed, and you don't have the Microsoft Script Debugger downloaded and installed, nothing happens.

I don't mean that it goes away with no message, I mean it acts as if I had never touched the button. I sit there clicking the button for a good fifteen seconds wondering what's happening, and then I realize "D'OH! I need to install the Microsoft Script Debugger!".

I can't upload the script debugger and link to it here, because of stupid Microsoft Genuine Advantage rules, but I can give you a link over to MS to download it yourself, always assuming you pass the Genuine Check.

(Ms Script Debugger Link)

Next time, I'll talk about the new Developer Toolbar for IE7. Does it measure up to the Firefox extension?

~A!

Google and Privacy

Ooh, the industry is a-buzz with the interim report by Privacy International Placing Google 23rd out of... well... 23 in internet privacy.

PI gave them the lowest possible rating, saying they were information hoarders who were hostile to privacy.

The circus that has ensued since is lovely. Just... lovely. Google says PI is in Microsoft's pocket (one of their 70 panel members actually does work for Redmond), and PI says it's all "sour grapes" on Google's part, and they want an apology.

So the big thing people are calling me and emailing me about now, is "Should I stop using Google?" I hear it a million times a day. Are they really hostile to privacy?

Well, PI is a firm that's done this for a long, long time, and their results are usually pretty trustworthy. I'm going to give them the benefit of the doubt and say yes, Google is probably hostile to privacy.

I run all of my mail into a single GMail account, and I see adds based on the content of the email messages. Come on, are you just going to _believe_ them when they say it's safe to let them do that? Granted, it's ingenious, but it plays into the whole culture of elitist entitlement google has always had a tendency for.

One caveat I've been giving people: If you look at the report I linked to above, you're going to see that Windows Live  (eg. hotmail, passport, all that stuff), came in as a "Substantial threat" to privacy. So you take a couple steps up, maybe, by switching over to MS. AOL, same thing, they're a "Substantial threat". Yahoo?

And in the defense of Google, PI based some of their rating on the fact google wouldn't give them all the details. Hey, if I ask somebody "you're not going to sell my email address, are you?" and they just whistle and turn away, I ain't givin' em my email.

But I also counsel people not to panic. They've been using google's tools for a long time, most of them, and migrating away is a big, scary proposition.  Also, it's not like anyone else is doing any better with it, PI entitled their report "Race to the Bottom? 2007". Not a single one of the 23 companies listed in the report received a privacy-friendly rating.

And if you're going to go with the best of the bunch for privacy, you'll want the BBC, eBay, Wikipedia, and LiveJournal.

Am I switching? I'm afriad that's kind of private.

~A!

Don’t Write Bad Code

There is a popular misconception about code, and about programming in general. Programming is a science, but most people think it is ONLY a science. In point of fact, programming is an art, like music, or painting, or sketching.

Programming is most like poetry than any other expression. It is poetry rather than prose because of the rhythm, the subtle flow of ideas, the tempo of it all. While it is true anyone can learn to rhyme, it takes a mastery of more than fundamentals to be a poet. The same is true with programming. Anyone, and I do mean anyone, can learn the basic syntax of any programming language. Most are straightforward, simple, and logical. Just like phonics, the basic syntax of any language can be picked up by most anyone.

Fewer can write code for a living. Usually it takes a B.S. degree or better to work for a "good" company that will let you sit in a cubicle and churn out reams of code to make them rich. But what makes a programmer? Is it the ability to solve a problem by writing code? Is it designing the solution, rather than writing the code, that makes one a programmer?

I say no. I say there is a subtle, remarkable passion that underlies the great programmer. The great programmer exults in her discoveries and struggles constantly at the edge of something better. The great programmer sees his solution as an amorphous glimpse of something big, something grand that he can bring about with just a keyboard and a mouse, maybe a compiler.

In my experience, I've come across a great many people who write code. I've seen clients design their own sites to save a buck, and outsourced programmers churn out code too quickly in order to move on to the next project and make their dollar. I've seen it in house, too, but mostly I see it in the outsourcing realm.

Beyond that quick buck, down inside that quick and inefficient hackery that permeates this industry, there is a betrayal. It is subtle, and small, but a betrayal nonetheless. To "produce" code, as it were, is to deny the art, and to spit out chunks of code that barely get the job done in the most inelegant way possible through brute force and turning the error reporting off should be criminal.

Perhaps this article should be called "How to write bad code", because I'm about to tell you how to do it. If you want to write ugly, unmaintainable monstrosities, just pick up a book at the bookstore and go to it. Don't read anything but the syntax, and don't ever look for a cleaner way.

Don't refactor, don't think, and pepper your code with spelling errors in variable names. Make your databases huge and ungainly, without well-defined keys, and write all of your queries ad-hoc into your pages without checks and balances, and interpolate them directly into the HTML they affect. Don't learn about normalization, performance tuning, or object orientation in even the most basic context.

Most of all, if you want to write bad code, all you have to do is lack a passion for it. Daydream about leaving work as you write your code. Separate yourself from it.

There is an old saying, that the difference between something built and something created is simply this: What is created is loved before it is completed, and what is built can only be admired after it is built.

Create, don't build. If you find yourself simply building, stop and go find something you love to do.

Code is poetry.

~A!

WordPress Themes