Nope, that wasn't a good thing to do.

I have managed to blast away, ohh, about (mumble, mumble) files, while trying to undo other mayhem I caused while paying with some new macros.

I'll get my blog house back in proper order, when I'm on a fast pipe, and my upstreaming won't be so bumpy. Like, tomorrow.

Ya know, I shoulda increased the amount of time Radio takes before looking for changed files -- might have saved some pain....

And happy 100th post, me. Rats.
10:54:34 PM  [] blah blah blah'd on this    

---

The great HTML tables debate rage on, and DaveW has asked for reasons why Tables can be less good...

Here's my $US0.02 on this one, to add to the other voices. One reason I dislike the use of tables for layout of non-tabular data is that they make moving the data between applications more difficult.

My take on the background of this...

The main reason is the original spec for HTML tables was flawed. HTML came from SGML, where the number of columns and rows must be specified for validity and well-formedness. HTML doesn't have this degree of specificity, though.

And we're stuck with it for now.

Ramifications of this decision, as I've seen 'em...

This is one reason behind why rendering a page plastered with multiple-nested tables can take so long, and why a missing </table> tag can leave you with a blank page displayed in some browsers.

This is also a reason why trying to import HTML pages that use tables for design layout into another application or to translate it to another file format can be difficult.

HTML made with tables for design layout is a mostly-closed trunk right now.

Unfortunately it is also a still-needed evil in many cases, since most browsers still do not have full support for CSS positioning (styling yes, but positioning is often horribly broken). And that's a chicken or the egg prospect. Browser makers won't fully support CSS-P until they have to, and until it's more supported, many pages won't exist using CSS-P.
4:44:10 PM  [] blah blah blah'd on this    

---