Well, it is. Hard, I mean.

Everyone knows how to build some shelter: put some stools and cover with branches and it would mostly fit the bill. If however it should withstand the wind and rain, it requires quite a bit more skills. Everyone knows how to get heating: put some wood and start a fire. Only few knows what it takes to build proper, natural heating that’s just there.

The same is with web development. Anyone can build a web page that looks fine to them. But it might not be fine to me or some other people. It might be downright inaccessible to some. It might be pain in the ass to some other.

Every single time I encounter rants like those two linked above, it’s plainly obvious it’s made by people who just don’t get it. I mean, just look at those two rants/posts (whatever you call them) and you’ll see how not-getting-it is the core of their frustration.

Just one example:

On the screen the natural order of flow for the five major layout elements is: top, left, center, right, bottom. But the actual order in which they appear in the code has “right” and “center” reversed. Is this a mistake? To find out, let’s see what happens if we change them around so that the order in the code matches the presentation order:
…
Youch! That looks terrible! Apparently the order matters. The reason that the order matters is that this layout, like all multi-column CSS layouts, is achieved with floats, and the way that floats get rendered depends on the order in which they appear. So we have not managed to separate content from presentation.

Yes Ron, it does not look good because CSS rules were written to achieve the desired layout using the given HTML structure code — which could also be much improved, but that’s another topic.
To give you real-life example: do you have a bike? Do you expect to be able to drive if you sit on it faced to the rear of the bike? Hm, crap, I can’t turn the pedals properly. The bike is shit.

The other rant is even worse, the anger of not being able to code the desired layout in CSS is spilling from all corners. I can understand that frustration and have experienced it several times, when I tried to learn something and failed to do so.

I drank the Kool-Aid, and I woke up two weeks later with a broken design. I had a headache from banging my head against the CSS wall. But, it simply couldn’t be a problem with CSS itself. The problem had to be that I didn’t understand CSS well enough. The answer had to be that I was bad, lazy or I didn’t care about web standards or something. The internets had told me so.

Yes iamelgringo, you’re just not up to it. You should have admitted it to yourself and hired someone else who is, to finish the job. Or just use tables as you did and get on with your life. Posting this:

So, I don’t ever want to read how web designers who don’t use pure CSS in their layouts are lazy, stupid, don’t care about their craft, backwards or don’t bathe properly. Never again. People who post such things online are heretofore to be known as CSS Trolls and are to be banished from the internets for all time. Begone yea vile fiends!

just makes you jealous wanker.

And just to touch lightly on the argument about Google – the fact that Google is not using CSS-based design is responsible for the fact that they have two different search pages – one for desktops, another for mobile devices (when I think about it, they probably have more than two). Multiple code bases for the page that has one input field and two buttons on it. Sheeeesh…Google’s front page is prime example of crapy front-end work.

Will code HTML for food. And give you crap code for it.

Or however that joke went. There are many reasons why tables are not to be used for layout. Two important ones are:

1. tables are fixed structure which cement the layout for good
2. cemented structures are impossible or way too hard to adapt to displays with vastly different screen estate

For instance, take a look at my winery web site. If you look at it on desktop browser, you’ll see rich graphics, 3-column web site. But if you look at it on iPhone in portrait mode, you’ll see one-column website with some graphics removed. All it took to achieve this look is one meta element in the page head and half a screen of additional CSS rules. It would be just as simple to adapt it to other mobile browsers. Let me see you do that this quick and fast with tables.

Not to mention how impossible is to achieve noticeably different skins if you use layout tables. For the last several years I have maintained old and created new instances of company’s main web product, using the very same code base, with just a different set of CSS rules and images. 20 or so counting, each new instance was several days at worst for the complete reskin job.
Every time I need to apply some designs to pages created using ASP.NET, I cringe and resign my case or dig deep and redo almost entire contents of the .aspx files. It takes good deal of knowledge to do things properly.

Not everyone are capable of doing it, which is just fine. There’s plenty of other professions, not everyone should be web front-end developers. If you don’t know how to do it and/or are incapable of learning, just give up and find some other thing to do in life.

Don’t go around prophesying nonsense.

Recently, at the office, I had client request to create a design like this:

The HTML I had already was like this:

<div class="buttons"><strong>


 


<input type="submit" value="Continue →" /></strong>


<span class="lesserbtn">


 


<input type="submit" value="Cancel" /></span></div> 

There was no chance to change this into anything drastically different as bunch of server-side code depended on form submit buttons being input elements. Thus, I went with this code and looked for CSS solutions.

One really helpful fact was that all captions were one line of code. Thus, I was able to use one long image with rounded corners. I had two nested elements as well, which is enough to get the design up.

