Code Crafting Blueprints

Make CSS fun again with SASS!

olkarls — Thu, 19 Apr 2012 14:36:44 -0400

CSS is powerful, with few changes you can make your website look completely different. You can easily separate design from markup and create amazing designs. Although CSS is simple I used to have a hard time structuring my documents and I often ended up with lots of duplicated rules. That ended when I found SASS, which in my opinion is the biggest revolution of web development ever.

So, what is SASS?

Sass stands for “Syntactically Awesome Stylesheets” and comes in two flavors. SASS, the original format with indented syntax and SCSS which is CSS compatible. Since I’m an old school user I’ll focus on the SASS format in this article.

This quote comes from the official site and describes the purpose well:

Sass is a meta-language on top of CSS that’s used to describe the style of a document cleanly and structurally, with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable stylesheets.

Nice huh, but why would you use it?

Before I’ll show some examples I really hope to sell this so you so here are some benefits:

I’ve saved hundreds and hundreds of hours in the 3 - 4 years that I’ve used SASS.
I have never used the find and replace function in a CSS file since then.
I have never scrolled down a 10000 lines long file trying to find a specific rule.

import files

In SASS a file named style.sass would be compiled to a file called style.css. If you prepend the filename with an underscore the file won’t be compiled at all and you can include it within another file. This makes is easy to keep a logic structure of rules, for example:

@import 'reset'

@media only screen and (min-width: 768px)
  @import 'tablet'

@media only screen and (max-width: 480px)
  @import 'mobile'

The file above is named style.sass and includes all the rules in the file called _reset.sass. As mentioned before SASS uses syntactical whitespace and nesting so the rules within the file called _tablet.sass would only be applied inside the first media query. Sass will compile style.sass into a single file but you can structure the rules in as many files that you want.

Variables

You can use even use variables to define rules. This was the feature i missed the most while I was hacking CSS. Define colors, margins, paddings or anything else you want to be able to easily change.

$link_color: #007bc0

a:link, a:visted
  color: #{$link_color}

You can even perform calculations:

$link_hover_color: $link_color - #111

a:hover, a:active
  color: #{$link_hover_color}

This makes it very easy to change colors

Mixins

Mixins is a really powerful feature of SASS which makes it possible to reuse blocks of rules on any given selector. Are your tired of retyping the same vendor prefixes over and over again? I sure was. Check out this example:

@mixin border_radius($top, $right: '', $bottom: '', $left: '')
  @if $right == ''
    -moz-border-radius: #{$top}px #{$top}px #{$top}px #{$top}px
    -webkit-border-radius: #{$top}px #{$top}px #{$top}px #{$top}px
    border-radius: #{$top}px #{$top}px #{$top}px #{$top}px
  @else
    -moz-border-radius: #{$top}px #{$right}px #{$bottom}px #{$left}px
    -webkit-border-radius: #{$top}px #{$right}px #{$bottom}px #{$left}px
    border-radius: #{$top}px #{$right}px #{$bottom}px #{$left}px

This mixin defines a set of rules for any element. Use it like this:

#call-to-action
  @include border_radius(10px)

If you want different radius for different corners, then just add more arguments:

#call-to-action
  @include border_radius(10px, 4px, 16px, 12px)

Mixins makes it fun to try out new features of CSS since you can generate all the vendor prefixes dynamically, but it doesn’t stop there. Imagine the relief of removing all the duplication in a bloated CSS file.

Other resources

SASS’ official site
SASS source code on Github
Compass a framework built upon sass.

Conclusion

I hope I’m a good enough writer to make you see how powerful this is. As stated before this saves a lot of time and makes CSS fun.

Happy SASSing!

Written by: Ola Karlsson

Better Inputs with HTML5

svennerberg — Thu, 12 Apr 2012 04:09:00 -0400

Form elements are the backbone of all web applications. It’s through these that we’re able to collect input from our users. Up until recently we’ve had to live with a pretty limited set of form elements and it’s quite remarkable what we’ve been able to do with them.

We’ve essentialy been stuck with 4 types of elements:

Input
Textarea
Select
Button

Of these 4 elements the most versitile is the <input> element. Depending on its type attribute it can serve in several different shapes such as a text field, a checkbox, a submit button, etc.

Sure it’s versitile but there are still plenty of cases where we could really use better ones.

New Input Types

With the advent of HTML5 we suddenly have a lot of new, improved, input types at our disposal. Some of them still have such scarse browser adoption that they’re not a good option yet. But there are several that we can use right away to enhance the User Experience and they even degrade gracefully for older browsers.

Enhancing your inputs - HTML5 Style

Improved Email Field

Our first candidate is email. Think about how often you enter your email into fields on various web sites. Then think about how awkward it is to do that on your smart phone when you have to switch mode on the keyboard to access the @-key.

Luckily it’s easy to enhance that input with the new input type called, you probably guessed… That’s right: email.

<input type="email" name="email-address" id="email-address />

It might not come as a big suprise that those who benefits most from this input type are smart phone users. What it does for those is to automatically display the email specific keyboard which has the @-key already visible.

Another benefit is that the first letter doesn’t default to being upper case as it is on inputs of type text in iOS. This is really great because most of us normally wouldn’t write our email-addresses starting with a capital letter. At least for me, that just looks plain weird.

