In a lot of the CSS code I see, people don’t seem to be aware of shorthand properties. They are an excellent way of keeping your stylesheet condensed and it also gives you an easy overview. Basically, it’s a way to write one-liners to affect all sides of an element or all similar properties grouped together.

The general rule is to apply length values for padding, margin and borders. They are to be written in this order, according to the element’s sides: top, right, bottom, left. If you only write two values, it will be for: top/bottom and right/left. Write three values and it will be applied like this: top, right/left, bottom.

NOTE: Remember to always specify a unit, such as px, em, % etc, unless the value is 0.

/* 2 px margin all around */
div#header{
	margin:2px;
}

/* 2 px top/bottom margin and 4 px right/left margin */
div#header{
	margin:2px 4px;
}

/* 1 px top margin, 4 px right/left margin and 8 px bottom margin */
div#header{
	margin:1px 4px 8px;
}

/* 
	1 px top margin, 3 px right margin, 8 px bottom margin
	and 5 px left margin 
*/
div#header{
	margin:1px 3px 8px 5px;
}

W3C’s CSS 2.1 specification on margin properties, padding properties and border properties.

For font values, the shorthand property is applied in this order: font weight, font size/line height, font family.

/*
	A bold font weight, 10 px big with a line height of 14 px
	and desired font family specified in prioritized order.
	The font weight value and the line height value can be omitted.
*/
div#header{
	font:bold 10px/14px Verdana, Arial, Helvetica, sans-serif;
}

W3C’s CSS 2.1 specification on the font shorthand property.

When it comes to background styles, it comes in this order: background color, background image, background repeat, background attachment, background position. Like this:

/*
	The element will get a white background and have
	a non-repeated background image that is placed 
	in the element's top right corner.
*/
div#header{
	background:#FFF url(images/funky-pic.png) no-repeat right top;
}

W3C’s CSS 2.1 specification on background properties.

Using shorthand properties results in a compact CSS file whose weight in kbs will be as little as possible.

PS. A nod to Roger‘s Efficient CSS with shorthand properties post, which I read after I wrote this. It contains more information for those of you who can’t get enough! DS.

Everything can be done through CSS, even Windows XP.

Two short topics today (see the other one below). This one is about what I wrote about in the beginning of April, how to structure one’s CSS file. Now the more well-known Douglas Bowman has written a post where he explains some of his tricks.

And, as I also wrote in two comments to Douglas’ post, I use Bradbury Software’s TopStyle for writing my CSS, which gives me the possibility to expand or collapse CSS rules by my choice.

Also, one thing I think is missing in CSS is a class-like grouping method. For instance:

div#header{
	a{
		color:#F00;
	}
	ul{
		list-style:none;
	}
}

where those styles above would only affect the elements within a div named “header”. Sounds like a good idea, doesn’t it? 🙂

Since most of my readers are very interested in CSS and many of you know who Dave Shea and Molly are, I thought I’d try and write a review of their the Zen of CSS Design book, that I just finished reading. One reason is to give my personal view on it, and another is to maybe give you some idea if this book is for you or not.

First, I just have to say that in the “About the authors” page, it’s hilarious that (to me) Dave looks like Molly’s boy toy… 🙂

With that aside, let’s start from the beginning. I love the cover and the format of the book. Glossy colored pages are so much nicer than the developer books I usually read. When it comes to the format, I’m not sure if the credit should go to this book, or to the New Riders publishing company (I don’t know, since this is the first book from New Riders that I’ve read), but either way, I love it.

The book is about the incredible css Zen Garden web site, which is a showcase for using the same well-structured XHTML file for over 160 different designs, all solely based on the content of their corresponding CSS file. The web site is an invaluable tool to show people what can really be accomplished with CSS, and this book covers some of the different designs’ code, color, images, typography, concept etc.

