Problems with my current codebase

Well, I already have a codebase, but it has some problems. The important one is that it only covers the very basics. That’s because designs can be very diverse and as a developer I want to stay true to the design. So it’s hard to build a codebase with grids and blocks if all design differ from eachother.

Another problem major issue is something I have more control over: the codebase and the documentation is a bit scattered. The last problem I have is that I have no demo page of my standard CSS code, so there’s no easy way to check the template on browser compatibilities.

Now my jQuery plugin project has reached version 1.1, I had the time to do some thinking about a new codebase that would be solid, extendable, easy to deploy and would replace all other codebases and documentation.

Let me make it clear: this article is about my considerations about building a solid framework for myself. It may not apply to you and my ideas not unique either. It still may be helpful for you to get an idea of what sort of codebase you need.

Existing examples

The most important thing about a codebase is to decide how to set it up and how to store it. I like the way open source grids like Grid960 and YUI have organized their code into little reusable bits and have created a demo and test page for each and every component.

I must admit: I hardly ever used these grids. Most of those grids talk the language of the web developer, not of the designer. And the designers I know don’t have to limit themselves to a 24-column grid system. Not to mention the designers that are totally ignorant of such a system and whose task is to design a website and mail the Photoshop file to some other company that has to build it. Although I have my reservations towards grids, I like the way these codebases are organized. It can serve as a good Blueprint for my own codebase.

I also get my inspiration from Nicole Sullivan’s talk on Object Oriented CSS (OOCSS). OOCSS basically means that you build your components in such a way that they become extendable objects. Just like in real object oriented programming. Just have a look at her talk about OOCSS on Yahoo! Developer Network.

Prefix classes

By adding a (relatively) unique string before the name of the class you have created your own CSS namespace. It will minimize any interference of other CSS styling that is not part of your own code. Some real life examples can be found in the code that is generated by the CMS systems I have experience with: Sitefinity and Sitecore. The CMS Sitefinity for example prefixes all CSS classes with “sf_”.

Grids, blocks and text

All CSS code will be split into different categories that work relatively independently of each other. Until now I can come up with 3 of them.

Grids

Grids are the frameworks of placeholders in which we put our content. You know: header, visual, column1, column2, column3 and footer. There are lots of grid templates around like Grid960 and Blueprint. My view is that those templates only work if the designer agrees to work within the limits of that framework. My ambition is to write a framework that makes my work easier while still being flexible enough to keep the designers happy.

Blocks

There are as many block as the designer can come up with. I think it will be a real time saver to talk with the designer and write down all the types of blocks he thinks he’ll like to use often. Or even better: just open the last 20 or so web designs he/she made and destil the common blocks and its common features. like menus, news article lists, homepage spotlights, etc. Finally you create basic blocks of it in your template system.

Standarization is not always popular with designers but if it means that projects can be created cheaper there may eventually be budget left to build cool stuff. At least, I hope…

Text

Basic text styling is also a relatively independent component in CSS code. You always define a basic font color, family, size and line height that serves as a base styling for the whole websites. More specific text styling in blocks should be kept to a minimum and preferably relatively to the base text style. So if you have a base style of font: 1em/1.5em normal Arial, sans-serif, you ideally should style a header in a block like this: font-size: 1.5em; line-height: 1.2em;.

Although font-weight is not something you can set relative to a base style, it’s not likely that it will look ugly in combination with some design if you add font-weight styling to a block. Setting the font-family in the styling of blocks on the other hand will most likely interfere with design, since designs tend to depend heavily on a particular font.

Create base templates and extend themes

The code for each grid system and each block will be stored in a seperate base CSS file. Each grid or block can be extended with extra themes or styles. Each style extension will have its own CSS file and presumes that the base file is already loaded.

Optimizing CSS

Having all code seperated in small snippets is great for maintaining an overview. As long as you can see what a CSS file does by looking at its filename, its will be easy to add and extend styling to a website.

The template code is not optimized for speed, though. If we don’t do anything about the fragmentation, the server will have to load a bunch of little CSS files. It’s important to stress this: It’s not just the total filesize that matters, each http request costs time. Check out YSlow if you want to know more about this and if it affects your site.

YUI

That’s why all CSS in the website has to be exported, merged and its code minified to one single CSS file. Normally I use YUI compressor for it.

Less

But you can do more than just minification. Less is a system that extends the CSS syntax with stuff like variables, nested rules and mixins. Less was originally built in Ruby, but there’s also an ASP.NET port. I hope it will help me create very flexible grids.