The Email enhanced keyboard in iOS

As an extra perk, this input type also triggers some rudimantary email validation on submit in some browsers. Here’s how it looks in Google Chrome.

The validation message is in Swedish but says: “Enter a Email address”

If you want to prevent the browser from performing this validation you can add the attribute formnovalidate to the submit button.

<input type="submit" value="Send" formnovalidate />

Better URL input

A related input type to email is url. It works the exact same way, including validation, but brings up the url enhanced keyboard on smart phones.

<input type="url" name="your-url" />

The URL enhanced keyboard in iOS

A better search form

Another new input type is search. What this does exactly is a bit unclear, and the W3C specification is very vauge on how it should behave but it potentially bare a lot of promise.

One trait seems to be that it gets a different style in some browsers. A style with rounded corners.

In Google Chrome it gets a small x on the right hand side, which you can click to delete the inputed text. It also displays a dropdown with recent searches.

The Search Input in Google Chrome

The special styling in Webkit browsers (Chrome and Safari) can make custom styling of the input really hard. Fortunately you can disable this styling with this CSS rule.

-webkit-appearance: none;

It reverts the search input to look like an ordinary text input and you are yet again free to style it in any way your heart desires.

Check out The search Type for a more in-depth view on what this input type does in different browsers.

Entering phone numbers have never been easier

Entering phone numbers on a phone and not having access to the special numpad that’s built into the phone is plain dumb! There’s a reason that the numpad is designed the way it is - it makes it easier to dial numbers, duh!

So do your mobile users a favor and make sure that whenever you want them to enter phone numbers, use the input type tel.

<input type="tel" name="phone-number" />

This brings up the thumb-friendly keypad. At least in iOS.

The telephone numpad in iOS

Crunching numbers in style

Quite often, at least in web applications, you need the user to enter numbers. And guess what! There’s a special input type for that too. It’s called number and it brings up the keyboard in number mode on smart phones.

<input type="number" name="magic-number" />

The iOS keyboard in number mode

Sure it’s nice to have the keyboard with the numbers already showing. After all it saves you one keypress to switch to this mode. But didn’t we have an even better numpad that we could use - at least for integers?

Sure you could use the tel type. But unless it really is a phone number you want them to enter that’s not really appropriate.

But there is actually another way to elicit the numpad, at least on Mobile Safari.

There’s a new attribute in HTML5 called pattern. It takes a regular expression as its value that determines what a valid input is. If you enter [0-9]* it will tell the browser that only numbers are valid entries in this particular input and that will also make Mobile Safari bring up the numpad.

<input type="number" name="magic-number" pattern="[0-9]*" />

(Kudos to David Goss for this neat little trick)

But what about desktop browsers? Well in some browsers, specifically Chrome, Safari and Opera, the numeric input type will render as a spinner. You can either click the small arrows to increase or decrease the value. Or you can use the arrow keys on the keyboard to do the same.

The number input in Google Chrome

Can I use these now?

Yes, you can! The beauty of all these new input types is that if a browser doesn’t support them, it will just revert to a common, plain, vanilla text box. And no harm is done.

This is really good because it means that using these input types are totally safe. And I’m sure that especially your mobile users will thank you for it.

References

Books

HTML5 for Web Designers by Jeremy Keith (You can also read it online)

INTRODUCING HTML5 by Bruce Lawson and Remy Sharp

Online

The Current State of HTML5 Forms

Written by: Gabriel Svennerberg

How to keep yourself and your customer happy

olkarls — Thu, 05 Apr 2012 11:58:00 -0400

The phone rings and an excited voice is heard on the other side of the line. I’ve got this amazing idea! It’s a totally untapped market and I already have the investors lined up waiting to pay up. Can you build this service and I’ll pay you later or maybe you rather have some of the stocks?

$elling your time

There are three different types of projects that I often stumble upon. It could be clear, unclear or a complete mess. The strategies differ depending on how well the project is defined:

If the project is well specified, has a clear goal and no loose threads then go for a fixed price but be sure to specify what’s included.
If it’s unclear, make the customer specify the missing parts. Help them by asking many questions and charge for the time spent.
If the project is nothing more than an idea without substance then maybe you can help them write the specification and charge for it. Don’t give a fixed price because this could take time.

Don’t forget to get the customers signature on the specification. This makes the project real for both you and the customer.

If you use a fixed rate and it’s a big project send a partial invoice at the start.

Planning

Before you launch your editor, itching to start coding, you have to plan the project. This is where most time is saved, it is not by using the newest and coolest ruby gems out there.

Try to break up the project in small well defined units with a clear goal. This could be something like: list products, user registration or search. Make them so small that you could finish the whole part within days.

Roll up your sleeves and start coding…not yet

There is one more important thing to do before you can do any real work. And that is hosting.

No matter how big or small the project is, make sure you have somewhere to host it. You should publish new releases often, several times a day actually.

The customer must be able to see the progress you’re making. This pushes the project forward and keep both parts motivated. It also makes you confident that the code works “for real”.

Coding

If you’ve done the planning right this is a no-brainer. Just do what you must to get the parts finished. If you encounter some problems make sure to let the customer know about it.

Conclusion