Maybe this is just me, but I felt that the book is mostly written too much from a designer’s point of view. And to be fair, designers are the ones behind the different designs, but I have never myself, or met any other that has, had the role of being the designer and the one coding the CSS. In “my” world that’s two different roles, normally an AD and an Interface Developer. I don’t know what it’s like in the rest of the world, but here in Sweden the word “Web Designer” has a bad ring to it; to me it symbolizes the first developers in the beginning of the commercial internet era, the ones that were hard-coding the pages and doing everything from the design and copy writing work to the interface coding.

With that said, I have to admit that some of the topics in the book are things that will (probably) never apply to my professional role and I won’t browse through those chapters as a reference in my daily work, but they were still interesting to read one time.

Getting back to the format of the book: every chapter has small boxes in the margin, usually named “tip” or “note”. They turn out to be links to very useful web sites with solutions to and ideas about handling different scenarios. Personally, I’d wish that the content of some of those linked web pages were discussed in the book (some of them are mentioned in the text, but not much more). I think the book would’ve been more interesting if they had been a part of it, instead of only focusing on having a different css Zen Garden design as a starting point all the time. On the other hand, maybe that’s the whole point of this book. I don’t know. But to me it could’ve been the ultimate CSS/interface developing book, but now it’s “merely” a guide to the different designs in the css Zen Garden.

The chapters are:

1. View Source
2. Design
3. Layout
4. Imagery
5. Typography
6. Special Effects
7. Reconstruction

I think it started off great with the View Source chapter, but after that it just wasn’t as intriguing. Bits and pieces of the other chapters were interesting per se, but not extraordinary. The last three chapters got more interesting though, starting with chapter five, Typography. I don’t regard myself particularly skilled in that area, so I gained something from it. Then chapter six and seven, Special Effects and Reconstruction, respectively, had some nifty things to pique one’s curiosity.

The Closing Thoughts was one of the better parts of the book, with good advice and introducing a link to Dave Shea’s CSS Crib Sheet.

However, there are two things that the book promotes (in some places), which I don’t like:

Pure CSS Menus

I can live with changing the look of a link with :hover, since it’s more of a state, but I think creating menus belong in the behavior layer.
Take, for instance, this sentence in the part about the Tulipe design:

…you can always default to JavaScript for dynamic menus. There’s nothing wrong with that, but CSS allows you to do it more elegantly…

It’s exactly this general attitude, that it’s so easy and elegant to do it in the CSS file, that I personally don’t like. I express my opinion more detailed in my Three separated layers, capisce? post.

Browser elitism

The book is full of mentioning things that won’t work in IE on a PC, and I agree that it’s important that all of IE’s shortcomings are brought up. I also like that it is being addressed in how to write the CSS code to handle them. The thing that bothers me, though, is that there are several designs covered in this book that delivers more stunning designs and effects to more competent web browsers, like Firefox and others, while serving a more bland version to IE.
That, to me, is showing a browser elitism attitude, and that way of approaching things is exactly how IE got away with its different proprietary techniques that later resulted in people writing code that only worked in IE. Sure, in the book’s case, the extra effects are written according to the W3C recommendations, but personally I think that one should do it’s best to deliver an equal design and its effects to all of one’s targeted web browsers.

Coding wise, as in all books, there are some minor flaws and typos that aren’t even worth bringing up. One thing, though, that got to me, was a part where catering to IE 5.x incapabilities of centering content with text-align alternatives, instead of the correct way with using width and margin:0 auto;, is refered to as a hack. The code:

body{
	text-align-center;
}

#container{
	text-align:left;
}

Using text-align in a clever way is not a hack to me. The Box Model hack is a real hack. Maybe I’m just nitpicking, but I think its a vast difference between a smart, validating and correct solution and an actual hack.

Another thing:
In some chapters, especially in the last one, there are numerous places with sentences like:

If you go to the web page, you can see the full CSS…

Sure, but what’s the point of buying the book then (except for the explanations)? I understand that the different chapters can’t have CSS code running page up and down, but it would’ve been nice with an appendix of the different CSS files, to get a feel of the whole structure (and not having to resort to a computer, while sitting out in the Spring sun and reading…).

