The article “The Architect Has No Clothes“, by Michael Mehaffy and Nikos A. Salingaros, explores why modern architecture feels so cold and inhospitable and how that might be easily explained by a phenomenon called “architectural myopia”. The authors describe how this consequence likely has its causes in how architecture is taught and how the methodologies used in the classroom deprive future architectures from any empathy with those who will in the future live and use their creations.

It’s not my goal to provide a summary, as the article does a much better job at explaining this fascinating theory. But I started thinking about whether it would be fair to conclude us web designers might sometimes suffer from a similar malady. I also found it interesting that this profession I hear mentioned so many times as so established and as the ideal model to follow is, like our own, still finding its own ways.

After a restless start to the year, I finally had time and head to sit down and read through the first few weeks of thoughts. Some are longer than others, but invariably there is something alluring about diving in so quickly and for such brief a moment into someone else’s mind.

What is calc()?

The calc() function can be used to specify lengths. For example, you can use it for values of borders, margins, paddings, fonts, etc. Calculating widths can be extremely complicated, especially in fluid layouts; calc() is unique because it lets you make these calculations within the CSS itself.

It accepts addition (“+”), subtraction (“-“), multiplication (“*”) and division (“/“).

Let’s look at a simple example:

div {
	width: calc(100% - 20px); }

Easy, right? You can also have more than one calculation within a single function, for example:

div {
	width: calc(100% - 20px + 2px*2); }

In the current specification, it is stated that multiplication and division expressions have precedence over addition and subtraction. This means that, in the previous example, “2px*2” will be calculated before the other two expressions. Also, note that divisions by zero will (or should) result in an error.

The spec is not yet finalised (there is an Editor’s Draft version that expands on the CSS3 Values and Units Working Draft version), but these are the basics.

A simple use case

To show calc’s usefulness further, I’ve created a basic layout where I’ve applied it generously.

The layout consists of a main content container on the left, a sidebar on the right, and a footer, below the previous two. Here is the basic markup with only part of the text being shown, for brevity:

<div class="wrapper">

	<div id="main">
		<h1>Far far away…</h1>
		<p>Far far away, behind the word mountains…</p>
	</div>

	<div id="accessory">
		<ul>
			<li><a href="#">Far far away…</a></li>
			<li><a href="#">Separated they live…</a></li>
			<li><a href="#">A small river named…</a></li>
		</ul>
	</div>

	<div id="footer">
		Visit the article…
	</div>

</div>

After the (hopefully) self-explanatory simple reset (please check the full CSS in the example document), font properties and defining the links, I will define the look of my body element:

body {
	background: #E8EADD;
	color: #3C323A;
	padding: 20px; }

After that, I will say that the main container div should be full width (100%) minus 40px and aligned horizontally in the middle of the viewport:

.wrapper {
	width: 1024px; /* Fallback for browsers that don't support the calc() function */
	width: -moz-calc(100% - 40px);
	width: calc(100% - 40px);
	margin: auto; }

In the CSS above, I have also added a fallback width for browsers that don’t support the calc() function, and the vendor prefix for Firefox 4.

Following this, I will set the borders, width and margins of the main container div, and I will float it left:

#main {
	border: 8px solid #B8C172;
	float: left;
	margin-bottom: 20px;
	margin-right: 20px;
	padding: 20px;
	width: 704px; /* Fallback for browsers that don't support the calc() function */
	width: -moz-calc(75% - 20px*2 - 8px*2);
	width: calc(75% - 20px*2 - 8px*2); }

So what is happening in this calc() function? I am stating that I want my container div to be 75% wide (75% of its parent container, remember), but from these 75% I need to subtract “20px*2” to account for the padding on each side, and “8px*2” to account for the border on each side.

Moving onto the sidebar, I want it to occupy the remaining 25% inside the parent container, but this value will have to allow for padding, borders and the margin of the sidebar div (20px).

#accessory {
	border: 8px solid #B8C172;
	float: right;
	padding: 10px;
	width: 208px; /* Fallback for browsers that don't support the calc() function */
	width: -moz-calc(25% - 10px*2 - 8px*2 - 20px);
	width: calc(25% - 10px*2 - 8px*2 - 20px); }

Deconstructing “calc(25% - 10px*2 - 8px*2 - 20px)”, we have the original 25%, minus “10px*2” to account for the padding on each side, minus “8px*2” to account for the border on each side, minus “20px” to account for the main container’s right margin.

The footer is simply a full width div, I shan’t bore everyone by explaining that.

Because the sidebar becomes too small after a certain point, I’ve also included a simple media query that unfloats the main and sidebar containers, and recalculates their widths so they are 100% wide minus their respective padding and border values.