By exporting CSS into optimized code, you can focus on making the most readable CSS source file because all comments and spaces in the code will be removed in the end. This is also what I do with JavaScript code and certainly will continue to do.

Related posts:

1. Too advanced CSS selectors
2. The last resort in CSS debugging
3. Tips for using and debugging of Less CSS code
4. Crucial stuff for your company’s internal projects

Though it may seem like a good idea, the X-UA tag was initially received with mixed reactions. Some worried for example that web developers will become lazy and would only support IE7 even if Microsoft would roll out IE15. John Resig (creator of jQuery) even would go as far as calling the X-UA tag, “completely useless” and “harmful”. He thinks that the X-UA tag will just create more confusion because there will always be differences between a native IE7 and an emulated IE7.

I decided to use the meta-tag anyway. If it really didn’t work at all I could always remove the meta tag. On top of it: most websites I work on are not that complex and simplifying test procedures is a big plus.

My experience with the X-UA

Until now I had some good experiences with the X-UA tag, but I must say I have encountered 2 differences in rendering between a native IE7 and an emulated one. That’s not much if you consider that I use it ever since the meta tag was available, but it is something we have to look out for.

One of those 2 bugs happened just a while ago. We noticed that some website did not render well in IE9 with IE7 emulation. The text that was styled with custom web fonts (loaded with @font-face) was chopped off at the top and bottom. There was no problem in a native IE7 browser. The bug below shows that although IE7 emulation works pretty well, it still may have some glitches.

The line above is a screenshot from a native IE7. The line below is from an IE9 in IE7 mode. Both run on Vista.

So it may be worth while to check some old websites you created when you installed IE9, even when you implemented the X-UA tag.

No related posts.

The template is based on the basic template of JSDoc Toolkit. The HTML structure is basically the same, but with a new design for both desktop and mobile browsers.

Command line options

• Set title -D="title:Estate Library"
• Remove _global_ -D="noGlobal:true"
• Make “Files” the homepage instead of “Classes” -D="index:files"

Example:
java -jar jsdoc-toolkit\jsrun.jar jsdoc-toolkit\app\run.js -d=Documentation\ -D="noGlobal:true" -D="title:Estate Library" -D="index:files" -t=jsdoc-toolkit\templates\codeview -p -v Javascript\Estate\Source\Estate*.js

Screenshots (version 1.1.2)

Codeview for desktops

Codeview for handheld devices

Changelog:

• 1.2
  - Extra command line options, thanks to Aaron Wirtz
  - A more logical template structure, thanks to Aaron Wirtz
  - A quick filter, to filter the class list and methods
  - Some bug fixes, including one reported by Gregor
• 1.1.2
  - Option for removing the _global_ link by adding -D="noGlobal:true" in the command line
• 1.1.1
  - Styling fixes
• 1.1
  - Support for mobile devices
  - Updated design and styling fixes

Related posts:

1. Codeview 1.2
2. Codeview update
3. Document your Javascript: interview with Michael Mathews of JSDoc Toolkit
4. Codeview is on Github now
5. Another Codeview update

• Behaviour of the fluid design
• Interaction like hovers
• How the website looks in different browsers

On top of it, she also mentions some disadvantages of using Photoshop:

• It crashes, leaving you with hours of work lost.
• Font rendering sucks

Photoshop is still king

Although creating a website directly in HTML has it advantages, I think designing in Photoshop is better in most cases.

Photoshop is faster

Yes, a simple design could well be created directly in HTML. But not all designs are simple. Changing a background color is easy in CSS, but dragging columns around, changing or altering visuals and all kind of other alterations are quicker in Photoshop. Designs can change dramatically before it is finally approved by the client. Those changes are quicker done in Photoshop.

Photoshop is static

Being static isn’t not just a disadvantage. A static design is in fact helpful because it helps you focus on how a website should look like and not be bogged down by browser incompatibilities. This too gives you extra speed in designing.

Photoshop is versatile

Just because CSS can do stuff like round corners and text shadows in some browsers, doesn’t mean it has become a designing tool. Photoshop can do more than just that. When designing in HTML I start to think too much in the constraints that both HTML and CSS have. In Photoshop I have much more design choices. Because of that I’m able to think more out of the box.

Crashes and font rendering