All in all, despite my criticism above, I do like the book. It’s a good read, but not as amazing as I had hoped for. Too much focus on the design, and to little of solving problems all the way, discussed from every angle. Maybe too many designs covered instead of focusing more thoroughly on fewer ones?
However, I’m convinced that many people will gain a lot from reading it, and it shows off some cool CSS.

PS. A little bit over a month ago, Tommy wrote a post about this book and some of his opinions about it. DS.

Si, capisco. But many people don’t understand. Or they don’t want to. Or both.
Interface code is supposed to consist of three layers:

• Content (HTML)
• Layout and looks (CSS)
• Behavior/interaction(JavaScript)

This is so basic, just like using semantics. However, as Jeremy Keith writes in his excellent piece Gotta keep ’em separated (:hover Considered Harmful is also a recommended read), a common problem is that many, many developers use pseudo-classes in CSS for interaction effects.
Hence, of course they then complain about IE‘s incomplete support for CSS 2 (which is a very sad thing, I agree), since there are a lot more pseudo-classes available in it that are supported by web browsers like Firefox, Opera and others.

But pseudo-classes aren’t the way to go, and I don’t know what they’re doing in the CSS specification in the first place.
So why do developers use them? Like Jeremy, I believe that it is because it’s easier to do it that way, and not all of them are accustomed with JavaScript. Peter-Paul Koch also wrote about this (amongst other things) almost a year ago, where he concludes:

However, everyone’s personal preference seems to be CSS these days, and that’s what bothers me. The balance is lost. People seem to be afraid of JavaScript.

And Jeremy wonderfully states:

There is a gap in your skill set that needs to be filled.

That’s all to say, really. Do it right or don’t use it. Many developers (including my Interface Developer colleague at the company where I work) argue:

But it’s so easy to have it in the CSS file.

But what kind of an argument is that? As easy as using tables instead of CSS? As easy as having FONT tags? As easy as using DIV tags for every element on the page and then style them?
It shouldn’t be easy, it should be correct.

There are two cases to argue this, that are semi-valid points that should be answered:

1. Accessibility
   True. There might be cases where the visiting web browser has JavaScript deactivated/doesn’t support it, but supports CSS.
   But as always, the page should be usable for visitors that doesn’t support script. Not a valid excuse. Another factor to this is that DOM scripting is more widely supported than CSS 2, which means that you will probably be able to target more users with an onfocus event than the corresponding :focus pseudo-class in CSS.
2. Hover effects on A tags
   Having a numerous amount of links in a page would end up in massive code if you were to add onmouseover and onmouseout attributes to every A tag. But that’s not the way I’d do it, and not the way I’d recommend. Luckily, Mark has written the code for display, so I don’t have to put it here.

Now that we’ve finally managed to separate content and presentation, the risk is that the CSS file will just be the new replacement bulk file, with interaction in it as well. Please, please don’t let us repeat the mistakes we did with the HTML files in the beginning. Let’s separate things into where they belong.

As I’ve mentioned before, in my previous company we worked with offshore developing located in Serbia. Given the fact that we were sitting in different countries, different levels of knowledge of the English language, different skills and such, sometimes we didn’t work seamlessy together.

The phrase in the heading came from one of the system developers in Serbia, when he had (less knowingly) changed my interface code, followed up by the jokingly said comment “I improve design”.
Needless to say, in my eyes, it wasn’t improved (however, if you’re reading this, Aleks, no hard feelings from my side. It was an entertaining ride :-)).

I tend to be very though when it comes to the structure of my code, which leads me to how to set up the structure of one’s CSS file(s).
Earlier on, I used to order my CSS in the order things were rendered in the page. However, I soon realized that with additions and changes all the time, fixes and so on, this wasn’t really useful as soon as I got to build bigger web sites.

So nowadays, I structure my CSS this way:

First, tag-specific CSS:
a{
color:#FFF;
}

body{
margin:0px;
}