The key to a profitable, fun and stable project is planning. Planning might not be the sexiest part of the project but it sure is the stage where you save the most time.

It’s important to get payed but it’s even more important to over deliver. Remember your last project should always be your best.

Written by: Ola Karlsson

Make Click Areas Comfortably Large

svennerberg — Thu, 29 Mar 2012 02:03:00 -0400

Have you ever been browsing a web site on your smart phone or tablet and found that on some sites, the links are so tiny and so tightly packed, that it’s near impossible to click the right one?

I have definitely been there and it’s equally frustrating each time. As the use of smart phones and tablets increases, so does the importance of having big enough target areas to interact with. But it’s not only important for mobile browsing. The truth is that it benefits desktop users as well.

Fitts’s Law

Fitts’s Law is a classic rule of thumb in Usability. The law can be expressed in a fairly complex mathematical way but in a nutshell it states that the larger and closer a target is, the easier and faster it is to click it.

It’s not exactly Rocket Science, but still it highlights the importance of having, not only big enough targets, but also to position them intelligently.

If you want to know more about Fitts’s Law there’s an excellent explanation over at Particle Tree.

Designing for Touch

For touch devices, such as smart phones and tablets, a big enough touch target is even more important than on desktop. While a mouse pointer is a precision instrument with a click area of just 1 x 1 pixel, a human finger is more of a sledge hammer. The avarage size of the pad of a human index finger is 1.6 to 2 cm which translates to about 45-57 pixels on a screen.

You’ve probably experienced the frustration yourself when trying to click small links that are tightly packed on a smart phone. It can be really hard to hit the right target and that’s not the experience you want people to have with your web site.

Image credit: sochacki.info

Recommended touch target sizes

Apple iOS Human Interface Guidelines state that a touch target should be at least 44 x 44 points large. (The reason they’re using points instead of pixels is that points can be used for both standard and retina displays).

Microsoft’s Windows Phone UI Design and Interaction Guide suggest that the size of the touch target should be 34 pixels with an absolute minimum of 26 pixels and Nokia’s Developer Guidelines state that the touch target should be at least 1 x 1 cm.

I actually I think that Nokia has the best guidelines since it states its minimum dimensions in cm. I mean 44 pixels can be very different on different screens and devices.

What you don’t have in size you can make up in space

Another interesting aspect of this is that if you absolutely do need to have relatively small touch targets you can partly compensate that by increasing the space between the targets. By doing that you limit the chance of missed targets.

The rule is: The smaller the target, the bigger the gap.

In Practice

Enough already, I think you get why it’s important to have big enough click/touch targets. The question is, how is it done in practice?

The first thing to recognize is that the clickable area could be well outside the visible area of the object.

Regular links

For links in a list, the easiest way is to increase the padding. Instead of having a padding on the list-item you should have it on the link itself. In this example I simply add a 10 pixel padding to a link. Watch how that dramatically increases its clickable area (The faint red background indicates the clickable area).

li a {
  padding: 10px;
}

Checkboxes and Radiobuttons

For checkboxes and radiobuttons, which often are really small, the trick is to put them inside a label and add a generous padding to them. By connecting the checkbox and the label via the id and the for attributes, the entire area of the label toggles the checkbox.

HTML

<label for="foo">
   <input type="checkbox" name="foo" id="foo" value="bar" />
  A padded checkbox
<label>

CSS

label {
  display: block
  padding: 10px;
}

In this case the padded click area is over 50 times larger than the checkbox.

Of course there are other elements that this could be applied to as well but these two examples should be enough to give you an idea of how to go about it.

References

Online

Finger-Friendly Design: Ideal Mobile Touchscreen Target Sizes

Touch Target Sizes

The Definitive Guide To Styling Web Links

Written by: Gabriel Svennerberg

"It is far better to adapt the technology to the user than to force the user to adapt to the..."

svennerberg — Tue, 27 Mar 2012 06:49:22 -0400

“It is far better to adapt the technology to the user than to force the user to adapt to the technology.”

- Larry Marine

What to do when all else fails?

olkarls — Thu, 22 Mar 2012 15:57:00 -0400

So your brand new project is finally live. It’s looking great, your customer is happy and users are starting to pour in. Just when you’re about to start up the next project your customer calls you and says that something might be wrong, it’s no biggie but check when you can. You put it on your todo list and continue to work on the other project.

When your about to go home the customer calls again. He is not as relaxed this time. The application is clearly not working as expected and he needs you to fix this asap. It looks like you don’t need to make plans for tomorrow.

As you wake up the day after from your iPhone’s email notification alarms and constant vibrations, you remember, this will be a busy day.

It can be hard to keep the cool as bug reports floods your inbox and the client calls every minute with weird questions and even more weird “solutions”.

This is clearly an exaggeration but it can sometimes be very hard to spot and crush that bug, so where to start?

My suggestion would be to start to look at external parts of your app, that could be cron jobs, services or anything else that isn’t trigged by a web request. I often find that these are the weakest link of the system. These things can easily hangup and even die.

If you have a chained dependency, meaning one script must be done before the other should run. Then make sure that there is enough time for the first one to finish. Could it be that as the data grows the script takes longer time to finish? A better and more scalable solution would be that the first script calls the second one when it’s done.