I was suprised that Photoshop crashes are mentioned as a major problem. I consider Photoshop as a very reliable product. The only problem is that saving can take a while, so not everyone saves regularly. If you don’t save regularly you’re asking for trouble. Even with stable products.

The issue with font rendering is indeed a problem, but that’s more an issue for designers. Clients don’t even know it’s an issue. They’ll only notice differences when they’re dramatic like with webfonts. Just compare this weblog between Apple Safari and IE on the PC: it’s hard not to see the difference.

My preference

Since I’m a web developer I ought to be tempted to skip Photoshop and start coding right away. But that’s not the case. I designed my blog twice last year. In both cases I chose to do the basic design in Photoshop. Only when I was happy with that basic design, I started developing and added extra elements on the fly. The current design of my blog could just as easy be built in HTML/CSS from the start, but I’m convinced it’s better to work in Photoshop first.

Related posts:

1. Differences between Photoshop web design and HTML. Part 1: line height
2. 3 Tips for making CSS sprites in Photoshop
3. The grey areas of progressive enhancement

• The menu on the top right was large and clunky. Because of that it didn’t leave much room for more links.
• The ‘logo’ on the top left did not feel like a real logo mainly because it was … well … just not designed well.
• The shadow effect on the columns looked cool, but because it was made with PNG8 images instead of PNG24, it wasn’t possible to add an background image to the page.

What I did like was the scalability of the website. you could as easily view the page on your (i)phone as it would be on your large, wide computer screen. I dropped support for mobile phones. There are lots of Wordpress plugins to cater the mobile devices. I have to dive into that some time. For now anyone with a mobile device can grab the RSS feeds.

I still have to fix a few styling glitches but I thought the design was good enough to make the switch. Here are the most important aspects of the design:

• Use of rgba as background color. This makes it possible to set opacity for just the background instead of the whole box. rgba is not supported in IE, so you will have a solid white background then.
• Using opacity in the columns makes it possible to use large backgrounds. That gives me a reason to pick up my photography.
• The use of webfonts. This was something I was eager to use. This is something designers and web developers alike have been waiting for. The implementation isn’t perfect, but it looks well in Firefox and on the Apple. IE and Webkit on the PC still need some tweaking. I’ll go in to more detail in an upcoming article. For now I’ve been glad to be able to experiment with a real web site instead of running some tests with webfonts.
• Less data: I removed irrelevant data where I could. It’s most apparent in the list of articles on the homepage where I removed information like categories, tags and dates.
• Links become visible with an underline when a column is hovered. This will make the website look less crowded. It’s a bit like the folder tree view in Vista’s Windows Explorer: you will only see the folding icons (the plus and minus icons next to the folders) when that section is active.

There are some things I have to do:

• Make a logo that is suitable for creating a favicon
• Tweaking the fonts for IE & Webkit on PC.

No related posts.

But like anything Photoshop has its weak points. And since we humans tend to focus on those tiny grains of imperfections I decided to sum up the troubles you can encounter when converting a Photoshop document into to a real website.

Line height between paragraphs

One thing that definitely can be confusing is the line height of text. When increasing the line height in Photoshop by setting the ‘leading’, the extra space is added above the text. In HTML That extra space is distributed above and below the text. Below you can see the differences next to each other.

A large line-height in Photoshop adds space above the text

A large line-height in HTML/CSS adds space above and below the text

Activate this window in the menu throught Window > Character

Many designers use line-height to create paragraphs. So if you want to know how much margin you have to set on paragraphs, you have to look at line-height of the first line in a paragraph. In short: Line-height of the first line – default line-height = the margin between paragraphs. That’s why I never look at the line height of the first line of text in a paragraph in Photoshop.

Line height of the first line in a text box

Another thing to be aware of is that the line-height has absolutely no effect in the first line of a text box. So it doesn’t matter if you set the line-height to 20px or 40px. No extra white space is added on top of the text. HTML does not follow Photoshop’s behaviour.

Because of that you have to be aware that different styles with different line heights in a website can push the whole text box up or down. That’s especially important when the first line of a text box should align with some box or image on the left or right as you can see in the examples below.

The solid box and the text box are aligned (line-height: 20px).

...but when a heading is added with 40px line-height it does not align anymore.

You could fix the problem above with this CSS:

.textBox h1:first-child {
    margin-top: -10px; /* only half of the extra line-height has to be compensated */
    font-size: 20px;
    line-height: 40px;
}