@media screen and (max-width: 768px) {
	#main, #accessory {
		float: none; }
	#main {
		margin-right: 0;
		width: -moz-calc(100% - 20px*2 - 8px*2);
		width: calc(100% - 20px*2 - 8px*2); }
	#accessory {
		width: -moz-calc(100% - 10px*2 - 8px*2);
		width: calc(100% - 10px*2 - 8px*2); }
}

This is a very simplistic use case, but hopefully it’s enough to spike your interest and prompt you to find out more about wonderful calc().

Browser support

Calc is supported by IE 9 and Firefox 4 (which requires the -moz-calc vendor property). I can understand, however, how this can be a bigger problem if compared to the relatively deficient browser support of things such as animations. While animations are accessory, incorrect measurements can break a site.

This does not mean though that we shouldn’t be trying these out. If Firefox and IE have made the effort to implement this, and these are the browsers with the biggest market share, I would suppose the others will follow suit (I’m not sure whether WebKit or Opera are working on this or not, but do let me know if they are).

In my example, I’ve opted for including fallback, absolute lengths for non-comforming browsers, which gives them a non-fluid layout. This might not be acceptable in your particular case though, but it is for my use case.

Reference

If you’d like to know more about calc(), head on to the following resources:

• CSS3 Values and Units, W3C specification
• CSS3 Values and Units, W3C Editor’s Draft specification
• -moz-calc on MDC Docs
• Firefox 4: CSS3 calc() announcement on Mozilla Hacks

Final note

Along with few other CSS3 properties, calc() is one of those new pieces of CSS that can truly make our lives easier. I haven’t tested it in terms of performance, so I don’t know how big an impact all these calculations might have on the browser, but I’d guess it won’t be more consequential than all those transitions and transforms that everyone seems to be so happy to indiscriminately add to their sites.

So, have you used calc() on a project? Is this something you feel is a welcome addition to CSS? I’d love to hear your thoughts.

The other side

Although I can’t say I have much experience interviewing and hiring people, when you’re suddenly on this side of the hiring process, some things become clear, mainly on how people could easily make their CV’s stand out from everyone else’s.

Your 15 minutes of fame

We’re busy all the time, so even though we make our best effort to make sure we only hire the best people, looking at applicants’ emails, agency referrals, CV’s, portfolios, takes a lot of time. So the first thing you should keep in mind is that people are busy. They want to see your work and capabilities straight away. Try to make that as clear a process as you can.

Emails and cover letters

Friendly but professional. We’re talking about web roles here, you’re not applying for a job as a lawyer or an accountant. A friendly, polite, clear, concise—and professional—email about you, your skills and why you’re interested in the job go a long way.

The CV

Some people say CV’s don’t matter, especially for a web designer. I disagree. I’d rather follow links to your most important work from a CV than trying to figure out how the navigation on your site works.

Details on what your role was on each project are highly useful—if you’re called in for an interview, you’ll be asked that anyway.

Try to make the CV as short as possible, but let it be representative of your career so far and/or your accomplishments.

I would recommend you don’t forget to mention the following:

• Name, contact (email, city, phone number)
• Short blurb summarising your competences and what you’re looking for in a job
• Link to online portfolio (if you have one…)
• Perhaps a LinkedIn profile link (for example, you may have recommendations there)
• Education info (I don’t need to see your primary school though)
• Your skills (use known keywords here, and point out whether you’re an expert at something or only know it at a basic level), languages you speak, etc.
• Employment history with description for each role, links to projects you were involved in (make this relevant to the position you’re applying to)
• Published work, or link to your blog
• Other accomplishments such as any relevant awards, or speaking you’ve done

If you want to you can add references or recommendations, although not necessary and this may make your CV too long.

Links are indispensable if the sites are online somewhere (even if just as a screen grab on a portfolio site).

Review

When making your CV, ask someone else to review it for you. If you can find someone with more experience than you (someone who’s used to looking at CV’s would be perfect), and that knows your skills, so they can remind you of any skills you might have forgotten to mention, or tell you you don’t really have a particular skill you mentioned.

If you’re applying in a language other than your own, ask someone who speaks the language to proofread it.

The last time I revamped my CV, I asked a couple of people to look at it, with different backgrounds, but from the industry, and some native English speakers. Their recommendations were invaluable and made my CV ten times better.

Writing and personal projects

Having a personal blog where you express your thoughts and ideas about what you do always gives a good impression (exceptions aside). Writing shows you are capable of expressing yourself, and writing about your work shows a level of commitment and engagement with what you do that is invaluable and usually a synonym of someone who is willing to learn and also willing to share—indispensable attributes for working in a team.

This is especially important if you are a developer, with no visual work to show on a portfolio site. I still don’t know which is the best way for a developer to showcase their work other than in a show & tell/writing scenario. Ideas are welcome, feel free to use the comment form.