Basic idea I had was to put background image on both the input and its parent element, both aligned to opposite corners.

Step 1 — remove default styles

This is fairly easy, but necessary.

.buttons {


line-height: 1;


}


 


.buttons input {


line-height: 1;


font-size: 1em;


font-weight: bold;


margin: 0;


padding: 0;


border: 0;


} 

Step 2 — enclosing element

Now, let’s start with the styles for the button first.

.buttons strong, span.btn {


background: url(btn-round.png) no-repeat left;


padding: 1em 0 1em 5px;


margin-right: 10px;


cursor: pointer;


} 

This is left side of the button. Note the use of vertical paddings. Since this is inline element, they do nothing to the text but they do expand inline box. That way, background graphic is fully revealed.

Step 3 — actual button

.buttons strong input, span.btn input {


color: #000;


background: url(btn-round.png) no-repeat right;


margin: 0 -5px 0 0;


padding: 1em 10px 1em 5px;


border: 0;


cursor: pointer;


} 

Same thing for internal element, but this one is forced 5px to the right to reveal the rounder corners of the previous element.

And that’s it. Fairly simple and mostly works ok. Here’s an example page.

Problems

It’s strange that it does not work ok with all fonts. Example page shows that when Calibri is used, images don’t always line up. In Safari, they don’t fully line up even for Helvetica Neue. They do line up for Verdana, Georgia, Arial. In Opera 9.5 Calibri example is the worst.
Second problem is that in some cases, when larger font sizes are used, images again don’t line up.
Amazingly, the only browser I didn’t have an issue with is IE, both 6 and 7.

I could not get to the bottom of this. If anyone have any ideas, please share. Inline box is a very complicated issue and I’m sure there’s something I’m missing.

Another goal was to create as typographically good design as I could. It should follow the vertical rhythm, use the appropriate characters for given context and feature nice readable font faces.

I have created demo page that showcases all that nice typography. Another demo showcases some grid options.

Typography

In the demo page I tried to include every little detail that shows how all this looks like. It will serve me as the reference point for markup and entity codes. However, I don’t claim any breakthrough stuff here — all this stands on the work of other people, neatly combined in one reusable package.

I took most styles and leads from Jeff Croft’s presentation at Webmaster Jam Session and the excellent typography created by tipogrify engine, which is available as WP plugin.

I shamelessly copied John Gruber’s footnotes — they’re simply wonderful, down to that lovely contour arrow for going back to the footnote link.

The rest of the lovely characters, like single and double quotes, en dash and em dash, elipsis — these I found through Peter Sheerin’s wonderful article The Trouble With EM ’n EN (and Other Shady Characters), from A List Apart.
This is where I read that old typographic styling of the blockquotes was that each paragraph was quoted at the beginning but only the last is quoted at the end.

Speaking of blockquotes, I have included Roger Johansson’s work — value of cite attribute is displayed below the quote. This was the most challenging part of the entire CSS and due to the use of advanced selectors and generated content IE6 and IE7 users will not see it properly.

Grids

These are not the only possible grids, you can do whatever you want, as long as you follow two simple rules:

1. Basic grid unit is: default font-size * line-height.
2. Every block on the page must use margin, padding, width and height equal to a multiple of basic unit

First rule sounds simple. In the body element, I defined that my leading (line-height) is 1.5, meaning that my basic grid block is 1.5em high and — for consistency sake — 1.5em wide.

There’s one caveat: if for any block on the page you change the font size, then you need to calculate its dimensions using new grid unit. Here’s one example, where I want ctop block to be 20 grid units wide (which would be 20*1.5em=30em):

.ctop {


	font-size: 1.2em;


	width: 25em; /* 1 / 1.2 * 30em = 25em  */


} 

Since I enlarged the font, I adjusted the width for that, so that I can easily align it with some other block in the grid which uses default font size.

With that in mind, you can do anything you want.

I also want to re-iterate what I already wrote on the grid demo page: make your life easier and use normal, descriptive names for the blocks. CSS frameworks try to standardize the block names, so that you can add the suffixes and calculate the final size. And then you end up with grid6, prefix2, span-6, append-2 and similar non-sensical names.
After you built the layout, do you really need those classes? If yes, please write back — I would really like to know for what.

Me, I find them bloated. I draw the design on the piece of paper, write the sizes and spaces and then proceed to create a layout style with meaningful names like top, footer, main etc. YMMV, as usual.

Forms

Forms on your page will certainly destroy the vertical rhythm. You have no idea what are the exact sizes. Someone’s OS theme can vary this widely: it can have different base size, borders of this or that width, paddings…