The first-child selector ensures us that the negative margin is only used on something that’s on the very top of the text-box. As already said, the line-height is distributed above and below the text. So we only have to compensate for the extra space on the upper part of the line. So:

40px (line-height) - 20px (font-size) = 10px (the value for our negative top margin).

Related posts:

1. Do you create your design in Photoshop or Notepad?
2. 3 Tips for making CSS sprites in Photoshop

Most of the time that’s not what you want. Using tag names as selectors can also make design changes troublesome if you have to add more divs and need to give it a different styling. But since IE7 we can use new selectors that help us to build much more delicate CSS selectors. Those new selectors are:

• Child selector: .parent > .child
• First child selector: .parent .child:first-child
• Adjacent selector: .sibling + .sibling
• First child selector: div:first-child
• Attribute selectors: div[id]

Now you can style the following HTML with just a single class:

HTML:

	This is some title
	Lorem ipsum
	Lorem ipsum
	Lorem ipsum
	Some body text with lots of lorem ipsums in it
	Some body text with lots of lorem ipsums in it
	Lorem ipsum

CSS:

.container span {
	font-family: sans-serif;
}
.container > span:first-child {
	font-size: 1.5em;
	font-weight: bold;
	font-family: serif;
}
.container > span > span {
	font-style: italic;
}
.container > span > span > span {
	font-weight: bold;
}
.container > span + span {
	display: block;
	margin-top: 0.5em;
}
.container a:nth-child(2) {
	font-weight: bold;
}
.container a {
	display: block;
	color: #f0f;
}
.container a:nth-child(4) ~ a {
	font-size: 0.9em;
}

The advantage is that you can, as you can see, style whole blocks of HTML code with just one class. In theory you could even use no classes at all. Without ‘class’-attributes on every element, the HTML code looks just a little bit more cleaner and readable. You can also use those and other selectors in javascript libraries like jQuery to select particular HTML elements. Since most libraries are cross-browser you don’t have to worry if a selector is or isn’t supported by a browser. Consider this piece of code in jQuery:

jQuery(".container a:nth-child(4) ~ a").click( function() {
	alert('hello world');
})

That’s all nice, but should I use it?

No. I use them some times, but I try to stay away from it if possible. The problem with these selectors is that they rely so much on the structure of the HTML that it becomes harder to change the HTML structure. If you take another look at the HTML and CSS that I showed as an example in the beginning of the article, it’s clear that you can’t add a few links or spans without having to change the CSS. Add some advanced jQuery selectors in the mix and you may have locked the HTML structure forever since no-one dares to change it.

Should I discard those new selectors then?

Not necessarily. Sometimes you just have no choice if you for some reason are not able to change the HTML. My personal guideline is that styling has to be predictable. So when you edit some piece of HTML code, the styling should behave as expected. That means that you don’t style your HTML in a way that the text-color of the 4th span is red.

So what can be styled predictable? If you ask me advanced selectors shine when the structure is relatively fixed. Lists are a good example. Just take a look at these code blocks below. The styling will behave normal, regardless what you do with the HTML.

HTML:

Lorem
Ipsum
Dolor

Sit
Amet

CSS:

ul.list li + li {
	margin-top: 10px; /* adds top margin to all list items except the first */
}
ul.list > li {
	font-weight: bold; /* styles only the first level list items differently */
}

Javascript:

jQuery("ul.list li:nth-child(even)").addClass("zebra"); // adds zebra striping to a list

HTML elements you can easily apply advanced selectors

Besides ul, you can style uls, dls, tables. That doesn’t mean that other elements should only be styled with classes. There are always some exceptions to the rule. Just let your common sense be the judge.

Related posts:

1. How to overcome the limits of CSS in Internet Explorer 6
2. For the sloppy clickers
3. Hack: how to enable :first-child in IE6
4. Alternative for :nth-of-type() and :nth-child()
5. What you can’t do in IE’s Quirks Mode

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

I only build websites in Standards Mode, so Quirks Mode is an almost non-existent issue for me. This week, however, I had to restyle an old website. And while rewriting the CSS I remembered that the difference between the two modes goes farther than just a difference in box model. Simple things you’ve learned to rely on in Standards Mode are gone in Quirks Mode.

No * html

If I want a class to specifically target IE6 or IE7 I always prepend selectors with * html (IE6) or *:first-child+html (IE7) in case the rendering is a bit off with other browsers. But that simply doesn’t work in Quirks Mode. On Wikipedia there’s a list of browser bugs you can exploit in CSS. I chose to exploit the ”!important quirk“ since future browsers will just ignore the invalid CSS code that only runs in IE6 and IE7.