A blog is a personal project, but other types of personal explorations are always a plus (apps you’ve made, research, experiments, etc.).

Your skills

By showing you’re interested and engaged (I don’t think you can be in this industry if you dread it—it’s a labour of love), that you can communicate with others, and that you are willing to learn, you will be one step ahead of most people.

If the person or team recruiting notice this, they might be open to take you in as a junior who can progress, who they can mentor and help advance in their career—even when the original idea was to hire someone for a more senior position.

Where are the good ones?

It’s extremely hard to hire good people, especially for full time positions. If you’re good and you know it, and your skills are relevant, you’ll probably get more offers than you need, even if you already have a job or are freelancing.
So what I’d like to ask, besides asking for tips on how to create a good first impression when looking for work, is where would you go to find the good ones? And how can you make sure that they’ll want to work with (or for) you?

Note: I know I’ve focussed mostly on the CV and writing/personal projects part of the story. I could have mentioned actual portfolios, or interviews, or even the importance of expanding your network (people are more likely to interview someone they know or that someone has recommended), but this post is already long as it is, and I’m not in the mood for writing another book right now.

Existing frameworks

There’s an abundance of CSS frameworks out there, from the simpler ones that only provide layout solutions to ones that include forms, typography and fluid layout modules.

From what I can tell, designers and agencies that work with frameworks on a regular basis tend to use either Blueprint CSS or 960 Grid System (often abbreviated to 960gs). Yahoo!’s YUI Grids is also a popular one. These were the three frameworks I experimented with.

Preconceptions

I had frameworks all figured out: they were for CSS authors who wanted to go with the easy solution and not create their own CSS foundations, or for those who didn’t really want to understand how CSS works — basically, anyone looking for an easy solution.

If there is one thing I dislike it is purists who aren’t open to other people’s ideas and that never change their minds. I love CSS and I can be a purist in some cases, but I also understand that not everything can be perfect and sometimes stylesheets are messy. We all aspire to create beautiful, clean code, that is semantic and valid, but when working on real projects, that keep being updated, where more than one person at different times edits the CSS, each one with their interpretation of ‘perfect’ and with their own different level of expertise and experience, efficiency usually takes precedence over the purity of the code.

But I digress. What I mean to say is that sometimes we can use the odd non-semantic class name and no puppies will die. This is what frameworks are often criticised for. Class names like ‘grid_16‘ or ‘span-8‘ are far from being ideal, but given the need for being adaptable to any kind of project, they make sense (in most cases at least).

These non-semantic class names can be paired with better ID names (like ‘class="span-8" id="aside"‘) or, when using HTML5, with semantic element names.

While I was trying these frameworks out, I asked a few questions on Twitter (mainly complaints, to be fair), and, even though this is not scientific, most people seemed to reprove the use of frameworks. I seem to remember someone even saying they are ‘useless’, and many more negative comments. Two or three people said they used them though, and were very happy about that (opinions diverged on which one).

Wireframing

I always had the idea that frameworks would be quite useful to create wireframes on the browser, so that was what I decided to replicate with Blueprint, 960gs and YUI 3 Grids, using a very simple layout.

Blueprint

The Blueprint CSS framework was created by Olav Bjørkøy and released in August 2007. It is usually considered to be the most comprehensive CSS framework, since it caters not only for grid-based layout creation but provides, and has, a solid typographic foundation, considering aspects like vertical rhythm. It also provides a reset and print stylesheet, and basic styling for forms.

The framework uses by default a 24-column layout (each column spans 30 pixels and has a right margin of 10 pixels) but you can create different layouts by using the compressor included in the files.

Using Blueprint is as easy as including a wrapper with a class of “container” surrounding the remaining blocks on the page. Depending on the width of each of the internal containers, you need to use a class of, for example, “span-24”, for a div that spans across the entire width of the page, or “span-8”, for a block that spans across 8. If the container is the last one within a particular container or column, it should also include a class of “last”. The HTML for a the layout above would look like this (I have omitted the content, of course):

<body>
	<div class="container">
	
		<div class="span-24 b">
		</div>
		
		<div class="span-6 b">
		</div>
		
		<div class="span-18 last">
		
			<div class="span-15">
		
				<div class="span-15 last b">
				</div>
				
				<div class="span-9 b">
				</div>
				
				<div class="span-6 last b">
				</div>
				
			</div>
			
			<div class="span-3 last">
			</div>
			
			<div class="span-18 last b">
			</div>
		
		</div>
	
	</div>
</body>

I’ve also added a class “b” (pardon the presentational name) to the divs that have content so that I could add a light background and some bottom margin to preview the wireframe better (we’re just doing a quick example here, so it’s OK to include this directly in the head):

