Continuing work on my next theme, Thematic, one thing I want to get out of the way immediately is the structure, or skeleton, of the thing. The outer structure of any HTML+CSS document is where things usually go bonkers and the last thing I want is for my markup to make things worse when I update versions. So, that said, here’s the basic divisions of markup, which I’ll follow with some of my thinking. I’m hoping we can start a conversation over this—and I’m totally up for a raging debate over my non-transcendent approach to this—so give this post a quick scan and see if you can add your two cents. The more the merrier.
The Thematic Markup Divisions
Why Use This Structure?
Why divide the code up this way? How is this any better than The Sandbox or any other theme for that matter? What are you trying to do here exactly?
Well, one of my main goals is to enable all sorts of CSS madness without changing the markup. While at the same keeping the markup divisions logical, letting the <div> serve it’s intended purpose. That is, making sure the <div> is there only to make my code more readable and imparting some meaning to it with class structure. With two important and glaring exceptions of course, wrapper and container.
A wrapper class is sort of a convention now—even though it’s not necessary—and anyway, it provides a useful point for playing with absolute and relative positioning. The container class lets us up keep our content source-ordered and have a sidebar on the left side of the screen using CSS only (check out the Sandbox layouts for examples of this). The use of these classes are straight out of The Sandbox and general web design convention. I think we can probably all agree on keeping these here.
But what about the CSS madness? More carefully thought out divisions = more madness. Subdividing the header and footer contents and collecting the center bits in a <div> let’s us create a bulletproof fixed-fluid hybrid layout, something like SimpleBits, or even something weird like MNML, and who knows what else. Personally, I like the who knows what else. Anyway, combined with the semantic class functions of The Sandbox there aren’t a lot of themes that can compete when it comes to employing the possibilities of CSS.
So what do you think? I’d appreciate the thoughts of anyone considering using Thematic. It’ll be your markup too, eventually.
For more thinking about the whole topic of naming and structure check out What’s in a name (pt2) and Structural Naming. These two posts are 4 years old but still worth reading.
ThemeShaper 
center is a pretty bad ID name, content or body would be better. (center implies formating)
One of the things that I didn’t realize Sandbox did for the longest time was support the hAtom microformat. http://microformats.org/wiki/hatom
The games begin. 🙂
Center could imply formatting. But then so does header and footer. Body is confusing and I like content where it is, wrapping content. It just seemed logical to me, extending the metaphor of the physical body to the divisions of the markup (Head, feet, center of gravity). In my mind it describes the code: it’s between the head and the foot, it’s the center.
Thorax briefly flashed through my mind and was quickly dismissed. Thankfully.
Microformats: I’m expecting Sandbox (and Sandbox-based themes) to become a lot more popular very soon. I think this might be the year of microformats. What with Firefox 3 apparently making it easier to do “stuff” with them and Yahoo apparently incorporating them into searches.
Apparently, I say, because I haven’t really seen any of this yet.
My first thought was also, “Center? What was he thinking? That’s a presentational term!”
I’d put a vote in for “body” or “main.” (Thanks for resisting “thorax.”)
And if you are really going to push for structural naming, why not avoid “sidebars” entirely? I hear the term “widgetarea” is hip with the cool kids…
I like the ordinal ID’s, though. They’re, um…classy. 😉
Really? Well, I could live with main, I guess. Sigh. Grumble. Moan. Do my intentions count? I don’t mean for it to be presentational? Really, I don’t. Honest. It comes from using Firebug and wanting to keep everything neat.
Darn, you caught me proposing code, CircleReader! Yeah, sidebar is kinda annoying. I was talking more about the template tag though. Now that’s presentational. With 2.5 you can do stuff like
<?php get_sidebar('primary'); ?>, and include a file called sidebar-primary.php. Very cool. But weird if you’re not making a sidebar, like say something in the footer. What’s that, a footer bar? What if the main bulk of your content is going to be held in a widgetized area? Totally possible. Anyway, the tag calls it a sidebar, the admin area calls it a sidebar but I don’t like that it’s a sidebar.Which brings me back to my classes, you’re right, maybe I shouldn’t call it a sidebar. Widgetarea, widgetregion, widgetzone, widgetthorax… it’s tough.
… any other suggestions for “widgetarea” and “center/main”?
I can’t be the only one liking center, can I?
Maybe just class=”widgets”?
“Main” makes more sense to me. Also, I think “widgets” is the way to go.
Why “access”?
Access is straight out of The Sandbox. Thematically, it grants access to all the pages of your blog. Practically, it holds the “skip to content” link (for people using screen readers) and the main navigation.
Maybe “central” ???
Since the widgetized area might not necessarily contain widgets and sidebar is way too suggestive—since a
sidebardoesn’t have to be a sidebar—I’m proposing the class of support to replace the sidebar class. Extra material, related links, advertisements; all these things support the content.If “center” is too presentational, should we move away from “header” and “footer”? Or is that moving too far from WordPress convention? Or is the convention corrupt in this case? Suprameta and Inframeta are probably too silly.
I think it’s mixing languages too. I may have to live with main.
Perhaps you could satisfy “center”-naysayers and future-proof against name-space violations by rephrasing all your element names in pig Latin?
Ustjae Iddingkay.
Steve wins.