Make a dump of your production database and import the data on your local machine. Does it look right, is there a null value where you don’t expect it to be?

The next step would be to debug your application. Logging is your best friend here. Try to set up some global error handling mechanism to log all exceptions that are thrown. Include all parameters sent to the app in the log message.

Define a test case based on the parameters of the failing request and continuously hit the app with those parameters and try to recreate the issue. If you succeed you’re probably close to a solution.

Take breaks! I know, there is nothing more frustrating than leave a problem unsolved but the fact is that your mind is constantly working on the issue even if your doing something else. I have sometimes solved nasty bugs within minutes after just ignoring the problem for awhile.

Keep up the spirit and good hunting.

Written by: Ola Karlsson

Make Clickable Things Look Clickable

svennerberg — Thu, 15 Mar 2012 11:08:00 -0400

This is really a no-brainer but nevertheless important, and actually something a lot of sites get wrong.

Imagine that you have an affiliate site for the travel industry. You write beautiful articles which vividly describes exotic places where people could spend their holidays. Sprinkled in the text you have affiliate links to traveling agencies, which in case you didn’t know, have pretty decent kick-backs on refered customers that leads to a sale.

Now, the sole purpose of that article is to make people click those links. After all, that’s how you make money of the site. One thing you should definitely do is to make sure that people notices them. Because if the contrast between the links and the body text is to low, it doesn’t matter how eloquently you describe the destination. If they can’t see ‘em, they won’t click ‘em.

This might sound like common sense but you would be surprised to know how many sites that get this wrong. Often I think, for aesthetic reasons.

What to do about it

You don’t have to take it as far as usability guru Jakob Nielsen who infamously claimed that links should be blue and underlined (which they are on his site useit.com by the way). I don’t want to take it that far but do make sure that your links stand out from the rest of the text.

Your safest bet is probably to have them underlined. It carries a really strong affordance for clickability (check the Fast Facts Section for more on affordance). But you could also have them in a different color, a different background color and/or styled in some other way. Just make sure that they stand out from the rest of the text.

Don’t forget that as much as 8% [kolla fakta] of all men are color blind so having something more than just the color to distinguish links is a good idea.

Not just text links

The same thinking goes for other things that are clickable such as buttons, checkboxes, select lists, images etc. etc. Make sure that they actually look clickable.

For buttons that can mean to look like physical buttons with a 3d effect making them stand out from the page and look more like physical objects.

The button on the left could just as well be a banner or a header, while the button on the right is begging to be clicked.

Provide clues

Also make sure to provide other clues such as the cursor changes to a pointing hand and that something happens with the object when it’s being hovered. This is easily achieved with the :hover pseudoclass in the CSS.

.clickable-item:hover { 
    cursor: pointer; 
    background-color: #ff9; 
}

Don’t forget to design for touch

On touch devices there are no such things as a hover. It’s therfor extra important to make clickable objects look clickable.

Fast Facts

Affordance

The term Affordance was popularized by Donald Norman in his seminal book The Psychology of Everyday Things. He later changed the term to Percieved Affordance since too many misunderstood what he meant by it. (Actually his latest term for this is Signifiers but that term hasn’t gained much traction yet)

Percieved Affordance means what properties of an object we can learn by just looking at it. For example a door knob communicates with its shape that it can be grabbed and turned. In a similar way we can by just looking at a pair of scissors see that the shape of the two “holes” looks like somewhere you can put your thumb and your hand.

The door knob affords grabbing and turning and the pair of scissors affords sticking your hands in the holes. In the same way a underlined link and a raised button affords clicking (or touching).

References

Online

Guidelines for Visulizing Links

Don Norman on Affordance

Written by: Gabriel Svennerberg

Why Still Sooo Slow? An Introduction to Database Indexes

olkarls — Thu, 08 Mar 2012 15:46:00 -0500

So you’ve already implemented these frontend performance tricks, right? I hope it made a huge difference, but what to do if your site still feels sluggish and slow? How about buying a new expensive dedicated server and add hardware every year or so? That might be necessary but there is a lot you can do on the data layer and this article will give you an introduction to database indexes.

What is a database index anyways?

Simply put it’s a table of contents just like the ones in books. It holds information about where the data is stored which helps the database to find it faster.

Every time a row gets inserted, updated or deleted the index needs to be updated and this will slow down the write process. But at the same time increase the read speed.

Benchmark

I’ve created a database with a single table called users with the following fields:

first_name, varchar
last_name, varchar
email, varchar
company_id, int

I then filled the table with 100000 rows and ran the following query 100 times:

SELECT u.first_name, u.last_name, u.email FROM users u where company_id = 100094

4.299390 seconds later the benchmark was done. Do you think an index will decrease the time spent running the test? Let’s try.

I added an index to the company_id field and ran the same benchmark again and guess what, it only took 0.010680. That’s an 40256% speed increase, if my math is correct :).

As you can see from this trivial example there is a lot you can do on the data layer to increase performance. There is of course more to cover on database indexes and here are some good resources:

If your interested in how to run similar tests then grab a copy of the mysql benchmark script and play around.

Written by: Ola Karlsson

The Proper Way to Include CSS

svennerberg — Thu, 01 Mar 2012 18:34:47 -0500