.b { background:#d4d4d4; margin-bottom:10px; }

Here’s a screenshot of the completed wireframe:

This took me less than 10 minutes to make (I know it’s pretty basic though), including having a quick read through the Getting Started guides.

960gs

The 960 Grid System CSS framework was developed by Nathan Smith and was released in March 2008. This framework was developed with a strong focus on the grid; even though it provides basic typographic styles, its main purpose is to deliver a cross-browser foundation (it has full A-Grade browser support, as defined by Yahoo!) that allows for many variations of the most common grid-based layouts.

For 960gs I’m going with an even simpler layout — the main idea here is to show the differences between class naming and nesting from framework to framework.

The framework works, by default, on either a 12 or 16 column grid. We need to add a container surrounding the inner blocks with a class of “container_16” (or “container_12”); the inner containers should have classes of “grid_16”, “grid_14”, etc., depending on how many columns they span. Here is the final HTML markup for our simple layout:

<body>
	<div class="container_16">
		<div class="grid_16 b">
			Header
		</div>
		<div class="grid_4 b">
			Sidebar
		</div>
		<div class="grid_12 b">
			Main content
		</div>
		<div class="grid_16 b">
			Footer
		</div>
	</div>
</body>

And this what you should see:

As with Blueprint, there are several tools online that allow you to configure the framework to your needs. Fluid 960 Grid System is based on the original 960 Grid System, but allows for fluid and fixed layouts, and includes basic styling for elements such as navigation, tables, forms, articles and typography.

YUI 3 Grids

The YUI 3 Grids framework is part of the Yahoo! User Interface Library (YUI). The library includes JavaScript resources as well as CSS (YUI 3 CSS also incorporates reset and typography stylesheets). It works in a similar way to the other frameworks presented in this chapter, with a difference: there is no predefined width for the main container, only predefined “units” in which a container can expand within another container.

In this case, we need to add the desired width to the body element of our page, as such:

body {
  	 margin: auto;
  	 width: 960px;	
}

The “margin: auto” property will centre our content on the page. Next, as with the other frameworks, we need to include a wrapper container with the class “yui3-g”. The containers within it will take class names based on the percentage of the width they should fill (or “units”). So, for example, if the sidebar takes up one third of the total width, it should have a class of “yui3-u-1-3”, and if the main content area takes up two thirds of the total width, it should have a class of “yui3-u-2-3”. YUI comes with a set of predefined unit classes (which are listed in the framework’s website).

The final example would have the following HTML:

<body>
	<div class="yui3-g">
		<div class="yui3-u-1 b">
			Header
		</div>
		<div class="yui3-u-1-3 b">
			Sidebar
		</div>
		<div class="yui3-u-2-3 b">
			Main content
		</div>		
		<div class="yui3-u-1 b">
			Footer
		</div>
	</div>
</body>

Looking like this:

Notice that YUI doesn’t have gutters between the columns — I see that as a downside.

My favourite

For me there’s a clear winner and it’s Blueprint. The guide was clear, it provides lots of tutorials and examples from within the front page of the website, and the fact that it provides a good typographic foundation is a major advantage.

Another advantage of Blueprint is the community behind it, which is constantly creating and releasing new plugins, themes and other tools that can be used in conjunction with the basic framework.

I felt 960gs‘s logic a lot harder to understand; it took me more than 30 minutes to figure out how the framework worked and finish the layout. If I’m going to use a framework I will be doing it to save time, so I didn’t find that experience very nice. Also, contrary to Blueprint’s website, 960gs’s didn’t have a clear ‘getting started’ tutorial, so I had to look for articles outside of the site to ‘get started’. I do like the Fluid 960gs framework, but I’m not sure if there isn’t something similar for Blueprint.

Most people that I’ve talked to while doing this little experiment mentioned that they didn’t really appreciate frameworks, but the ones who did, swore by 960gs, so it might have been that I just wasn’t introduced to it the right (or simpler) way. There are beautiful websites built on top of this framework (a quick look at its website is enough proof), like the gorgeous Black Estate Vineyard:

The fact that YUI is adaptable to any width is a major plus, but the reduced amount of unit combinations made it a little uncomfortable to use, and I felt somewhat restricted as to what I could do with my layouts. If this is incorrect, I’d love it if someone would let me know, I couldn’t find a way around it easily in the getting started guide.

Conclusion

I’ve mentioned above that I believed CSS frameworks to be ‘the easy solution’. I still think that’s true, but I don’t see it as a bad thing: why spend hours creating perfectly hand-crafted CSS layouts when there are excellent foundations that we can build upon already out there? Life’s not just about coding (really) and there are better things that I can be doing with my time than creating problems for which there are solutions already.

This doesn’t mean, however, that I believe everyone should be using existing frameworks in their projects. Ideally, you’d be working with your own framework or template, adapted to your needs. It just means that I don’t think CSS frameworks should be treated like a bad thing and they can definitely be useful in some cases, or even as a base or inspiration for creating a custom framework. And I will certainly not condemn any designer or agency that uses out-of-the-box solutions, like Blueprint, because the benefits that you get from using those can surpass the downsides like verbose stylesheets and non semantic class names.

Don’t get me wrong: I thrive on a good piece of semantic HTML and CSS, and like most of you I also wanted to throw up the first time I looked at the non-semantic classes that these frameworks use. I will look at you sideways if your navigation is a paragraph rather than a list and I may unfollow you on Twitter if I know you’ve ever used class names like “redLink”. I still believe that the non-semantic class names are the least desirable feature of frameworks; ideally we shouldn’t have classes like that in our stylesheets, but I also think there are times when we need to be flexible and adapt ourselves and accept that things like this will happen.

Maybe they are a good solution for quick or low budget projects, or prototypes (although prototype code will often move on to production, so beware if you’re especially lazy, like me). I just thought this would be a good topic to discuss, and I guess I don’t mind saying that I like stuff people usually get repulsed by, so here.

My verdict: no, frameworks are not evil.

So my question is, have you ever used a framework? Do you agree that they are a great tool, or have I gone crazy? I’d love to hear your thoughts.

What is LESS?

LESS — Leaner CSS — is, in the authors’ own words, a “new version of CSS” (better yet, of writing CSS), that is then compiled into “traditional” CSS using the LESS compiler.

There are 4 main things you can do with LESS that you can’t with normal CSS:

1. Variables

You can define a variable, such as “@text-color”, and use it throughout your stylesheet. If the colour of your text changes, you only need to change it once in your CSS — where the variable is initially defined.

2. Nested selectors

With nested selectors, instead of doing this and repeating yourself:

aside h1 { font-size: 24px; }
aside h2 { font-size: 18px; }

You can have:

aside {
	h1 { font-size: 24px; }
	h2 { font-size: 18px; }
}

3. Operations

You can add, subtract, divide and multiply using operations. Here’s a quick example:

@wrappers: 600px;

aside {
    width: @wrappers / 2;
}

This is definitely not the best example, but it should be enough for you to get the point.

4. Mixins

Mixins work a lot like variables, but you can specify a whole class in one. For example:

.b-radius {
	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
	border-radius: 5px;
}

.box {
	.b-radius;
}

From these examples, I suppose you can say that LESS is actually more. (I’m sorry, I couldn’t help myself.)

This is not a “how to” guide

The official LESS documentation is very clear on how to install it. I have to admit I usually stop reading instructions whenever “Terminal” is mentioned (and I know more people do), but I guess most CSS authors will be OK with it — if not, ask for help to your nearest web dev (or email me and I’ll give you the phone number of one).

After it’s installed, you’ll have two files: the .less file — this is the file you’ll be working with — and the compiled .css file.

There’s also LESS app, that makes it easier to use LESS. And I suppose that some CMS and servers let you use LESS directly, but the point of this article is not to teach anyone how to install it — it’s to go through its good and bad points.

On to the important bit…

How LESS can make your life easier

This is a list of things that, in my opinion, make LESS worthwhile and can really simplify your CSS. These are the things that I usually miss the most when I’m not working on LESS files.

1. Variables

Surely when you are writing your CSS there are colours, measurements, etc. that you keep using over and over. For example, let’s say your brand colour is jade (very fashionable for Spring/Summer 2010). You may use it on various elements in your design, for example, the main text:

body {
    …
    color: #77b59d;
    …
}

Or the borders of your posts:

article {
    …
    border-bottom: 1px solid #77b59d;
    …
}

Or as the background of your footer:

footer {
    …
    background-color: #77b59d;
    …
}

If someone has to edit the CSS file and doesn’t know exactly which colour he or she is supposed to be using — it may even be you a few months later —, what happens is that either you’ll spend some time scanning through the document until you find the colour, you’ll use Firebug or, if you like to complicate things, use xScope or take a screenshot and use Photoshop to detect the colour.

This is silly. You’ll end up with many similar colours instead of just one. (As a note, Dreamweaver lists all the colours that a site is using — you’d be surprised at how inconsistent some CSS authors can be when applying colour.)

Another thing that may happen is when you actually want to change this colour throughout your stylesheet: you’ll have to edit every instance of it — that’s painful.

With a variable, you can have this:

@main-color: #77b59d;

body {
    …
    color: @main-color;
    …
}

article {
    …
    border-bottom: 1px solid @main-color;
    …
}

footer {
    …
    background-color: @main-color;
    …
}

Beware though: you can easily go overboard with variables. I have to confess I was inebriated in the beginning by the thought of never having to declare a colour, a padding value, etc. again, and started adding too many variables to my LESS files. It gets messy and complicated quickly. You’ll have to find a balance.

2. Accessors

If you only need to access something once, you probably don’t need a variable. If you’re pretty sure that that thing you need to access is, and will always be, directly linked to whichever thing you’re linking it to, you can use an accessor.

Let’s say you have a block with a heading and some text. You want the border of that box to always be the same colour as the heading. You can have this:

#sales {
    border-color: #ae7b2a;
}

