Halogen Labs Weblog

Todd Huss wrote about avoiding using image tags in HTML. He brings up two points about why this might be bad.

His first argument is:

It violates the separation of content and design by including a design element in your HTML

By this argument, we’re not supposed to use img tags because it violates separation of content and design? While this is basically true, it also seems a little shortsighted. Todd’s technique is actually quite well-suited for the template portion of a page, but breaks down once you’re working with pure content. Sure, HTML isn’t perfect, but what happens if your document legitimately contains an inline image?

Let’s take a simple example, a templated website. There’s a subtle yet fundamental difference between the HTML you wrap around your content, and the HTML that your content ends up as. Let’s also assume that you’re being a good developer and using a two-step view pattern for your web publishing. You have your content in some XML format, and you transform it to HTML and merge it with the page template, and then push the rest to the browser.

By making a distinction between the actual content of your page, and the template shell, you’re able to maintain an even better separation of concerns. So now, what happens when you want to legitimately want to include an image (or something else) inline in your content? The format you’re storing your content in should be able to handle it. Transform your content to HTML (or don’t, if you’re using something good like XTHML), and then merge it with the page template. Now you can completely maintain the site template separately from the page content.

Personally, I tend to use Todd’s technique when working on the site template, and then use inline image tags in the actual content. Using img tags inside your content keeps it descriptive — moreso than something like <div class=”fishImage”/>.

As far as argument #2:

Your SEO will suffer because image alt tags don’t carry as much weight as real text

I’m not a huge SEO expert, so I tend to agree with this one. Obviously you can’t put an exact number on it, but it seems logical that your SEO might take a minor hit by using an image tag for nagivation compared to an anchor tag. Your markup should be generally clean to begin with, and a clean page template (along with descriptively marked-up content) can get you most of the way there.

Well it seems that I caused some sort of a stir with yesterday’s post about Mark’s fiasco. Don’t get me wrong; I love reading Mark, and my comments weren’t meant in a mean fashion.

What I was trying to get at, was that it seems to me that Mark needs a little bit more leeway with his online publishing. He seemed happy using XHTML 1.1, and then he toyed with the idea of having to migrate to XHTML 2.0, and was not happy.

Yesterday, I proposed mark use a “presentation layer”. This is just a fancy way of saying that he needs a better separation of his content and his layout. Sure, he uses XHTML + CSS + MT with a database backend, but apparently that’s not enough.

Mark needs the ability to store his data however he wants, and then spit out HTML, XML, or whatever his heart (or his reader’s hearts) desire. This is where Cocoon comes in, and this is where I plan on getting some work done with connecting Cocoon and MT together in a useful fashion.

One of the problems with how MT works is that it stores everything in the database, and then exports it to whatever format using the templates.

• Editing templates in a textarea sucks
• Where are the XML templates?

And most importantly,

• Why doesn’t MT’s export do so as XML?

I am working on a Python script to convert MT’s loosely-structured export output to well-formed XML. This will be useful when I want to pull all of the entries into Cocoon.

Another option is to manually edit the MT templates to output XML, and then serve them up using Cocoon.

Why Cocoon?

• I can use some sort of XML DTD that I know won’t change very much (DocBook, Apache Document v1.1).
• I can output to any number of formats, and I can very easily serve up a “lite” page for older browsers or users who so desire.
• I’m not screwed when the W3C releases another XHTML 2.0 spec.
• I know my data won’t be changing whenever the W3C changes their mind about how data should be presented as (X)HTML.

So there you have it. Think about it. It looks like MT is getting something that looks like you can use Wikiesque commands, but then when I saw the Perl code that handled it, I ran away screaming.

Stay tuned.

I’m going to keep this short and sweet. Mark and Zeldman, two people who don’t read this blog, have been complaining about the W3C and the embryonic XHTML 2.0 spec.

I’ve gone through the anger that Mark has regarding web standards, and I promptly gave up being angry at the W3C.

The W3C’s problem is that although they are one of the most important organizations on the Net, they refuse to let things “percolate.” While we’re looking at the XHTML 2.0 spec, we must realize that there are still millions of pages that are using HTML 4 Transitional because of incomplete implementations in all the browsers.

The W3C is asking us (developers) to move forward, while we’re still asking our users (and our browsers) to take valid XHTML 1.1. And in two years we’ll see an XHTML 3.0 spec, just as we’re starting to “plan for the future” by migrating our XHTML 1.1 pages to 2.0. Our users will be at least two steps behind the W3C.

It never ends.

What we as developers need from the W3C is a guarantee that the XHTML 2 spec will remain frozen for at least five seven years before they start springing new things on us.

After all, just how far can HTML go? How far does it need to go? In the end, it’s all just XML+ CSS.

Well, well well. It seems that the local alternative newspaper just bought a few passes and managed to board the Cluetrain.

Oh wow, the mail links are live. They’re using Radio.

Wow. Why People Hate Journalists.

This is big. Real big.

Steve Perry (Editor (!)), David Schminke (Managing Editor), Britt Robson (Senior Editor), Brad Zellar (Senior Writer), Melizza Maerz (Music Editor), and G.R. Anderson, Jr. (Staff Writer).

Hey, isn’t G.R Anderson one of the writers indirectly accused of using the word “Opine” too much, as pointed out by Chuck and Joel of Cosmic Slop? :)

Regardless, welcome aboard, everybody, and I’ll be watching intently. I was trying to start a revolution when I asked Pioneer Press writer Leslie Brooks Suzukamo to start a blog. He was interviewing me for an article about blogging. He agreed to start his own blog (and did), but he didn’t maintain it. It only further proved to me that the Pioneer Press wasn’t ready to get on the train.

Matthew Langham points out something called “Adobe Document Server” along with a bunch of other software (”Forms Server”, “Output Server”, “Workflow Server”) designed around PDF. He also notes that Cocoon could be a likely suspect.

Digging around Google revealed this, this page at Adobe, this whitepapr at Adobe (PDF), as well as this FAQ at Adobe (PDF).

Among the features listed:

• Eliminates need for Reader software
• Performs server-based printing and faxing
• Views Acrobat PDF files within a Web browser
• Converts PDF documents into GIF or JPEG images
• Displays images along with a toolbar

This is interesting, they seem to be un-doing the need for PDF :) the second item is mildly interesting, and the third and fourth items could be easily achieved with a PDF2HTMLSerializer or a PDF2JPEGSerializer :)