You already know that the CSS should be separated from the HTML not to violate the separation of concerns. You probably also know that it should be inserted in the <head> part of the page. But what is the best way to include it? There is after all two ways of doing it.

Via <link>
Via @import

At first glance it might seem that it wouldn’t matter, but as it turns out it does. In fact it does matter a lot!

Using @import to include CSS can cause a blank white screen, just like if you would have inserted the CSS at the bottom of the page.

It does this becuase CSS inserted via @import is always downloaded last. Since the browser won’t render anything until it loaded all the CSS, the page is completely blank until the CSS has finally downloaded.

But why does the browser wait until all the CSS is loaded? Because it’s lazy! It doesn’t want to risk having to rerender the content, something it have to do if the CSS will alter the styling (which it probably will).

Actual Performance vs Percieved Performance

It’s important to understand that this behavior doesn’t affect the actual performance of the page. In fact in some cases the actual performance is faster. What it does affect is the percieved performance.

With the CSS being loaded first, the browser will render the content of the page as it’s being downloaded. This is called Progressive rendering and it gives the user the impression that the page is loading faster.

The rule

What it boiles down to is this:

Always use <link> in the <head> of the document to include CSS.

<link type="text/css" rel="stylesheet" media="screen" href="style.css" />

CSS in the <head>

References

Books

High Performance Web Sites - Essential Knowledge for Frontend Engineers by Steve Souders

Online

Don’t use @import

Bonus Fact

This best practice is taken from rule no 5 in Steve Souders excellent book High Performance Web Site. This book contains 14 rules for faster-loading pages and is a must read if you’re serious about web site performance.

Written by: Gabriel Svennerberg

OpenSearch

olkarls — Thu, 23 Feb 2012 13:54:00 -0500

Have you seen the little Google icon next to the search field in Safari and Firefox? With a few simple tricks you can have your own site listed as a dedicated search engine within these browsers. So let’s get to it.

Create a new file named opensearchdescription.xml and put in the root of your website.

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <ShortName>Web Search</ShortName>
  <Description>Use Example.com to search the Web.</Description>
  <Url type="text/html" method="get" template="/search?q={searchTerms}" />
</OpenSearchDescription>

The elements you’ll need to change is:

ShortName — Your sites name
Description — A description of your search engine
Url — The url of the search results page

And a link to the xml file inside the head tag of your webpage like this:

<link rel="search" href="http://example.com/opensearchdescription.xml" type="application/opensearchdescription+xml" title="Content Search" />

Head over to your site using Safari or Firefox and click the little icon next to the search bar and see your site listed. Click add yoursite.com to use it as a search engine. Type in a search phrase and press enter. If you have added the right url inside the Url tag in the opensearchdescription.xml file then you should be taken to your sites search result page.

The OpenSearch functionality is a bit different in Google Chrome since it has a combined search field and address bar. Start by typing yoursite.com and press tab. The bar changes and says ‘Search yoursite.com’. Fill in your search term and press enter.

This is a very easy and useful way enhance your site. There are many more options to include to your opensearchdescription.xml file such as icons and tags. I highly encurage you to read the full specification over at the offical site.

Written by: Ola Karlsson

Put scripts at the bottom

svennerberg — Thu, 16 Feb 2012 03:42:00 -0500

You’ve added your favorite JavaScript Libraries: jQuery, jQueryUI, a couple of plugins a few shims and on top of that your own js-files plus Google Analytic. When you load the page you’re surprised to see that it takes a while for something to render. In fact you realize that you’ve got the famous blank white screen.

What’s going on here you say to yourself. Duh, you’ve put all the scripts in the <head> of the document. No wonder the page takes some time to load.

But wait a minute! Isn’t the <head> Where you supposed to put the js? You know, so that all the scripts are available when the DOM has loaded. I’m sorry to break the news but the <head> is a horrible place to put scripts! Putting them there leads to two things:

Content below the script will not render until the scripts are downloaded and parsed.
Assets like images, other script files and so on are blocked from being downloaded until the scripts are ready.

There’s a couple of reasons why this is happening.

Dependencies

The first reason is that the browser wants to make sure that a script added earlier in the document is loaded properly before adding the next in line because they can have dependencies. Just like your js code is probably dependent on a js library like jQuery.

Better safe than sorry

The second reason is that normally, the browser downloads files in parallell, meaning that 2 or more files download at the same time (even more if you spread out the files across CDN’s). But when a script file is downloaded this behavior is actually disabled, effectively blocking all other downloads until the script is done.

But why, you might ask. What can possible happen? Well the browser lives by the motto: “Better safe than sorry!”. It can’t be sure that the script being downloaded won’t alter the content of the page with document.write (Something you should never do by the way). It wants to be absolutely sure that the page will render properly.

Put them at the bottom

The <head> is actually the worst place you can put your scripts. Putting them there will delay all the other content from being rendered.

The best place is therefore to put your scripts at the bottom, just before the closing <body> tag. Doing this, the CSS and the HTML can be downloaded and rendered, giving the visitor something to look at before the script blocking begins (Assuming that you’ve put your CSS at the top).

This also has the added benefit that you know that the DOM is ready when the scripts execute, removing the need to listen for a load event.

So if you haven’t done so already, go ahead and move those <script> tags to the bottom of the page for an easy and instant performance boost of your site.

References

