karinoyo

built in/with

wordpress jEdit tacoHTML smultron adobe illustrator adobe photoshop iMac

grid system sources

Olav Bjorkoy’s blueprint Stephen Bau’s fluid 960 grid system Vladimir Carrer’s EMastic

template inspirations

Eston Bond’s Gridlock Kerry Webster’s Dirty Girl Derek Punsalan’s Grid Focus Public ArtCulture’s Modicus Remix

tested

great in firefox 2.0.0.16 adequate in safari 3.1.2 (known css font size issues) others unknown

additional inspiration

Yahoo! UI Library’s YUI grid Kematzy’s Blueprint Grid Generator Arun Kale’s Morning After template Ulf Pettersson’s Modern template

b/w photographs

shorpy

color photographs

books, victures old book, Michal Zacharzewski, SXC precious old #3, Sanja Gjenero carpenter’s tools, Craig Jewell old books, Riesma Pawestri old tools, Jonathan Ogilvie garage #5, Thom W Metalshoppe #4, G Baden Tools, Guido Ruiter

plugins

Dan P. Benjamin’s image rotator Nick Momrik’s most commented Justin Blanton’s smart archives Scott Allen’s spamfree Ben Coleman’s flickr sidebar Brahim Machkouri’s category icons and category icons widget

And finally, a long-winded (of course) explanation about the design.

It was a long hard saga to get to here, and mostly because what I wanted — a strict vertical alignment with multiple inset columns — didn’t seem to co-exist with elegant code. In the end, I went with creating my own hybrid from among several grids. I started with Blueprint but strayed because while I can see its value in a purely design sense, it just seemed like 24 columns was way more than any average page I’d ever create. There’s kill, and there’s overkill. Plus, the Blueprint gridwork seems to visually destroy the grid even as it’s created: columns aren’t centered within gutters but are weighted to have 10px extra to the right.

This side-weight means end columns (at minimum, though in some demos the start columns also) must be independently marked to undo this added weight, which rather defeats the usefulness (for me) of just slapping the grid-width and moving along. On top of that, the use of column-borders adds margin & padding space, which can throw everything off. The result was that more often than not, there weren’t actually a total of 24 spans in one row, but 23, because the column would effectively eat up a span’s worth in the grid, and you have to compensate by reducing the row’s span-value by one.

That’s part of what I mean by destroying the grid even as it creates it. The rows weren’t adding up vertically without a lot of tweaking, and the point of any grid system — I thought — was to be simpler, not more of a hassle.

Worst of all in my opinion, the grid is a fixed 960px wide. It looked gorgeous on my iMac screen, but I couldn’t even see the entirety of the screen when I tested the site in IE6 on my 15″ laptop. (I won’t even go into how many hacks were needed to get IE6’s ridiculous margin/padding issues to handle the grid properly, even with the inclusion of Blueprint’s ie.css file.)

Given all the people I know (including myself) who view the ‘net through a smaller screen, or just don’t care to have a browser maximized, I really wanted a fluid-width page, instead. I switched over to using Stephen Bau’s design, then, which satisfied the fluid-width requirement but did so by complicating the CSS to the point of innumerable divs inside of divs inside of divs. Dropping just one would send the entire page into a hissy fit, and between the two, I’d rather build a fixed-width site at 760px wide than bury myself in CSS-divs. I liked the accordion feature but ended up a bundle of frustration over the fact that simplifying the layout (and removing even just one accordian’d block) seemed to throw it all out of whack and none of the javascript would work.

I tried YUI grids, but for all that I kept seeing folks writing about its flexibility, every manipulation I did with it — aiming (at the time) for the appearance of overlapping rows but a strict vertical pattern — just ended up breaking it… when I wasn’t breaking it just from trying to simplify the CSS into something that, again, wasn’t div inside of div inside of div. (And not the most sensical div system, either; I got the intention in the naming scheme but it certainly wasn’t immediately intuitive.)

Then I tried the Blueprint Grid generator, to at least create a similar structure but with a page width closer to about 750px or so. Unfortunately, that put me back in the original boat of having to structure any inset divs as less-one to make up for space taken by columns. After too many hours gnashing my teeth at the butchered vertical pattern all because I wanted a main level for the three most recent entries and then sub-columns with older entries — sub-columns, I should add, that didn’t line up with the above because of the insets — I ditched Blueprint again.

After a very short interlude of trying to figure out what the hell these designers are going on about when it comes to the showgrid.png background and the math involved and their rationalization for only adding padding/margin weights to one side, I spent an even shorter interlude trying to reproduce that math to figure out column widths… and said to hell with that, the only sane option is to poach what I want, rip out the rest, and see if I can’t get it to work.