To use the ”!important quirk“ you misuse the !important keyword. Normally that keyword is used like this:

.classname {
    width: 100px !important;
}

The !important keyword ensures that the width of 100px cannot be overruled by other styles unless you use another !important. In IE6 and IE7 any keyword that starts with a ! works like a !important, so you can write something like this:

.classname {
    width: 100px; /* works in all 'normal' browsers' */
    width: 150px !lteIE7; /* for IE 7 and lower */
}

No fancy selectors

What surprised me much more is that some advanced selectors like the attribute selectors are not possible in IE7 when running in Quirks Mode. So the CSS code below will only work in Standards Mode:

table[width='160'] { /* this selector will not run in IE7 Quirks Mode */
    width: 100px;
}

The same holds true for selectors like :first-child, the Adjacent Sibling (+) Combinator and the Child (>) Combinator. Bummer.

Why not use conditional comments?

If you want to have some classes that are specifically targeted towards IE6 and IE7, Conditional Comments are the easiest and safest thing.

<!--[if lt IE 6]>
<link href='/css/IE6.css' rel='stylesheet' type='text/css' media='all' />
<![endif]-->


But I prefer CSS filters above conditional comments. By using CSS filters I have all the styling of an element in one page and not scattered around in different CSS files. In most cases I only use conditional comments to hide CSS code that won’t validate.

More information about conditional comments

Code for the sake of Technorati: 4252WKT38H9D

Related posts:

1. Too advanced CSS selectors

• Dreamweaver In your menu go to: Commands > Clean Up HTML.
• Visual Studio Select the source code in the editor, right click on the selected code and choose Format selection. Here’s a nice article from Scott Guthrie that also explains how to configure the source formatting.
• HTML Tidy If could probably list a plethora of programs that (also) do formatting, but I’ll only mention HTML Tidy since I occasionally use the online version of it on HTML Tidy Online.

Related posts:

1. Tips for using and debugging of Less CSS code

• Using a grid
• Some info about exporting
• How to use bullets in CSS sprites

The grid

One of the things that make CSS sprites hard is to figure out what coordinates you have use to show the right image in the sprite. To keep things simple I always switch on the grid: Ctrl+'. If needed I configure the grid to 50 pixels per line by doing the following: Ctrl+K, select “Guides, grid & slices” and set the gridline value to 50. Finally I press Ctrl+Shift+; to make objects snap to the gridlines. Now you will have something like this:

Now you can fill it with whatever you want. Because everything snaps on the 50 pixel grid it’s easy to find out what coordinate you have to use. For example: if you position the cursor to the upper left corner of the image you’d like to use (like in the screenshot below), you’ll find your coordinates in the info pane. It will be off by a few pixels but since it’s on a grid you know that you just have to round of the numbers. In this example the CSS code would be background: url(sprite.png) -200px -50px no-repeat.

Exporting the CSS sprite

I always export a CSS sprite as PNG8. On rare occasions I do JPG to create an onmouseover-effect on picture. If you don’t have to support IE6 you might consider using PNG24 instead since it supports full color. But if you do have to support IE6 you’re stuck with PNG8 because IE6 cannot handle the alpha channels of PNG24. You could use IE’s proprietary filter, but that doesn’t work that well with CSS sprites since it doesn’t have an option to position a background.

Since PNG8 has a maximum of 256 different colors, the exported image may look bad if you need much more than that. Be wary of sprites with different colors and gradients. They may need much more than 256 colors. If you need much more colors than PNG8 can offer you, you could split the sprite by grouping the colors in different sprites. For example: you’d create one sprite for all red items and one for all the blue items.

Lists and sprites

Normally you use a sprite in a box that has a specific width and height. Otherwise some other image in the sprite might pop up. So sprites aren’t usable in blocks with dynamic heights like p tags. But there’s one exception: list items. Because bullets in a list are always aligned in the top left corner you just have to be sure that there’s no image on the right or the bottom of the bullet. So if you align the bullets from the left bottom to the upper right like in the example below you will never have images popping up in places they shouldn’t be. The left side and upper side of the line of bullets can still be used to place images while the bottom and the right has to be clear at all times.

Related posts:

1. Differences between Photoshop web design and HTML. Part 1: line height
2. Tips for using and debugging of Less CSS code