Books

High Performance Web Sites - Essential Knowledge for Frontend Engineers by Steve Souders

High Performance JavaScript by Nicholas C. Zakas

Online

High Performance Web Sites: Rule 6 – Move Scripts to the Bottom

Written by: Gabriel Svennerberg

Speed is of the essence!

olkarls — Thu, 09 Feb 2012 12:24:00 -0500

Every asset on a webpage needs to be downloaded by the browser and that takes time. The browser is also limited to between two and six concurrent transfers, depending on which browser is used. That means that if your web page has 18 assets (images, stylesheets or javascript files), the browser starts with the first two assets and enqueues the rest. When asset number one is downloaded it opens a new transfer and starts with asset number three and so on. This is usually where you should start to optimize a slow site.

Minimize the number of http requests

Combine all your css files into one css file and all the javascript files into one javascript file. There is a really good open source build script that’ll help you do that. Check out HTML5 boilerplate’s build script.

CSS Sprites

If you are using alot of background images in your css files then you should combine all or most of them into a single file. Then use the css background-position to select the visible area of your image. There is not enough room to dive into css sprites in this article, but here is a good one that’ll help you get started.

Use a far cache expiring date

Another good way to minimize request is the tell the browser that the downloaded file won’t change for a very long time. This means that after the download is complete the file is always served from the local cache.

Setting up expiring dates is often done in your virtual host configuration and you may have to install some software depending on which web server you are using.

This is an example for Apache which has mod_expires enabled:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
    ExpiresActive On
    ExpiresDefault "access plus 1 year"
</FilesMatch>

All the files with the extension listed in the FileMatch expression will be cached one year from when the request is made.

This is the perfect solution as long as you never update any of these files again, but that might not be the case.

Expire the cache

The easiest way to expire the cache is to append a version number to all your static assets, like this: body-bg-v2.png. If need to update that file you’ll need to change it’s name to body-bg-v3.png. That can be a real pain since you’ll need to rename all your files which have changed, including the background images within your css files. Good thing you’re using css sprites, right?

As you can see, there is some hassle to set all of this up but it’s really worth it. The user will have a much better experience while visiting your site.

Written by: Ola Karlsson

Know Your Doctype

svennerberg — Thu, 02 Feb 2012 07:59:00 -0500

The doctype is the piece of code that should sit at the top of all other markup in an HTML-document. It doesn’t do a whole lot, but it does one important thing. It tells the browser which flavor of HTML you’ve choosen to use on your web page.

The doctype might look something like this…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

…at least if XHTML 1.0 is your kind of flavor.

Then why is it important to tell the browser what kind of markup to expect? Isn’t HTML just HTML?

As it turns out it’s very important to tell the browser which type of HTML to use or you might suffer from slower rendering and unexpected interpretation of your markup.

Quirky browsers

Traditionally browser have had to be very forgiving when parsing HTML. They’ve had to because back in the day, nobody knew what good HTML looked like, not even the browser manufactures who instead competed over who could come up with the craziest HTML tag. Remember the <blink> and the <marqee> tag?

It was regular wild west and people tossed together HTML tags with no regards to semantic meaning or concerns about if it was valid or not.

Even if the HTML was sloppy and contained errors, the browser would still do its best to render the page according to it. To do that it actually switches to a different mode, Quirks Mode, sometimes referred to as Compability Mode. In Quirks Mode the browser is much more forgiving and tries hard to render badly formatted HTML. The problem is that this takes a lot more CPU than rendering valid HTML, and the results are pretty unpredictable.

Avoid this by Stating the Doctype

Of course today it’s a whole different story. There are now best practices and defined standards on how to use HTML and even most browser manufactures does its best to implement the standards properly.

But it’s important to declare the proper doctype. If you omit it, the browser will automatically switch to Quirks Mode since it will assume that you don’t know what you’re doing. The result is that the page will take longer to parse and the HTML can be interpreted in unexpected ways. It will for example use Microsofts faulty box-model in IE6, which will probably mess upp your entire layout. (For a long list of examples check out the article What happens in Quirks Mode.)

What Doctype to Choose

It’s not that important which doctype you actually use. The most important thing is that you make a conscious decision about this and that you use a valid doctype.

Personally I wouldn’t go with anything else than HTML5 these days, and that has its advantages. It’s the only doctype that I can actually write from memory.

<!doctype html>

"Good design is all about making other designers feel like idiots because that idea wasn’t theirs"

olkarls — Wed, 01 Feb 2012 12:38:00 -0500

“Good design is all about making other designers feel like idiots because that idea wasn’t theirs”

- Frank Chimero

.htaccess Tricks

olkarls — Thu, 26 Jan 2012 10:37:00 -0500

This article will show you my most common .htaccess tricks. A .htaccess is a file that is placed in the root of your website and allows to override the Apache configuration.

No duplicated content

You should make your site respond to both yoursite.com and www.yoursite.com because some people still writes those wwws into the browser. This leaves one problem though. All the content is duplicated, meaning your sites content is competing with it self.

In the time of sharing craziness where everybody hunts retweets, likes and links, the problem becomes more obvious.

If ten people links to: yoursite.com/really-great-article/ and another five links to www.yoursite.com/really-great-article/ then Google will rank those two urls individually. Since most search engines consider links to be the best ranking factor you need to get all the links you can and be sure that they are pointing to the correct location.