I first modified Bau’s 16 column version into an 8-column system, using Khoi Vinh’s Subtraction.com as my altar upon to worship etc, but again the borders and side-columns and whatnot got in my way, plus 8 columns really isn’t that flexible. It probably only works well if you know exactly what you want on each page, in terms of layout. I wanted to have room to move around while I figured out a design, so I did need more give.

I didn’t like Blueprint’s use of “span-1,” “span-2,” etc to indicate column widths. It might make logical sense but it’s hard to track on the eyes when you’re staring at code, given that [span class=""] and [span id=""] are standards in CSS. I did like that the CSS for Blueprint was otherwise elegantly simple, though. Testing Bau’s em-based fluid width got me funky visuals in IE6 (and to a lesser degree, in IE7 once I upgraded), but using the percentage-based widths worked nicely.

As long as I’m muttering to myself, I’ll add that IE doesn’t particularly like the append, prepend, suffix, prefix, whatever-whats Blueprint, EMastic, FluidGS, and their ilk like to use. It could be more of that margin/padding issue, or maybe it’s just me. (It’s possible.) Besides, the impression I get is that these push, pull, prepend, append, on and on exceptions are designed to break the grid, which sort of defeats the purpose of having a grid. I am aware that sometimes a sudden break in a strong grid can be a visually dynamic element, but my point here is that when you look at the code for the base grid, and then you see that there’s another five times as many lines to define the exceptions… it’s a little out of hand. No wonder IE goes bonkers; Microsoft may create bloatware but it never seems to be able to create applications that can handle bloated code from any other source. Eh, well.

In the end, I stripped the FluidGS code down to the bare bones, for 16 columns and percentage-based:

.container {background:#fff;width: 90%;margin-left: 4%;margin-right: 4%;}
comma-delineated list of grids {display: inline;float: left;margin-left: 1%;margin-right: 1%;background:#fff;}
.container .grid_1{width: 4.25%;}
.container .grid_2{width: 10.5%;}
.container .grid_3{width: 16.75%;}
.container .grid_4{width: 23%;}
.container .grid_5{width: 29.25%;}
.container .grid_6{width: 35.5%;}
.container .grid_7{width: 41.75%;}
.container .grid_8{width: 48%;}
.container .grid_9{width: 54.25%;}
.container .grid_10{width: 60.5%;}
.container .grid_11{width: 66.75%;}
.container .grid_12{width: 73%;}
.container .grid_13{width: 79.25%;}
.container .grid_14{width: 85.5%;}
.container .grid_15{width: 91.75%;}
.container .grid_16{width: 98%;}

At this point, I finally had a basic grid system that was flexible enough to suit what I want, but with a CSS that wasn’t overloaded with boxes and blocks and insets and containers and wrappers and myriad other endless lines of divs and divs and divs.

A’course, then it all went up into the air again when I tried to introduce this system into Movable Type. That certainly seemed like a good application, based on its functionalities and plugins, but it wasn’t long before I was contemplating throwing rocks through SixApart’s window the next time I’m out in San Francisco. Just as a taste, the page on About Template Sets claims to be a page showing how designers can upload, select, work with, etc template sets, but its information is cursory, rudimentary, and pretty much assumes you already know everything it’s telling you so you aren’t bothered by the truck-sized gaps in the path. Gee, thanks. Add in that MT’s system is perl-based and has its own somewhat nonsensical naming scheme, even the ostensibly-useful Movable Type Cheat Sheet was pretty much a waste of pixels.

Great, now I know the MT codes for calling functions, but where can I find the most basic streamlined empty container version on which I can overlay my own design? (There’s one link out there that shows up if you google the right combination of words, but the download link has been dead for awhile, and the version it claims to minimalize is two versions back on MT, anyway.)

I did try taking the default MT layout/template/theme and stripping it down, but all I ended up with was a broken presentation. So many moving parts, and nothing anywhere that said, here is a basic template with the absolute barest contents. Coupled with an admin interface determined to do loop-dee-loops on itself, I just pitched it and moved on to trying Wordpress instead.

Designing for Wordpress

One thing about Wordpress over MT (regardless of overall built-in functionality) is that at least WP has bountiful documentation. And, just as valuable, it has bountiful opportunities all over the web for free, fully-designed, templates. An hour or so of searching and I ended up with six or seven good minimalist templates in my pile.

Thing is, I liked the way Dirty Girl had the header with a visual of the right-hand column starting above the content. I liked a lot of the basic CSS elements in that style — more than the first template I installed (Gridlock), but I couldn’t get any of the most basic settings to actually change. Eventually I realized that for some reason — beta, anyone? — there are eight or more CSS files involved in the presentation, and I’m not even sure all of them are being used, even if they’re in the download. Here’s a screenshot of the various embedded files, just to give you an idea of the layers:

I mean, honestly: is all of that absolutely necessary?

I liked the sidebar from Modicus Remix except for its automatic inclusion of Google Adsense and its breakdown of RSS into post feed, comment feed, full-entry feed, and summary-only feed. (Again, is that much detail really required? Most folks, myself included, just hit the freaking orange quarter-cicle thingie, let the subscription pop up in our reader or email app, and go from there. We’re perfectly capable of clicking on “read more” if we only get a summary, and we’re just as capable of skipping the rest if the opening sentences don’t catch our attention… but I’d hate to be trying to subscribe to the actual ArtCulture page. Options are good but there’s got to be a limit.)

I liked the entry style used in Gridlock but not the side-columns; I liked the simplicity in the code for Grid Focus’ header navigation (a great deal cleaner than Dirty Girl, even if the end result is almost identical). And since some had a grid — or sort-of-a-grid — and some didn’t, the best last option ended up, again, to rip it out and poach what I wanted and ditch the rest.

I guess in some ways I should say: a lot of these templates are minimalist in the visual sense. They aren’t so much in the actual code, and if I had to pick, I’d take elegantly streamlined code over a simplistic interface, any day. Doesn’t mean I’d be happy, just that if I had to choose…

I took screenshots of all the designs I liked, and put them together in PS to create a basic index.php image. Then I studied the fonts all over the page and narrowed them down to five basic sizes/styles. First, all fonts got lumped into this global:

{font-weight:normal;font-family:arial, helvetica, sans-serif;line-height:1.2em;}

From there, I decided there would be four settings, and as best I could manage (excepting text-decoration or color changes for in-paragraph links), everything would be one of these four. The variations between them, from largest to smallest are:

1) bold, 1.5em
2) normal, 1.15em
3) normal, .9em = paragraph/content font
4a) uppercase, .85em
4b) =4a but lowercase