Then ID-specific CSS, in alphabetical order where the tag name is the separator:
div#containerDiv{
width:800px;
margin:20px auto;
}

img#artImg{
border:0px;
}

img#userImg{
margin-left:20px;
}

Followed by class-specific CSS for specific tags, in alphabetical order where the tag name is the separator:

div.contentDiv{
width:400px;
background:#F00;
}

img.linkArrowImg{
float:right;
}

And finally class-specific CSS for any kind of tag, in alphabetical order where the tag name is the separator:

.bold{
font-weight:bold;
}

.preAmble{
font:1.2em/1.6em Verdana, Arial, Helvetica, sans-serif;
}

This works just fine for me. Does it look good? How do you do?

Those words, uttered by Marlon Brando in Apocalypse Now, in the role as Colonel Walter E. Kurtz, symbolized how it felt for me to have do develop things for Netscape 4. Luckily, Netscape has been declared dead now.

However, I read an interesting post which claimed that Internet Explorer has become the new Netscape 4 for us developers (original post found here).
I think that statement is a bit too harsh, but Internet Explorer
absolutely poses the biggest challenge in every day developing.

The thing that bothers me, though, is when pro-IE developers say things like: “So what’s so special about Firefox/Safari/[insert name of more competent browser here]? What does it have that IE doesn’t?”
It is that kind of attitude that scares me, that people are able to get
along in their professional life as developers without even knowing
about all the things Internet Explorer is missing, the far superior CSS
support (amongst other things) in other browsers and so on.

Well, I advise those people to take a look at Eric Meyer‘s css/edge site (of course, the examples here need that you use a competent web browser).

One of the things I miss the most in Internet Explorer’s CSS support is attribute selectors.
How about adding a look for all input text fields, without using classes,
and without affecting radio buttons, checkboxes, submit buttons etc.
Impossible, you say! Nope. Just code it like this:

input[type=”text”]{
width:300px;
background:#F00;
}

Ah, amazing, isn’t it? Eric Meyer wrote an article in three pieces about this in August 2000, part 1, part 2 and part 3. I recommend you to read these, especially the “box of possibilities”, as I’d like to call it, at the end of part 3.

Microsoft Watch has also got some interesting rumours about what we might expext in IE 7.

Recently, I’ve been moving towards an attitude that I want to satisfy as many users as possible, which means that everyone should be able to see and use the web sites I build. To me, it feels kind of like a Google philosophy, to reach as many users as possible with really easy to use interfaces.

It has gone so far that I even avoid JavaScript enabled in the user’s web browser (people that have worked with me previously problably won’t believe this, I love JavaScript!). But it’s more about what it’s worth, that one doesn’t use functions, scripts, plug-ins etc just for the sake of it, but to actually use it when it is motivated and gives a necessary enchancement to the web site/page.

I mean, how many times haven’t one done very advanced things on a web page, that one has been particurarly pleased about, but then it looks different on another computer, doesn’t work in a third one just because, for instance, script is disabled and so on.

No, I have moved more in a direction where, instead of using advanced functions in the client’s web browser, try to create web user interfaces that are managed through CSS and where content and its looks is totally separated, as in the brilliant example CSS Zen Garden, where evry page has the same HTML and the CSS takes care of everything that has to do with how it looks and its layout.

Also, I really like when web sites gives the user an option to change font size for the current web site/page without the need of going into the web browser settings just to achieve that.

I’m also of the firm belief that to reach the major audience (i.e. “all” users) then it’s vital to make it as easy to use as possible for them., I believe most inexperienced users is bothered/discouraged by texts like:

“Optimized resolution for this site is 800*600”

“You need to have JavaScript enabled in your web browser to be able to use this web site”

“You have to install Flash to hear our epileptic music and to see our bouncing circles”

I think the future is to follow the W3C recommendations that most web browsers have a pretty good support for today (except for, mainly, the PC version of Internet Explorer) to reach as many users as possible.
To start thinking about the end user and show them respect, instead of just complaining about their lack of knowledge and thinking that they’re ignorant.