.htaccess to the rescue

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^YOURSITE\.COM$ [NC]
RewriteRule ^(.*)$ http://YOURSITE.COM/$1 [R=301,L]

That .htaccess rule will permanently redirect everything that doesn’t begin with YOURSITE.COM to YOURSITE.COM. So if I linked to www.yoursite.com/really-great-article/ the visitor and the search engines who follows that link will end up on yoursite.com/really-great-article/ instead.

Google follow these redirects and understand that the url has moved to the other location.

So go ahead and add that rule to every site you own now.

Static site fixes

The following examples is a little more specific. I mostly use Ruby on Rails when I’m lashing out web apps but sometimes I use Frank. That’s an excellent Ruby framework for generating static html sites. Then the following examples comes in handy.

What if the actual url in the example above is yoursite.com/really-great-article/index.html. Then you need to remove the filename. Fortunatly that’s easy:

RewriteCond %{THE_REQUEST} /index\.(html|php) [NC]
RewriteRule ^(.*/)?index\.(html|php)$ /$1 [R=301,L]

Every url containing either index.html or index.php will be redirected to the folder it’s contained within. If you’re using other extensions then that just add them between the paranteses.

FourOohFour

If the document can’t be found Apache shows a generic default page that is pretty cruel to you grafical profile and it wont show your navigation, so the user is stuck. It’s also important to understand where your visitors are coming from and you should add a tracking code everywhere, even to your 404 pages.

Just create a file called 404.html in the root of you website and add the following rule to the .htaccess file.

ErrorDocument 404 /404.html

This is just a small introduction and I’ve only just scratched the surface. If you thirst after more .htacess tricks point your browser to the offical site to learn more.

Written by: Ola Karlsson

CSS in the Head

svennerberg — Thu, 19 Jan 2012 09:27:22 -0500

When optimizing a page you’re obviously thinking about where to add different assets on it. Stuff that is needed up front is placed at the top and stuff that is needed later can be placed further down. After all, we want the page to show something as fast as possible!

The percieved performance in this case is the most important factor. We therefore want the page to load progressively, meaning: The page renders from top to bottom as content is being downloaded.

Lets say you’re building an image gallery to show off your fabolous collection of Ninja Toasters(!?). When the user clicks a toaster a lightbox will open and display a bigger image of the toaster.

Now, the CSS for the lightbox isn’t needed for rendering the page. It’s actually not needed until the user clicks an image. Therefore we could include it at the bottom of the page to let other content load first right. You know so that the page will render faster? Wrong! Contrary to common sense it will actually delay the rendering of the page in a lot of web browsers.

But why does it delay the rendering? Keeping the browser from downloading it before other content ought to make the rendering faster. This is really counter intuitive at first glance, but listen to this:

The browser doesn’t want to risk having to re-render the page, it therefore waits until all CSS is loaded before rendering anything!

Fortunally there’s a really simple solution to this, just follow this simple rule: Include all CSS in the <head> of the page.

References

Books

High Performance Web Sites - Essential Knowledge for Frontend Engineers by Steve Souders

Online

Best Practices for Speeding Up Your Web Site

Written by: Gabriel Svennerberg

"Learn the rules so you know how to break them properly."

svennerberg — Fri, 13 Jan 2012 03:05:04 -0500

“Learn the rules so you know how to break them properly.”

- Dalai Lama

Never Allow Access to Destructive Actions Through a GET Request

olkarls — Thu, 12 Jan 2012 15:30:00 -0500

You’ve worked hard for a long time but finally your web application is ready and you’re eager to roll it out. Your site has an administration area where you can handle all the data your site contains.

The user section of the administraion area contains links like this: <a href="http://yoursite.com/delete_user?id=123">Delete user</a>.

If an authenticated administrator would click that link it would delete the user with id 123. This is fine right? We know that the user is logged in and the only way to access the link is through the administration section of the application. Wrong! This is a very insecure way to handle destructive actions.

There’s a lot of people out there with the sole purpose to hack or destroy your site and you should never leave anything to the slump.

What if I’m an evil hacker and I send an email to someone who handles your sites administration containing this code <a href="http://yoursite.com/delete_user?id=123">Checkout this really funny clip</a>. Ok, I know, you need to trust people not to click everything clickable right?

Well, then consider this:

I post on a forum where I know the adminstator hangs out, containing this image tag <img src="http://yoursite.com/delete_user?id=123" alt="The Cutest Kitten in the Universe" />. The second the administrator opens that url; the user is gone.

Urls are also easy to mask, either via a redirect rule in a .htaccess file or simply by creating a server side script. Then it’s impossible to see where the link goes while hovering it.

The point I’m trying to make is that a GET request doesn’t care which element it’s included in. If a requests is sent the request is sent.

So, How to solve this mess?

Never allow any GET request to handle data modifications. It really is that simple. You should also demand some sort of confirmation before deleting stuff because everybody can make a mistake right?

According to the specifications GET should be used for retrieve information.

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.

RFC2616 (HTTP 1.1) reference

Written by: Ola Karlsson

Separation of Concerns

svennerberg — Thu, 12 Jan 2012 14:31:00 -0500

