I've been meaning to fix up my web site at http://homepage.mac.com/pmuellr/index.xml for a while now. Not really to fix the content, which I also need to do, but fix the structure. See, I use a little trick to get some of the common elements on each of the pages. The first hint is that the pages are xml files, not html files. But do a "view source" on one, and you'll start to see what's going on.
The real trick lies in the second line in the xml files.
<?xml-stylesheet type="text/xsl" href="local.xsl.xml"?>
I'm formatting these xml files with XSLT. It's my XSLT stylesheets that bring in the common header, footer, etc. I even used it to create 'new' tags like <url> that take the text inside an <url> / </url> pair, and render it as a link to itself.
Why do I want to change this? Seems like it works pretty good. It works quite well on Firefox Mozilla and IE. And doesn't work at all for me on Apple's Safari browser. Which is kind of embarassing since the site is hosted on Apple's .mac site.
The Safari problem, whatever it might be, is probably fixable. In fact, Safari just last year, late in the year IIRC, started claiming support for in-browser XSLT. Only, my site has never worked. Just comes up blank with no errors, warnings, nada. Some basic experiments led me to believe it was probably the sheer number of files I was pulling in to get one page loaded that probably did me in. Fixable.
But that's not the real reason to change this. XSLT, if you've never played with it, is pretty freaking inscrutable (inscrutable is one of my favorite words). Every time I decide to tweak something, I'm lost. The same way I felt after trying to tweak the first Perl program I wrote, a couple of weeks after I wrote it.
So I want to do something else, and of course I'd be nuts to not consider AJAX, since AJAX is so unbelievably kewl! Actually, I'm not building a fricken web app here, but a site, so AJAX isn't really what I want at all. But I do want a little piece of it, that being XHR (XmlHttpRequest). To be able to have the header and footer information available separately from the content, but weave it together when viewing a page.
My first thought was to go ahead and make it a web app, where I'd just have one page, and then mod the links on that page to do XHR requests to replace the body. There are a number of problems with that approach. One being that users wouldn't be able to navigate the site with forward/backward buttons. Another being that they couldn't bookmark pages. Of course, there are ways around these issues, but they're a little unnatural.
But then I realized another problem: Google does a terrible job of indexing xml pages. I had done a vanity google the other day, and just happened to think I didn't remember seeing any links to my home page. Just tried again a minute ago, and nothing really immediately came up for "pmuellr". So I helped Google a little, by asking for "pmuellr site:homepage.mac.com". And got three hits. One of them my resume in PDF. Two of the XML files got labelled "File Format: Unrecognized". Screw that. Guess I can't blame Google though. It's not real clear how I could tell Google "I swear a browser will render it as HTML". Which is kind of a lie, obviously, if your browser is Safari, or some other browser that doesn't support XSLT.
The only way to fix THAT problem is to provide the pages as HTML. So I think I'll start some experiments where I take the current pages, change 'em to HTML file extensions, and figure out the smallest bit of header info that I can use to get the header / menu / footer generated. And other stuff like the favicon, css, etc. Wonder if I should even bother trying to make it legal HTML, or if I just try using a script element at the top followed by the contents of the body underneath? Literally a one liner. I'm kind of a sucker for getting that sweet XML validation from editors though ... tough call ... tough call.
I'll post back when I know more, if I find some tasty recipe.