And I’ve known for quite some time that tonnes of table code can be removed from the templates and formatting done with CSS.

I can even format the parts of the hard-coded calendar using CSS, without having to override UserLand’s code.  1:09:02 AM    

It goes deeper than just tables, Dave. It's about avoiding lock-in using open standards, which you know all about.

Try reading Scripting News with Lynx for a week, or with a PDA. Why do all of the paragraphs run together? Oh, right. They aren’t really paragraphs.

And all of the functional graphics, the tiny permalinks interspersed thoughout the text, don't have alt text. They show up as file names—the opposite of functional. Heh, “[bullet.gif] [bullet.gif] [bullet.gif].”

I know there’s an Avantgo version—but how many web sites do that? With a little bit of work the main page would load and read just fine in Lynx, in web readers for the handicapped, on cell phones and PDAs. You don’t even have to remove the tables for that. Using CSS is scalable content without a content management system. It’s client-side scalable content!

But the tables are the next stage of lock in, at a more macro level. Get rid of those and the whole thing becomes even more flexible. I can use a style sheet to put that long list of links at the bottom of the page, or to hide it.

What do you think?

[cowskull.gif]  12:51:53 AM    

The upshot on posting from a Mac browser

I traded a couple of emails about this with Jake Savin, but his attention is needed on something more pressing. I just want to make notes while this is still almost fresh in my mind. Caveat: much of these conclusions are my best guesses, from observing the results of my browser tests. If you know better, let me know.

All of the Mac browsers that I tested send posted data in iso–8859–1 encoding, a.k.a. Latin–1. Iso–8859–1 is an 8-bit encoding scheme, which includes 256 characters.

The curly quotes, n-dash, m-dash and other characters—that are very desirable from the designer’s point of view—are not within the iso–8859–1 character set.

Mozilla sends the characters using UTF–8 Unicode, a modern Internet standard. All other Mac web browsers send these using Windows CP–1252 encoding, which is similar to iso–8859–1, but adds these characters into an unused block of codes. I was surprised to find that even Mac-only browsers like OmniWeb and iCab do this.

A Manila or Radio server running on a Mac takes the incoming text and does an iso to Mac-Roman conversion, so that the text is stored internally in a native format. Unfortunately, the iso-Mac conversion bungs up the Windows characters.

The practically-minded solution would be to extend the iso–Mac converter (called string.latinToMac) so it understood this, but that stinks of embrace-and-extend. If I have time, I’ll use some string and rubber bands to test this on my own installation of Frontier and the Radio demo.

In the mean time, I’ll keep typing “’” for apostrophes.  12:31:23 AM