Have you ever found yourself in a situation where you have a site where the HTML, the CSS and the JavaScript are all tangled together and it becomes a nightmare to make even the tiniest site-wide change?

What you’ve experienced is what is commonly referred to as Spaghetti code. To avoid falling into this trap you should follow one simple rule:

Always separate HTML, CSS and JavaScript into different files.

Remember that HTML is for content (and structure), CSS is for design and JavaScript is for behavior. By separating them into different layers you gain several things. It becomes:

Easier to maintain
Increased performance
Better accessibility
A good foundation for SEO

Maintainability

First of all, your code becomes more maintainable. If there’s something wrong with the design, it’s probably in the CSS. If on the hand your super cool drag and drop interface stops working, something is probably wrong in the JavaScript files. In other words, it’s easier to find errors.

Imagine wanting to change the entire design of your site to a ninja unicorn theme (shudder). Having your HTML, CSS and JavaScript in a big mess you basically need to rewrite the whole site. But if you been a good coder and kept them separated, all you need to do is to change the CSS. Simple, right?

Performance

In most cases the site loads faster if you have the layers separated. And we all know how important speed is!

JavaScript and CSS files are static assets that can be effectively cached by the browser. What it means is that the browser doesn’t have to download them more than once. You save both bandwidth and rendering time.

Accessibility

By separating the different layers you also benefit the accessibility of the site. It’s in fact the foundation of Progressive Enhancement (and graceful degradation). This means that even if the user interact with your site using a less capable device (for example: disabled JavaScript, screen reader, old browser, you name it) it can still access the content because the device can simply ignore the parts it doesn’t support and render what it can.

HTML is the solid foundation of the web. By making sure that you keep the content there (semantically marked up of course) and that neither the CSS, nor the JavaScript is in its way, you can be sure that every browser on this planet can access your content.

SEO

Web crawlers, the evil robots of Search Engines that constantly crawles the web on their endless hunt for content to index, is another reason you want to separate the layers. A web crawler is basically a blind user. It doesn’t care about your fancy styles or your crazy JavaScript animations. All it cares about is your content - your HTML.

So you better make sure that your content is semantically marked up with valid HTML and that the CSS and JavaScript is out of its way. Having done this, you’re on your merry way towards SEO nirvana.

A Bad Example (Warning Anti Pattern!)

In this example, the separation of concerns is violated. Both content, style and behavior are meshed together in an awful soup.

HTML

<a href="/some/url/" onclick="someFunction(); return false;" style="font-size: 12px; color: #f00;">A bad link</a>

Good Example

In this good example the same thing is done with a clear separation between content, style and behavior.

HTML

<a href="/some/url/" id="some_link">A good link</a>

CSS

#some_link { font-size: 12px; color: #f00; }

JavaScript

document.getElementById('some_link').addEventListener('click', someFunction, false);

Conclusion

I hope that this article have convinced you that keeping a clear separation is the way to go. So save yourself a lot of grief and separate these three levels as much as possible or you might as well end up in Spagetti Code Hell.

References

Online

The Web Standards model - HTML, CSS and JavaScript

Separation of concerns on Wikipedia

Books

DOM Scripting by Jeremy Keith, FriendsofEd 2005

Bulletproof Web Design by Dan Cederholm, New Riders 2006

Bonus Fact

The concept of Separation of Concerns is not limited to HTML, CSS and JavaScript. It applies just as much to general software development where you want to keep different things separated. For example the data, the business logic and the User Interface.

Separation of concerns on Wikipedia

Written by: Gabriel Svennerberg

Code Crafting Blueprints

Make CSS fun again with SASS!

So, what is SASS?

Nice huh, but why would you use it?

import files

Variables

Mixins

Other resources

Conclusion

Better Inputs with HTML5

New Input Types

Enhancing your inputs - HTML5 Style

Improved Email Field

Better URL input

A better search form

Entering phone numbers have never been easier

Crunching numbers in style

Can I use these now?

References

Books

Online

How to keep yourself and your customer happy

$elling your time

Planning

Roll up your sleeves and start coding…not yet

Coding

Conclusion

Make Click Areas Comfortably Large

Fitts’s Law

Designing for Touch

Recommended touch target sizes

What you don’t have in size you can make up in space

In Practice

Regular links

Checkboxes and Radiobuttons

HTML

CSS

References

Online

"It is far better to adapt the technology to the user than to force the user to adapt to the..."

What to do when all else fails?

Make Clickable Things Look Clickable

What to do about it

Not just text links

Provide clues

Don’t forget to design for touch

Fast Facts

Affordance

References

Online

Why Still Sooo Slow? An Introduction to Database Indexes

What is a database index anyways?

Benchmark

The Proper Way to Include CSS

Actual Performance vs Percieved Performance

The rule

Related

References

Books

Online

Bonus Fact

OpenSearch

Put scripts at the bottom

Dependencies

Better safe than sorry

Put them at the bottom

References

Books

Online

Speed is of the essence!

Minimize the number of http requests

CSS Sprites

Use a far cache expiring date

Expire the cache

Know Your Doctype

Quirky browsers

Avoid this by Stating the Doctype

What Doctype to Choose

Further reading

"Good design is all about making other designers feel like idiots because that idea wasn’t theirs"