The only way to fight this is to use min-height, also set in ems, also using grid unit multiples. I do this to control the comment form on my serbian blog.

Borders

The other thing that will dislocate your grid is border. For just about anything. Pixel guys have it easy here — they just subtract the border size from width and/or height and done. Here, things are a bit more complicated.

There are two solutions. One is to use negative margins:

.column {


	border-top: 1px solid #999;


	margin-top: -1px;


} 

This works if your column does not already have margin-top defined. If it does, this will not be applicable.

Even if it doesn’t, this will still not work if the previous element is floated, and this one is not. That’s the case on my typography demo page, where footer has top border and 2 columns before it are floated. In this case, your only option is this:

.footer {


	position: relative;


	top: -1px;


} 

I prefer to use the margin-top solution, whenever I can. Less problems in IE.

In any case, I do hope you like all this. I will certainly update this as required. Let me know if you use it or have anything to add.

I took the opportunity to add some screenshots of reference rendering vs IE6/7 rendering, to make it easier on those just casually reading to see what the errors are (previously you needed to open the pages in IE6/7 to actually see what is wrong).

Additionally, IE8 also supports :after, which I use for float clearing.
As it is, there will be no need for ie8.css hidden under conditional comments. Yipi! :)

.menu li {


	z-index: 5;


}


.menu li:hover {


	z-index: 10000;


} 

This does not work in IE7 — it will not re-render the page. Here’s the example showing this problem.

update: David Hucklesby points to solution: IE needs a “nudge”, direction:ltr works. As well as a lot of other rules.

The gem is under the hood. CSS-based all the way, most obvious by turning CSS off in your browser. Plus, only 5 errors coming from the validator.w3.org, for the HTML 4.0 Transitional. Much can be said on the quality of the code (way too many divs for starters) but really a nice step forward — they missed the validity perfection by only an inch.

The most important aspect — the site looks and works identical in Firefox, as in IE6. Now, that is huge and very welcome step forward for Microsoft.

95% of code is from Dušan Janovský. I merely simplified it, thus instead of 3 or 4 nested divs, you need just one div, for the actual content. html and body play the role of table and table-cell respectivelly. Pure semantics. :)
For IE6 and IE7, I opted for the expression property, masked under conditional comments. No other solution I encountered is flexible enough.

This solution has 100% of the available height to spread, because there is no fixed height set for the content div.

Anw, to the issue. Imagine floated element followed by an element which is absolutelly positioned (AP) and have this style applied:

display:block;


position:absolute;


top: 0;


width: 30em; 

You see, no left rule. IE will position the left edge of the AP at the point where right edge of the floated element is:

Opera/Gecko/KHTML will place it at the left:0 of the content area of the parent (which is what I would expect it to do):

Applying clear:both to the AP element has no effect, things stays the same. I have seen this behavior in IE6 several times, but I keep forgetting it and it hunts me again along the way, when I least need it. This way, I will probably remember it. I hope some of you might find this useful too.

* html SELECTOR { height: 1% } 

This is one of the ways you can force IE6 to clear the floats in a container. And it partially works in IE7 too. The reason height:1% works is that IE7 internal engine is same as IE6, just with a lot less bugs in it. Why is float clearing a problem then? Because this part of the selector: * html does not work anymore — that bug is fixed.

However, IE7 still incorrectly interprets height:1% rule and will automatically expand the height of the box in question if its floated content can’t fit. Thus, that trick is still a viable solution to float clearing, especially since IE7 does not support :after selector yet, thus the solution working in all other modern browsers is not usable:

SELECTOR:after {


	content: "."; 


	height: 0; 


	display: block; 


	visibility: hidden;


	overflow: hidden;


	clear: both; 


} 

The way forward

The * html will not match anything in IE7 and will have no effect at all. This also is an ugly hack: we use one IE bug applied through another IE bug. Ugly. Such hacks should be used only as last resort, when no other solutions are available. And IE has perfect solution available, called conditional comments.

Thus, using conditional comments the height:1% is still a fine solution for float clearing. However, there is a better one. IE7 now supports min-height rule (among others) and that rule also triggers the infamous hasLayout property in IE7 internal engine and thus it is usable for float clear.

SELECTOR { min-height: 0; } 

This is simple to use (just put it at the start of your CSS file) and enumerate the elements which content should be cleared — the same list you use for IE6. And all is fine, because this can sit in your main .css file and no modern browser would choke on it.

IE7 has good enough support for the CSS2.1 that you should very rarely need to write IE7-only hacks, thus have little use for separate file containing IE7 tweaks. Actually, the float clear is the only thing I needed to change in all the sites I created in the last few years to make them working in IE7.
What a welcome change.