Category Archives: Web Standards

Semantic markup and CSS frameworks

Posted on by

The very talented Jeff Croft posts on CSS frameworks and the supposed myth of content and presentation separation, coming to the conclusion that it’s all a pipedream. I both agree and disagree.

Jeff says that *never having to touch the markup*, and only having to adjust the CSS for a redesign, is a myth. With this, I agree. If I’ve said it once, I’ve said it a million times: *design* is not *decoration*. So while I agree that most redesigns will involve changing markup, I disagree with the underlying premise that a redesign is a purely visual undertaking, and I disagree with the whole idea that one *should never have to touch* the markup. Which law is that? I would encourage anyone thinking that content/presentation separation or semantic markup (two completely different things) means that you’ll only need to change the CSS, to challenge this thought. They’re missing the point. This type of thinking reduces design to simply mean decoration. I didn’t study decoration for four years. My clients’ websites aren’t MySpace. We’re not *skinning* here. Since markup is *structural*, changing the structure of a design will certainly demand markup changes, and there’s nothing wrong with that.

Which brings me to CSS frameworks. Hmmm. Building a site so that you “only” need to change the CSS. This is pretty neat from a geek standpoint: can it be done? Is my framework better than your framework? But in reality, these CSS frameworks dictate to a certain extent how you’ll set up your structure. But shouldn’t the content dictate that?

Structure and meaning

*The separation of structure/content and presentation is meant to manifest itself to the end user, not to the developer.* When a site is stripped of all visual elements, the structured content of the site should still be accessible to the end user. There are two kinds of structure: document structure and visual structure. Document structure is the structure of the content itself. Visual structure is the physical structure of a page. We can distinguish these elements from each other through the use of semantic markup.

Semantic markup is all about meaning. When I say something is an “attention block”, I know what that means. Most importantly, fellow or future developers can figure out what an attention block is fairly quickly, even *sans* documentation. I can distinguish an attention block from an “urgent block” semantically, as opposed to only visually. But with all due respect to Jeff and others, what the hell is a *span-4* or a *pull-2*? And how does this help future developers? Colleagues when I move to another company? Or portability, when the client wants a DocBook PDF of the entire site?

The new WYSIWYG

CSS frameworks are a nice idea, but they introduce the same problems the JavaScript frameworks or app/CMS frameworks introduce: they try to make things easier for the current developer, and in doing so make it terribly easy for less-experienced developers to create terribly scary, unruly HTML and CSS, while they don’t yet fully understand the basics. Sound familiar? Isn’t this the exact reason we hate WYSIWYG editors? Could CSS frameworks perhaps be the geek equivalent of WYSIWYG? With most frameworks, you must first get to know the framework if you want to work with it effectively. But we *already* know HTML and CSS. So what happens when client X asks me to do a redesign of site X, which uses CSS framework X? I either have to learn how framework X works and rework the site *that* way (focusing on implementing new elements using the framework, which will translate into costs for the client), or I’ll have to rebuild the whole thing. Rebuilding the whole thing is very tempting, because restrictions will be removed, and I can approach the site based on content, structure and visual design using the very basic tools of semantic HTML and CSS. The site will be portable and maintainable: anyone knowledgeable in HTML and CSS can maintain it; semantic markup is understandable markup. The site will be fairly future-proof, independent of framework version changes.

I’m not saying that frameworks are bad, but I challenge the *reasons* often given for using them. I consider them mainly beneficial to the initial developers. I also challenge any excuses designed to defend the discarding of semantic markup. I just don’t buy that *span-4* and *pull-2* are necessary. You have to use class names anyway, why not make them meaningful?

Use CSS frameworks if you will, but really consider your reasons for using them. Weigh the pros and cons. Not only for yourself, but for the site, the end users and your client, which also means future developers. Think about portability. Think about the fact that visual design is not simply decoration. Consider that visual design and document structure, although separated for portability/durability and the accessibility to the end user, are in fact inseparable.

As designer Paul Rand once said, “Design is a method of putting form and content together”. Our methods should involve embracing and strengthening this relationship, instead of working against it.

Big companies and web standards

Posted on by

JavaScript guru Peter-Paul Koch writes about the need to reach out to front-end developers at large companies. The ones using web standards should be encouraged to evangelize. Why? To in turn encourage non-standards-based (is that a word?) developers at other large companies who might not otherwise be convinced by the predominantly freelance and small-business based world of standards evangelists. Not that there’s anything wrong with those, mind you.

One of the article’s comments brings up an interesting point. While I don’t own a large company, we do serve some *very* large clients. And one thing I’ve learned from them is something anyone who sells anything could probably tell you: if you want to sell something, whether it be a product, a service, or an idea, you’re best chance is to first speak the language of the person to whom you’re selling. Once you’ve done that, you need to show the buyer what’s in it for them. At big companies, it’ll usually come down to the subject of money.

Peter-Paul makes an interesting point. Developers at big companies speak the language of other big-company developers. They have different work environments, often high-stress and high-profile projects, and they often work on one aspect of a project (e.g. only HTML/CSS/JavaScript). While this could be a great first step, we need to remember that getting large companies to embrace web standards will not only involve convincing the developers, but also the management of these companies. What’s in it for them? How’s this stuff gonna make them money? Got your pitch ready? Sell it.