There’s one exception in this, which is an adaptation of the “alt” version from Blueprint, which is the h3 class. This is for in-post subheadings, so it’s a manual use, but it’s the only one.

h3 {font-weight:normal; font-size:1.65em; font-family: "Warnock Pro", "Goudy Old Style","Palatino","Book Antiqua", Georgia, serif; font-style: italic;}

#1 is the h1 tag, which is used for entry titles, and page titles, and that’s it. #2 is the h2 tag, for the headers on the sidebar. The actual CSS includes “#sidebar ul” and “#sidebar ul li” in this designation only because WP got prickly when I tried to force the dynamic sidebars to use the h2 tag for headers instead of h3. Well, fine, I can work around that.

#3 is the paragraph/content font, and #4 is the top line of the main navigation, the header-line over each entry, and links on the sidebar. (I didn’t bother with forcing the font-weight and color, but just accepted the inherited styles from the base a: and a:hover settings.) #5 is the ’span’ version of #4, with the only difference being the text is forced to lowercase, instead of uppercase. Right now there are no descriptions for any of the links, but the style is there and ready to be used when I get around to expanding the sidebar’s modules.

The problem, obviously, was that every time I turned around, regardless of origin, the code was whacked with a different name for each tiny bit and eight exceptions to every rule. I did end up having to go through line by line, and kill stuff, until I could get it all down. By the time I was done, I’d gone from six files in the /css subdirectory to just one style.css file; the only css I may end up keeping is the ie.css hack/workaround from Blueprint. I didn’t bother keeping the print.css option, given WP already has a wp-print plugin. (I just don’t have it hooked up yet.)

Just to give an idea of things that had me going wtf, srsly, were lines like this:

<div id="post-[ID]" class="post-container-inner">
<div class="line-1">
<div class="post-meta-1">
<div class="post-date-year">
<span class="post-date">
[DATE]
</span>
<span class="post-year">
[YEAR]
</span>
</div>
<div class="post-title" style="border:1px solid red;">
<span>
[TITLE]
</span>
</div>
</div>
</div>

So let me get this straight: at the start of every entry, there are four divs, followed by two separate divs — for the day-of-week + day-of-month display, and then one for the year. And then not only is there a div for the title, but that div is hard-code modified and then treated further to a span. Eh, wtf, over? Why not just freaking code all of the style you want into a single div and let that do all the work, instead of setting, modifying, and further modifying? That’s really the biggest problem with multiple css files: I never could figure out where the final say was, on any style. Sometimes I found a style redefined twice in the same css file.