#sales h2 {
    color: #sales['border-color']; 
}

Using accessors may be going a step too far in some cases, but in other cases it makes a lot of sense — I think they’re quite useful.

3. Mixins

One example: gradients. Let’s face it, they are an absolute pain to write. Take a look at how LESS makes it easier for you:

The mixin:

.grad-linear (@start:"", @end:"") {
    background: -webkit-gradient(linear, left top, left bottom, from(@start), to(@end));
    background: -moz-linear-gradient(-90deg,@start,@end);
}

Using the mixin in your .less file:

nav {
	.grad-linear(#b3cdcc,#718a89);
}

What your compiled .css file will show:

nav {
	background: -webkit-gradient(linear, left top, left bottom, from(#b3cdcc), to(#718a89));
	background: -moz-linear-gradient(-90deg, #b3cdcc, #718a89);
}

Mixins are great for properties that still require that we add some vendor-specific code (like border-radius) or for the latest CSS3 gradients, transitions, etc.

I have to say mixins, especially when used for gradients and border-radius, are my favourite part of LESS.

4. C-style comments

Some people prefer these to typical CSS inline comments. I’m OK with either, but if you’re using LESS, you can have either this:

/* A normal CSS comment */

Or this:

// A C-style CSS comment

5. Nesting (in some cases)

Nesting is one of those things that makes you think LESS is amazing at first. Then you start using LESS and start nesting selectors, and change your mind.

The rare instance where I think nesting is useful is with link states in simple selectors. In LESS you can have this:

a {
    :link, :visited { text-decoration:none; color:#edd273; font-weight:bold; }
    :hover, :active, :focus { color:#edd273; border-bottom:1px solid #edd273; }
}

And the output will be this:

a:link {
  text-decoration: none;
  color: #edd273;
  font-weight: bold;
}
a:visited {
  text-decoration: none;
  color: #edd273;
  font-weight: bold;
}
a:hover {
  color: #edd273;
  border-bottom: 1px solid #edd273;
}
a:active {
  color: #edd273;
  border-bottom: 1px solid #edd273;
}
a:focus {
  color: #edd273;
  border-bottom: 1px solid #edd273;
}

There’s a lot of repetition in here, I know (I’ll mention that on the next section), but it’s nice nonetheless.

How LESS can easily become a nightmare

This is a list of things that I would either avoid doing in LESS or that just don’t work the way you’d expect them to (so, annoyances).

1. Nesting (in most cases)

As I just mentioned in the previous section, nesting looks nice at first, but it doesn’t work flawlessly.

One of the things that I’ve noticed for example, is that, even though you can have this:

nav {
  ul {
    li a {
      :link { color: red; }
    }
  }
}

This won’t work (notice that now I’m using a direct child selector instead):

nav {
  ul {
    li > a {
      :link { color: red; }
    }
  }
}

For this last bit of CSS to work, you’ll have to do it like this (notice the extra “&”):

nav {
  ul {
    li > a {
      &:link { color: red; }
    }
  }
}

This not a problem with LESS, I guess it’s just not a very intuitive way of doing it just for using a different type of selector.

The main thing, however, that I think makes nesting a poor choice in most cases, is how it can make a mess out of specificity [here's a post I've written previously on specificity and other matters].

Your first instinct is to nest everything inside the main blocks, like aside, #sidebar, #news, etc. But then you realise you need to reutilise a piece of the CSS for another area on the site. You make another nested selector for that new block, because you don’t want to go over that first nested block of CSS that you created in the first place. You’ll be left out with numerous redundant selectors, with very long selectors (because you don’t notice this until the compiler phase), and with the need to create overly specific selectors to override your initial ones (that shouldn’t have been so specific to begin with).

Nesting selectors is one of those cases where the phrase “with great power comes great responsibility” makes a lot of sense. Use it wisely and carefully.

2. Changes made to the compiled file

This isn’t a problem with LESS per se, but rather with your working process.

Even if you are the only person in charge of the CSS on a given project, it’s possible that someday you will leave, or hand the project over to someone else, so it’s a good thing to make sure that no-one is going to edit the compiled .css file directly instead of the .less one.

If this happens, and then after a while someone does use the .less file, when it compiles, it will override the changes made to the .css file. Then you’ll have to go back and fix it.

This is just a general problem with people: if there’s a chance that we can make a mistake, we will make it.

3. Formatting

The .css file that results from the compiler gives you back your CSS with no comments and single-line declarations (that have more than one property). It would be useful if you could have some control over this. For example, you may want to minify the CSS (although you could argue that this should be a completely separate step), keep comments in, have multi-line CSS, group selectors, etc.

I’m not entirely sure if this has been resolved, so if someone knows better, do let me know.

4. Using Firebug

I can’t work without Firebug, and one of the best things about it is knowing exactly which line you’re looking at. If you’re using LESS, that’s broken: Firebug shows you the line of the compiled .css file, not the original .less file you’re editing, which is basically useless.

Conclusion

I love LESS and I think it’s a pleasure to use, until you start trying to be too clever and things start getting messy. My advice is to use it with care, take advantage of its niceties but don’t go overboard.

I know there are lot more problems (and probably good things too) that I haven’t referred. These are the ones that I’ve personally came across with; I try not to use LESS on larger projects and I usually don’t use @import on my stylesheets (especially smaller projects) — which I know can cause some problems.

I’d love to know what your thoughts are on this: have you used it? Why, or why not? Which problems have you encountered? Do you find it helpful or just plain silly?

What is the book about?

The book provides the reader with a foundation in how to markup and style a web site — the right way. In the authors’ own words this book is “a well-grounded, web standards-based approach in one package“.

Starting from the beginning, it explains the importance of solid, structured markup and of analysing a web site’s content before diving into the coding phase. It introduces the most important HTML tags and how to properly use them.

Following the HTML section of the book — which takes almost half of it — it dives into the CSS bit. Here it explains how to use CSS in a clean and effective way — just the way I like it :)

One of the most important aspects of this book is how it encourages the reader to continue to learn and explore — there is a very clear message that you can’t possibly learn everything from one book. It provides several paths in which the reader can further his or her knowledge and evolve as a web designer.

Who is the book for?

As I’ve mentioned above, the book is targeted at beginners — it doesn’t assume you know anything about HTML or CSS so everything is explained in a very clear and practical way.

I suppose it’s hard to assess whether the information would be easy to understand by an absolute beginner since I’m not one anymore (or at least I like to think I’m not). But every step of the book is so carefully explained, that I doubt anyone would have any problems.

Like Sam Brown mentioned in the title of his review, “Web designers who can’t code, need to read this book”. I couldn’t agree more.

A minor remark

The only thing I would have changed, or better yet, added to the book would be a more detailed section on inheritance. This is, however, probably due to the fact that I just wrote a massive post about it and all that information is fresh in my memory.

Inheritance is a fairly complicated topic and would probably not be relevant for this book; it’s one of the things that people can easily research on their own when any issues arise.

Conclusion

Reading this book felt like I was at the web design school I never had the change to attend. It is truly a course in a book: it explains the basics that every web designer should know — whether a coder or not.

The completed website that it provides the reader with at the end is invaluable, and I am not ashamed to admit that, even though I’m not within the book’s target audience, I’ve learned a few things I didn’t know, and remembered others I had forgotten.

I am lucky enough to know Christopher and Nicklas, the authors of this book, personally, and it was a pleasure to see that their charmingly friendly personalities show through in the writing of the book — which makes it an even more delightful read. Thoroughly recommended!

What does font-size-adjust do?

First, let me warn you: you will need to use Firefox to view the examples on this page properly. Yes, not Safari, Firefox!

The font-size-adjust property allows you to specify an optimal aspect ratio for when a fallback font is used; if the substitute font has a different aspect ratio than the preferred one, the text’s x-height (roughly the size of its lowercase letters) will be preserved.

Take a look at the image bellow:

Baskerville and Georgia don’t have the same aspect ratio, so when font fallback occurs (if Baskerville is the optimal font), the text usually looks much bigger even at the same size.

By using font-size-adjust, the original font-size for the fallback fonts will be divided by the font-size-adjust value.

Do not confuse font-size-adjust with -webkit-text-size-adjust, which is used to specify the size adjustment of text on the iPhone.

How to determine the correct font-size-adjust value

The example on the W3C specification is very clear:

Authors can calculate the aspect value for a given font by comparing spans with the same content but different font-size-adjust properties. If the same font-size is used, the spans will match when the font-size-adjust value is accurate for the given font.

I’m going to basically repeat its example here.

Let’s take a look at the following code, in which we have a paragraph with two spans.

The CSS:

p { font-family:Times New Roman; font-size:400px; }
			
span { border:solid 1px red; }
			
.adjust { font-size-adjust:0.5; }

The HTML:

<p><span>a</span><span class="adjust">a</span></p>

Both spans inherit the font-family from its parent (the p element), but the second span has the font-size-adjust property applied to it, with a random value.

If you check the example page, look at the example on the left: the red boxes don’t match size in height — the font-size-adjust value is wrong.

[Do all the boxes on the example page have the same height? What did I say? Firefox…]

After a few experiments, I’ve arrived at the value of “0.455”. Now here’s the CSS for the second example (on the right):

The CSS:

p { font-family:Times New Roman; font-size:400px; }
			
span { border:solid 1px green; }
			
.adjust { font-size-adjust:0.455; }

If you go ahead to the example page, you will see that on the example with the green borders, both a’s bounding boxes have the same height — now we have the correct font-size-adjust value for our preferred font.

An example

Here’s a quick example I’ve created just to show this working on actual text.

The font stack consists of: Calibri, Lucida Sans and Verdana (and this is the order by which the fonts are displayed on the page).

Safari’s rendering of the page:

And Firefox’s:

As you can see, Firefox maintains the same x-height independent of which font is being used.

I’m not concerned with the text not being aligned, the purpose of this example is to show how font-size-adjust can affect the consistency of the font size and the font’s legibility.

Also, even though the first div has the correct font stack, I had to manually specify Lucida Sans and Verdana for the other divs, so you (and I) can see the difference even if we have all three fonts installed.

Last comments

I guess using this property may eventually have some negative implications on how typography is treated throughout a website, but that can be the topic for another post — the main goal here is just to showcase a quite obscure CSS3 property that may be useful in some cases.

I confess I haven’t tested it on a “real” project yet, so I’d be happy to hear your thoughts.

This is, for now, only supported by Firefox for Windows from version 1.0 and from 3.0 on all platforms. There is a bug filed for Webkit to fix this issue though.

References and further reading

• Relative sizing: the ‘font-size-adjust’ property — CSS Fonts Module Level 3
• CSS Examples: font-size-adjust — Mozilla Developer Center
• font-size-adjust — Mozilla Developer Center
• Comparison of layout engines (Cascading Style Sheets) — Wikipedia
• Some new CSS features in Firefox 3 — David Baron’s Weblog
• And another CSS fonts-related article that might interest you (by me): The Future Of CSS Typography — on Smashing Magazine

What is the :empty pseudo-class

Here is the definition taken from the W3C Selectors Level 3 specification:

The :empty pseudo-class represents an element that has no children at all.

Seems easy enough, right? That’s because it is. The :empty pseudo-class is going to target elements that are completely empty; for example, an empty paragraph:

<p></p>

Or an empty table cell:

<table>
<tr>
<td></td>
</tr>
</table>

It won’t target this paragraph though (there is a space within the p tag, therefore it isn’t empty):

<p> </p>

A practical example

So when can this selector be useful?

Image you’re styling a table and some of the data cells have no content — you can style them differently using the magic :empty pseudo-class.

Let’s take the table I’ve created for the Adding Style with CSS: A Beautiful Table article. I’m going to use the same CSS, but change the data to make it simpler (the data I’ve added makes no sense, but you get the point…). I’m also going to remove the content in a few cells, to make this example relevant.

So this is our markup:

<table>

	<caption>A simple table</caption>
    
	<thead>    
		<tr>
			<th scope="col" rowspan="2">Some headings</th>
			<th scope="col" colspan="4">More headings</th>
		</tr>
		<tr>
			<th scope="col">Great</th>
			<th scope="col">Brilliant</th>
			<th scope="col">Genius</th>
			<th scope="col">Good</th>
		</tr>        
	</thead>

	<tfoot>
		<tr>
			<th scope="row">Interesting totals</th>
			<td>155</td>
			<td>165</td>
			<td>70</td>
			<td>140</td>
		</tr>
	</tfoot>
    
	<tbody>
		<tr>
			<th scope="row">Curious</th>
			<td>5</td>
			<td>35</td>
			<td>50</td>
			<td>15</td>
		</tr>
		<tr>
			<th scope="row">Awesome</th>
			<td>75</td>
			<td>90</td>
			<td></td>
			<td>5</td>
		</tr> 
		<tr>
			<th scope="row">Fabulous</th>
			<td>30</td>
			<td></td>
			<td>20</td>
			<td>80</td>
		</tr>
		<tr>
			<th scope="row">Nice</th>
			<td>45</td>
			<td>40</td>
			<td></td>
			<td>40</td>
		</tr>
        
	</tbody>

</table>

This is what I’m going to add to the CSS:

tbody td:empty {
	background: #EFEFEF;
	}

And now the empty cells are styled differently! I don’t think this could have been much easier.

Also, if you really need to ask, this selector works on the latest versions of Firefox, Safari, Chrome and Opera. It will probably work on Internet Explorer 9, like most CSS3 selectors will. (The first person to point out the obvious, will be directed to this link. — Thanks, Jack, for helping me remember the link!)

Here’s the example:

View example

So, will you be using this selector any time soon?