Front-End Architecture: Markup is the Technical Foundation
Wednesday May 3, 2006 / 11 CommentsThe first in a series discussing front-end architecture, today I want to think about markup as the technical foundation of a good front-end architecture. While user experience, usability, information architecture and the like are important, trying to build a scalable, maintainable, and extendable user experience on bad markup is like building a house on quicksand.
The Myth of Separation
We’d all love to think that everything is perfectly separated, contained, and loosely coupled. While that’s definitely an admirable goal, it’s not as realistic as we’d like. CSS and DOM Scripting are tied to our markup via classes and ID’s, and that’s to be expected.
I’m sure everyone has had to change some CSS or a script that was tied to Microsoft-like markup. Was it fun? Was it easy? Did it take you significantly longer? Of course it did, and since time is money, that means it’s more expensive. Chances are you thought at least one or two times that it would be easier to rewrite the markup from scratch, and you might have actually done that.
Mike Davidson made this painfully obvious with his entry on hacking a more tasteful myspace. The CSS he ended up having to use is atrocious. If he ever wants to go back and maintain or update that CSS, he’s in for some pain, and it’s not even his fault. Things aren’t as separate as we’d like, and bad markup will lead to bad CSS and scripting.
What Can You Do
The solution to all of this is painfully simple. Treat your markup as art. It’s a craft, mold it and tweak it until it’s just right. Slapping together some HTML will only cause you more pain down the road. Spend some time getting familiar with semantics and microformats. Even if you don’t use the microformats, you’ll have a better understanding of how to write better markup.
You’re going to have thousands of options on every page you create. You can use lists, definition lists, headings, paragraphs, etc. to markup almost anything. A brief investment in an extra five minutes can make a huge difference. Think about how the content might change in the future. Will it be shorter or longer? Will there always be a heading and an excerpt? Flexibile and scalable markup will go a long ways towards making future updates faster, easier, and less expensive.
A Brief Anecdote
At my new job, when I first handed over some of my markup to the engineers to integrate, they were dumb-founded. After years of integrating table-based markup, they were absolutely thrilled to work with something so simple and elegant.
It was exponentially easier to understand and integrate, and made their lives easier. Happier coders mean a happier team. Now, we can easily make changes and updates, and they are much more willing to make those changes as a result. It makes us more agile and responsive and saves money at the same time.
Summary
If you write bad markup, the rest of your code will inherently be bad. While I wouldn’t advise cutting corners, if you absolutely have to cut corners in your front-end code, your markup is the last place you should ever do so.
Featured Stuff - Resources: Wireframes & Page Description Diagrames
Omnigraffle and Visio versions of the wireframe templates and stencils I use on all of my projects. There’s even a few examples included for good measure. More about Wireframe & Page Description Diagram Stencils and Templates
I hear you.
Having to sift through decade-old markup at work is an ordeal but I’m always proud to see the end product will save me days of work later on. Now if I could only get them to use a CMS :D
ThameFunny, I go back a decade and my markup isn’t so much different from what it is now. ;) It was semantic then and it’s semantic now. The problem was the tables in between.
DOH!
ChadLWhen I read the title of this post I immediately thought of an article you wrote a while back. The Time is Now for Front-End Architects Reading that article finally gave me a concrete title for what I did on a daily basis.
My favorite advice I will take away from this article is
Thanks for continuing to address this topic. I am looking forward to the next article in the series.
Joey MarchyI have to agree with the heading “the myth of separation” because as nice and clean as the theory of separation may be, it gets a little sketchy when you start doing relatively complex designs. Suddenly you can’t lay out the semantic markup the way you want to without adding a few wrappers or changing the markup altogether simply because CSS doesn’t offer the level of control you’d like. Sure you can throw in some DOM scripting to compensate but you’ve just intertwined presentation and behaviour and again muddled “separation”... so as much as I’m a strong advocate for separation, I have to say that calling it a myth and/or a “theory” which is partially applicable is apt.
Ara PehlivanianJust as you have a certain vision in mind when you build XML, so too with XHTML the develpers (w3c) have something in mind when they build the language. Each piece of markup has meaning. Taking a little time to catch their vision for it will save you a lot of time in the future. :)
Gordon BranderNitpicking but: CSS can handle almost everything you need, browsers cannot…
RimantasTreat your markup as art. It’s a craft, mold it and tweak it until it’s just right
That’s perfect. I’ll certainly pass this little gem along.
I must congratulate you as well. The clarity, ‘big font factor’, and use of icons and graphics is amazingly refreshing. I must refrain from pulling down my style sheets and writing something new…
DanI can relate. Being new to CSS layouts, separation and the like, I was searching the web for a three column layout to use. The most referenced layout I found, written by a so-called CSS guru, had HTML overflowing with hacks and horrible looking code just to make it work in every browser. I thought to myself: Gee, a three column table would have required far less code. And how would they slap a new style sheet on it? You would have to rewrite all the html as well. Seemed to defeat the purpose.
JenniferRimantas – That’s another post in and of itself. Browsers can handle what they can, expecting any more is unreasonable. They’ll be more advanced someday, but until then, we all have to understand and work within the constraints created by them.
Dan – Too kind.
Jennifer – I’d say that’s the exception rather than the rule. CSS hacks are another Front-End architecture post on their own as well, and very well might be the next one. :)
GarrettThis reminds me a little of a PHP Architect article by Marcus Baker about the myth of reusable code. It’s the idea that you can’t possibly write code that will be reusable because someone will always think of a use you didn’t… I think it’s important to write the best markup for the project as it stands – your ‘markup as craft’ is spot on, but trying to predict what you might need in the future can get in the way.
Mike StenhouseCan you still work some humor into your markup? This may not be semantic…
Travis SchmeisserComments are closed for this entry.