As I’ve been revising my themes for the 2.1 version of WordPress, I’ve been working towards establishing certain “special classes” across each of my themes. Some of these I’ve seen in other themes, some of them I just made up.
There are a few I’d like for more WordPress theme developers to consider standardizing across the board.
First of all, they are classes, so they shouldn’t semantically impact the content. This is important because if, in the future, some person shockingly decides to change themes, the content of their posts isn’t affected.
Image classes
First of these class would be image positioning classes: .alignleft, .alignright, and .center. Since the positioning and/or float of images should be determined by CSS in XHTML, I think these are probably the safest special classes to agree upon.
img.alignleft { float: left; margin: 0.5em 1em 0.5em 0; }img.alignright { float: right; margin: 0.5em 0 0.5em 1em; }img.center { display: block; margin: 0.5em auto; text-align: center; }
I deleted the img element prefix from the descriptors above because I agree with Adam’s comment below. Still not sure about what to do about content columns.
An all-caps class
Another that I noticed first in Kubrick and have since seen all over the place is span.caps. I’m not sure why this came about, but I find it useful enough. It’s purely presentational.
span.caps {
font-variant: small-caps;
}
This could also be text-transform:uppercase; with essentially the same use. A per theme choice, I suppose.
XFN relationship classes
I’m also adding XFN link classes to my theme revisions. Why? Because I’m fascinated with Microformats, frankly. I found these great microformat icons, notably the XFN relationship icons.
Now, there is a more technically accurate way to style links with XFN relationship attributes, as noted on the XFN intro page:
a[rel~="friend"]{
background: url('xfn-friend.png') no-repeat center right;
margin-right: 2px;
padding: 2px 26px 2px 0;
}
But this, of course, requires the browser to be whooly CSS 2.1 compliant, i.e., handle CSS attribute selectors. And can we guess which browser doesn’t do this? (If you guessed IE, then you already knew the answer.)
Using attribute selectors in CSS can cause IE do all sorts of strange things, like ignore any inline selectors and following descriptors. Which means that not only will CSS not display an icon (as is set above) but might also screw up following CSS selectors. It’s touchy.
So this is my compromise. Which is fine, and forward-compatible:
a.xfn-friend {
background: url('xfn-friend.png') no-repeat center right;
margin-right: 2px;
padding: 2px 26px 2px 0;
}
The downfall of this is that it would be undermined if the link had the class but not the rel="friend" attribute. Which would be deception by icon.
Anyhow, those are just the most minor of things I’ve been considering and I’d like to hear what others had to say on the subject.
18 Comments
IMHO, an
.alertclass would make sense.good stuff. i hate having to edit posts when i change themes. the other really common ones i see are
a.download,.alert,.left,.column-left,.right,.column-right.i think restricting the align's to the img tag is actually bad, we should probably leave things as open as possible (in case people want to stick the class on a blockquote or something).
perhaps the best would be:
.alignright, .align-right, .right, .column-right { float: right; margin: 0.5em 0 0.5em 1em; }or something.
i dig on the microformats, but i don't know about adding them as classes inside posts. it's probably worth writing up a plugin that adds onto the link editor, adding the XFN stuff to it. then it could automatically add both the rel's and the classes.
I like the
.alert. Very good.I’m also thinking about adding
a.doc,a.html,a.pdf,a.zipbut I think, as Adam pointed out with images, that these might be better as unspecified to links (e.g.,.doc). Might be good to throw.downloadinto the mix. I use it here.I also have to agree that the XFN link classes would be better handled as a plugin. This probably isn’t a “theme” style issue, per se.
Maybe a plugin that adds classes to links with XFN
relattributes? Hmm.Hey Scott, would love to chat with you about these ideas, as they’re ones that I’ve been bouncing around for some time.
Also, this is a timely post that you might read on another person’s implementation of XFN-icons.
Anyway, totally supportive of using semantic markup patterns (micropatterns, I call them) — and using conventions that are already in widespread use. Such “convenience classes” could be really valuable used in tandem with microformats (which are used for identifying data).
Anyway, would love to chat more about this — especially with regard to the forthcoming changes in Sandbox.
One of the most annoying aspects of changing themes is making sure all the classes I’ve used in the past are still going to do purdy things in the future. There definitely needs to be a little standardization, I think! Great list!
(Another kvetch I’ve had regards headings: some themes begin posts with
H2s, othersH3s, and some vary depending on what type of page is being displayed, so what level of heading should be used to subdivide posts and still divide the document correctly? Arg!)Great idea. A
.clearfixclass would also be helpful, for clearing after floated images. Ideally this would include all the right hacks for IE.Ok, Tantek deleted my micropatterns page. Apparently we should rethink this.
I’ve included a
.clearerclass in my themes before, but I’d totally forgotten about it. It is definitely useful when floating things regardless of browser.Also, Mr Carrier, you’re totally right about headings. This is how I look at it.
There can only be one “most important” heading. That’s was makes it superlative. So that should be the blog title (i.e.,
h1). I would argue the next most important item(s) on a page are post headings, ergoh2.So when I style content headings (e.g.,
.entry-content hX {…}) I begin withh3. But lots of themes leave these out.And I like
.importantover.alertfor some reason. But we best not talk about the color of the bikeshed.How about not try to standardize classes, but to get WP developers to include a custom style sheet option that persists between theme changes? Say an extra CSS that gets tagged onto the end of the theme CSS?
No matter how you try to standardize, there will always be theme authors who disagree, or who simply don’t know about this “standard”. But if the system itself adds a hook for us to set up site-specific CSS that is independent from the themes, it solves the problem completely.
To take it one step further, the system can allow for multiple custom CSS, providing a ordering mechanism, and we could implement the “standards” in the form of a plug-in or something similar.
This way, the extra CSS can be very specific (it should be, to avoid interfering with theme classes) and intermediate users who sometimes tweak their CSS gets to keep their hard work, too.
I chatted to Mark (Podz), Matt, and others about the img issue earlier today. WordPress would greatly benefit from a general solution here, because most WordPress blogs have hideous looking images in posts (text butted up img) and there is also another current issue of RTE inserted img should not use deprecated align property
I like the idea of a plugin providing the same CSS regardless of the theme. A plugin that provides an option to add CSS or link to a file and insert it into the
head. I’m sure there’s already something out there that does just that. But great idea.Perhaps related to this plugin idea would be to add one that gave the user an option to add one of the three image classes when using the RTE to insert images.
Speaking of images looking badly in most themes, don’t forget the
img{max-width:99%;}anddiv.sidebar{overflow:hidden;}. But we digress. Evendiv#wrapper{overflow:auto;}can keep things from becoming too terrible.So far I’m keen on
.alignleft, .alignright,.center,.clearer,.content-column,.important,.caps, and.download. I like the idea of just making.content-column{width:33%;}and using it in conjunction with.alignleft,.alignright.As Lloyd said above, we’re probably going to make the WYSIWYG do
.alignleft/.alignrightclasses by default in WP.I think that’s a great idea, Matt. Would that, by chance, include the option for
.centeras well? I haven’t used the WYSIWYG editor yet, but I imagine this as being a radio button option, like in the uploader.What about multiple images? For instance I want to put three images of the same size, all floated to the right, but stacked top-to-bottom. With a straight float, the images will get stacked right-to-left.
Currently I manually use something like a div,img,br,img,br,img,/div kind of setup and float the outer div. But I don’t know how many people frequently have multiple images up like that…
I think the really important part of this conversation is the semantic nature of the classes. Sandbox taught me reams about the importance of Semantic classes in my markup. It also made me buy a few books by Dan Cederholm.
I currently use on all my sites
.alert, .notice, .caps, .left, .right, .center, .clear, span.hilite, blockquote.pullquoteI have found them to be absolutely invaluable when moving from design to design. I have also appropriated your div id structure from sandbox for all of my sites, including those not running on WordPress. I have become so familiar with them it’s really simplified my work flow.(Note that .alert and .notice serve 2 very different functions. Alert is a problem while notice is informational. In my mind and alert is red, while a notice is yellow.)
I wish they made a thank you card the said all that, but until Hallmark recognizes the importance of semantic classes, I’m just going to have to leave this comment.
Being someone who reads most blogs in a feed reader, I hate the idea of a standard for image alignment that isn’t also taken up by feed readers
You would also have to get all the compnaies who publish feeds by email involved as well, because otherwise those emails might look horrible.
I use inline CSS for a simple left or right alignment so that my content looks how I want it to.
Andy: I hear you about feed readers. If the image is placed on its own line within the composition window in WP, then it gets wrapped in a
p’s, so it doesn’t look so terrible.Inline CSS is a great solution to that. Except that it mixes style with content, which I’m not so hot about. Especially if you’re like me and redesign your site every three months. But it is good for the end user.
I suppose it would be entirely logically to use a class like
.importantwith the HTML elementstrong, as labeling something as important dictates that it carries strong emphasis.Ben: Thank you very much for your nice, nice words. When Hallmark does make one of those cards, send one to Andy as well.
Scott (and others), any interest in setting up a forum or mailing list devoted to (X)HTML/CSS and your themes, esp. Sandbox? Would be a good place for seasoned users to strut their stuff while allowing us n00bs a chance to climb the learning curves more quickly. (In this regard it might make for a perfect complement to the skins showcase at Sand Castles, though that site seems to be down.)
There are obviously a lot of discussion areas for coders around the Web, but one focused specifically on this set of themes might be nice and, well, focused. Just throwing it out there.
2 Trackbacks
[...] added some standard classes to use in posts [...]
[...] Wordpress 2.5’s new image uploader solves the longstanding bug of using deprecated XHTML attributes to float images (align=”left”, etc.), rather than it being done in CSS. This is handled by applying classes to the image when it’s inserted into the post, rather than via inline CSS. This is good, in terms of semantics, clean markup, and separating presentation from content. It’s something that Scott suggested a while back, that I’ve been building into my themes and designs since. [...]