There were two other features buit in to Firefox that I miss and haven’t seen them in IE (yeah, I know… download Firefox already): “View source selection…” and spell-check. The former was great to isolate areas on a page and see what code got it there. I recall it had a couple hiccups with it’s interaction with Firebug but nothing that was really all that bad. The latter was sweet for forms like this. Here, to spell check, I would have to copy the text and paste it into a tool that had a checker.

Aaaannnyway, the reason I mention all that is to bring it back to what you were saying about the document. If I wanted to retrieve an order and its order_lines from the database and display it in a document, I couldn’t just map the database ids to element ids. Why? Because they would not necessarily be unique. If the order has an id of 1, and the first order_line also has an id of 1, you’d end up with two elements fighting over the same id like vampire bats over a used tampon. I mean, that ain’t cool. So it is that you’d have to add in something to make each id unique, typically the table name. That way, you would end up with ids of “order1″ and “order_line1″.

As you have stated, the id is meant be used by the document as a whole in order to index the elements it contains, and not as a descriptor of the elements themselves. So yeah, right on!

For example, if I was modeling an order for a store, there might be an id, orderId, that makes the order to be unique from all other orders. If we were talking databases, I think this would be akin to the primary key (but I’m not really a database guy).

On the other hand, the id attribute has a different interpretataion and has a semi-reserved status a la the DOM. That is, I can locate an element using getElementById(). In order to locate the element by its unique order id, I would have to parse the tree and look for the element that has that particular order id.

So, the id’s context is really the document, not the data.

As for the use of getElementByUd(), why would you use it if you already have the element? That doesn’t make any sense – you would simply call element.id. As the Mudcraft people say, “me confused!”

The problem with the editors I’ve been using is that they are pretty much useless for style sheets. First, adjustments made in the design view are captured in style attributes of the appropriate element rather than in the style sheet. I see why this would be the case: the assumption probably is that you are overriding the style sheet. But there are times when what you really want is a change to the CSS. Second, the changes are explicit and rigid: heights and widths are explicitly captured and in pixels rather than percentages. They need to be more flexible.

I’ll have to look into GoLive. I’m wondering if there isn’t something little more simple. Perhaps there is an eclipse plug-in. That would be nice – esp. if a few plug-ins glued together to support AJAX.

It might just be that you need a better text editor. I use the venerable TextPad on Windows and TextMate on Macs, and both are capable of sending whatever script you’re working on to the appropriate browser. I prefer viewing my documents in a ‘real’ browser versus the design view of an editor, because I know there can be discrepancies. Scroodat!