I ended up just deleting line and after line of divs, and merging where it made sense. I’m still not sure why it’s necessary to define a class for “post-comment” and “post-date” and “post-author” when all three of them have the same blooming size, decoration, weight, alignment, etc. Why not just declare one class to be “meta” and leave it at that?

Yes, I know I’m borderline on the snark, and I don’t mean to be malicious about anyone’s code (we all have our preferences and styles, and it’s possible some folks do prefer to define each instance as a separate case), but frustration did push me to the point of genuine confusion. Is there something I’m missing? Is there some inherent value in so many levels of divs, that I can’t see?

A simpler version but no less baffling:

<div id="mid" class="fix">
<div id="mainCol" class="fix">
<div class="post" id="post-[ID]">
<div class="postMeta">
<span class="date">
[DATE]
</span>
<span class="comments">
[COMMENTS]
</span>
</div>
<h2>
[TITLE]
</h2>
<div class="entry">
<p>
[CONTENT]
<p>
</div>
</div>

Why have two divs in a row with the class of “fix”? What was broken? Why then have a class for setting the post ID followed by an inset class for the meta — and then another set of divs even though the on-screen appearance is identical in terms of font, weight, etc? And then not only is there a div for “entry” but the entry further gets bookended with <p>. It doesn’t really need that <p> designation, after all, if the “entry” class contains the same definitions as <p> (and if not, why not drop “entry” and have only <p>)?

Unless, of course, those previous five or whatever numbers of divs managed to impose absolute wackiness on down the line. This, too, is ignoring that in the CSS for this particular template, there are settings for “post” and settings for “entry” and I never did figure out what the difference was. If the overall presentation of the summary/short entries on the main page is effectively the same as single-article pages with the sole change of the content going from short to full, then… am I missing something to say just have one definition for “entry” and treat it as global?

This is the index.php code I ended up with, by the way:

<div class="entry" id="post-[ID]">
<div class="meta">
<span class="info">
[DATE] [AUTHOR] [REMARKS]
</span>
</div>
<h1>
[TITLE]
</h1>
<p>
[SUMMARY]
<p>
<div class="grid_14 linkname">
[CATEGORY]
</div>
<div class="grid_2 linkname">
[READ MORE]
</div>
<hr class="blank">

That last line is a hack, since I couldn’t figure out how to get the quasi-dotted line (the “meta” div) to increase its padding-top without funkifying the vertical alignment between the dotted-line and the info hanging off to the right. The class for “info” is identical to that of “linkname” except for being right-aligned. When it gets to the post-title, all divs are closed except for the grid-width setting, <h1> and <p> stand on their own, and then I used the grid to separate the category and ‘read more’ options rather than mess with the text-align:right and float:right madness of multiple spans etc etc.

Which reminds me…

Important! About percentage-grids…

When it’s a fixed-width grid, then you add up all the grid-widths and it should total the number of grids across (ignoring the column-border issue for now). So if you do an inset grid-row, then if the parent column is, say, 10 spans wide, you’d set the two children columns as being two values that total the parent’s width, say, 4 spans and 6 spans.

If you’re using a fluid width, though, the browser/server will not add up the sub-columns and determine they’re equal to “whatever is the total pixel value of the parent width”. Nope, the browser says to itself, the parent column is now the 100% width that’s further subdivided into 50% and 50% (or whatever combination).

Frex, in my grid a single span is 10.5% of the total body spread. If the parent-column is 50% of the overall page, then a child-column that’s one-span (that is, 10.5% of the total available width) is not actually 10.% of the overall page width but only 10.5% of the parent width. Whoops. Wondered why those columns kept looking funky… which means that every sub-column set must, in turn, add up to 100%. As long as you keep that in mind, the percentage-base grid will behave like a fixed-width grid in terms of lining up neatly.

(I don’t know if this is also true of fluid grids based on em-values.)

remaining questions

I’ve several but this is the one currently springing to mind: if you enter a numeral followed by double-quotes, WP changes the double-quotes to a ’smart quote’ and adds an extra space. I have no idea why. Example:

To get around it, you have to use the hex-value for the number. That is, you enter:

And the output then becomes:

Which, if you look close, is still somewhat bizarre: the quotes start off as straight, and then go to smart quotes. Scroll down through this post and you’ll see how this feature seems to go on and off of its own accord. I’m sure I can come up with something to stop the numeral+quote issue, possibly even stop the randomized smart-quotes (or at least make it consistent), but I’ve not yet checked the WP forums to see if this is a known issue. I’ll do that later.