Friendly Bit - Web development blog

Rendering a web page – step by step

2010-01-11T01:04:33+01:00

Have you ever thought about what happens when you surf the web? It's not as simple as it seems:

You type an URL into address bar in your preferred browser.
The browser parses the URL to find the protocol, host, port, and path.
It forms a HTTP request (that was most likely the protocol)
To reach the host, it first needs to translate the human readable host into an IP number, and it does this by doing a DNS lookup on the host
Then a socket needs to be opened from the user's computer to that IP number, on the port specified (most often port 80)
When a connection is open, the HTTP request is sent to the host
The host forwards the request to the server software (most often Apache) configured to listen on the specified port
The server inspects the request (most often only the path), and launches the server plugin needed to handle the request (corresponding to the server language you use, PHP, Java, .NET, Python?)
The plugin gets access to the full request, and starts to prepare a HTTP response.
To construct the response a database is (most likely) accessed. A database search is made, based on parameters in the path (or data) of the request
Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).
The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.
The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response
A DOM tree is built out of the broken HTML
New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.
Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree
Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly
The browser renders the page on the screen according to the DOM tree and the style information for each node
You see the page on the screen
You get annoyed the whole process was too slow.

I, too, get annoyed when the above steps take longer than one tenth of a second. But now at least I have some documentation to look at, while waiting the remaining fractions of a second before the page renders.

Spoiled we are, all of us.

(Feel free to add more steps, through the comments…)

Position: fixed CSS templates

2009-12-31T15:14:26+01:00

In 2006 I wrote an article about simulating Frames and Iframes and from time to time, I get questions of how to make modifications to the templates presented. But one big thing has changed since 2006: Perfect support for IE6 is no longer mandatory.

So yesterday, when Brandon Cobb of Super Fighter Team asked about a design with a fixed header, fixed left column, and scrolling right column, I thought I'd renew my take on simulating frames with CSS (The original article is still good for background information, so I still recommend reading it).

Position: fixed CSS templates#

The idea is this: Instead of specifying what parts of the page should scroll, we can specify what parts should stay fixed when scrolling. This makes it easier to deal with several fixed parts of the same layout, but also allows us do to things frames cannot do.

So what's the trick? Well, position: fixed does exactly what we want. It works just like position: absolute, but it stays still when the page is scrolled. So it's really just a matter of making sure things don't overlap.

Try resizing the page, and see how the scrolling works. The templates have been tested in: Fx 3.5, IE8, IE7, IE6 (see note below), Opera 10, Safari 4; all on Windows. Let me know if you can test it on more browsers, or find bugs.

You're of course free to use this templates as you see fit, with or without a link back, commercially or not. Consider it public domain.

Fixes for IE6#

As I've said, these designs don't act the same in IE6. Instead of some parts being fixed, the whole page scrolls in IE6. The good thing about this is that IE6 users won't see that your site is "broken", they will just get another design. And as the number of IE6 users goes towards zero, your design will be more and more consistent :). The fallback is very simple, IE6 gets position: absolute instead of fixed, using the !important hack (you should probably use conditional comments instead).

Hope these templates are useful for some of you!

SpriteMe – Combine images and get fewer HTTP requests

2009-09-19T17:09:02+02:00

Those of you that care about website performance have probably read about combining images, something that's called "CSS sprites". The idea is that by using the same (somewhat larger) image several times, you get fewer HTTP requests to your site, and therefore speed it up. Problem is, most of your images are CSS background images, that are positioned using clever background-positions and repeats.

Now, this makes to tricky to combine images. Something that repeats horizontally can't be combined with something that repeats vertically (unless there's transparency involved), and wide images can't be combined with narrow ones. So combining is usually tedious, manual work, both to combine the images and then calculate the new background-positions required.

Lucky for us then, that there is a tool called SpriteMe, available as a bookmarklet (a bookmark containing javascript), and as an excellent online demo that walks you through how it works. SpriteMe does all the hard work for you, you just have to copy and paste both the combined images, and the new background rules, to your site.

Decreasing the number of HTTP requests have never been simpler. Well done Steve Souders!

Techniques to use when IE6 dies

2009-08-26T23:54:51+02:00

Everyone except Microsoft themselves are talking about the death of IE6. I've tried motivating people to drop support, arguing that you at least can show IE6 users a message. Many have replied with "but our IT department doesn't let us…", and I can say nothing more than that the IT department is filled with humans. Which means they are lazy, and upgrade when people whine enough about it. It's a shame it has to be that way, that we have to punish people for their IT departments, but that's how it has to be.

As web developers, we should be the ones complaining the loudest. We have so much to win on IE6:s death it's silly. Just look at the below list of things IE6 can't do, but IE7 can (the next worst browser):

Native PNG alpha transparency without silly hacks.
Several selectors: Child selector (">"), Adjacent sibling selector ("+"), Attribute selectors ([attr=value]), and General sibling selector ("~", CSS3)
Min-height, Max-height, Min-width, Max-width
Multiple class/id selectors in the same ruleset (ie. .class1.class2 { … })
:hover on all elements, not just links
position: fixed
Native XMLHTTP (Without ActiveX)
International Domain Names (IDN), the ability to use UTF-8 chars in domains
Page zoom that zooms the whole page (don't worry about zoom)

This is a huge step forward for us web developers. Huge! Bigger then when CSS3 comes out, because we won't be able to use that one for years. Someone is pushing the front of what's possible, I'm pushing for the front of what's usable.

What can you do to help me get everything in the above list? And, did I forget something?

Sources:

A couple of sites I’ve launched

2009-02-16T18:18:02+01:00

Lots of opinions here lately, and very few concrete examples of work I've done. I thought I'd take a few minutes of your time and talk about those projects here.

All of the sites I've built are in Swedish. The reason for Swedish is just that they are so much easier to write for. Since English is not my native language, everything takes a little bit longer when having to struggle with vocabulary.

All of the sites are built with Django, a framework I've had great success with, which feels both well architectured and easy to get started with (a very unusual combination). Django also lets me write the HTML I want, without getting in the way.

(By the way: there's a Django User Group forming in Stockholm if you're interested. First meeting this friday)

Uttråkad.se#

The first one to launch was Uttråkad.se - hitta saker att göra, a site for everyone that have too much time on their hands. I guess the english version would be "bored.com", which kinda tells you what the site is about, right? :) Anyway, we've played around with having the site very open, with no registration needed at all.

I would say the launch has been a good one, with an article in metro the first week of launch, 153 activities posted, and about 70 daily unique visitors. It has been a fun project to be a part of, and it's been developed together with three friends in a group we call openworks.

Are you bored? Then play around with Uttråkad a bit :)

Kundo.se#

With our first project barely launched we decided to join an even called 24 hour business camp. The idea was simple: prepare a business idea, and build and launch it in 24 hours. Said and done: 92 entrepreneurs gathered at a luxurious conference center and presented 52 new sites 24 hours later. It was simply the best conference I've been to, and an extreme energy boost to be in a group of doers like that.

Anyway, we launched Kundo - kundtjänst på nätet after 24 hours, a site that companies can use to embed a feedback-widget on their site. Translates to something like "CustomerO.com", it's clearly influenced from Getsatisfaction but in Swedish. There's clearly a need for better ways for companies to communicate with their customers in Sweden too.

After the camp we still had some bugs and important features missing, so yesterday me and Björn sat down and squashed all the major ones. So, do you know of a company that needs to take better care of their customers? For free. Send them a link to Kundo. Thanks! :)

Samhallsentreprenor.se#

I've also been busy with Django at work. Samhallsentreprenor.se is a meeting place for people that work in projects that somehow help their local (or global) community. These are people that are incredibly motivated to do good, a group that's of course great to work for.

We've released new versions of the site about every 10 days, so development is fast, and through the development blog people can directly influence future features.

So, do you have ideas for projects that can help people around you? Sign up on the site and start talking to people.

Two more projects…#

… are under development and will be announced when they are done. There's no lack of things to do in my world :)

Interface developers and security

2009-01-24T00:30:44+01:00

You live in a new era, when demanding that people register on your site is no longer enough. There's far too many other sites out that that you're already a member of, you don't need another one. You need to trust people.

You also want people to contribute to your sites with content somehow. Text is not enough, you want all kinds of "rich" content, and you want people to be able to place them how they want on your page. I mean, we live in a new era after all.

Problem is, this new era thingie talk makes people forget the basics. Even though this is the future, and we're all bored with "just" hypertext, we can't allow random people to add HTML to our sites. Why? Ask myspace about the Samy worm from 2005, a little piece of clever front-end code that took their servers flying. What did they do wrong? They tried to let untrusted people embed HTML on their profile pages.

But they even had this clever filter, which cleaned the code first! Well, long story short, using a div with the style attribute set to a background image that points to a javascript url actually execute the javascript in IE6. Didn't think of that did you? So what about the fact that both IE6 and IE7 execute vbscripts in urls prefixed with "vbscript:", just like with javascript. Didn't know that? Ohhh. Perhaps then you shouldn't be trying to let unknown people embed HTML on your site?

Many of these security issues stem from the fact that ordinary well-educated computer scientists don't know enough about interface development, HTML, CSS and javascript, and discount them as being something that "anyone" could do. "Even my aunt made this puppy site in like 3 days, how hard can it be?!".

I've always thought that interface development have an undeserved reputation of being easier than "real programming"; something that you can let rookies work with, something that no "real" programmer would ever want. "No, I want to work with hard stuff, not that webby stuff".

If you are in a position where people actually think that, perhaps security could be the way to lift interface development to its proper status. So why not read up on Cross Site Scripting (XSS), look at examples of vulnerabilities, and pick a couple of examples of big sites that are vulnerable. While you're at it, why not read up on Cross-site request forgery (CSRF) too?

These are real issues that someone needs to take into account when building websites. My guess is that the fancy computer scientists will have a very long way to go before grasping this stuff. "Why does IE6 parse 'java script:' as if there where no space in the middle?". You know who's not surprised? Every damn interface developer out there.

So. Go out there, and teach them silly math people how it's done, and what your HTML, CSS and javscript-knowledge is worth. Show them that logic isn't the way we do things around here, that anything can happen when IE6 boots. And… whatever you do… think very hard before letting people embed HTML on your site.

OpenID, Nofollow removed, Comment counts, and IE7 fixes

2008-10-19T15:48:03+02:00

I'm added a few features to the site:

OpenID support: Instead of typing your name and e-mail you could instead sign in with an OpenID-enabled URL. Or you could completely ignore it, and go on as usual.

Nofollow restriction removed: WordPress by default adds rel="nofollow" to all links that people write in comments. It's a good way to decrease the impact of spam. Thing is, I strictly moderate comments, and have three plugins that prevent spam (Akismet, Spam Karma 2, and Bad Behavior). Since spam really isn't a problem, I've decided to remove the nofollow from your links, if you've posted more than three comments.

Comment counts: To make it easier to see who you can trust and not in the comments I've added a comment count next to the name. Damn, I've commented a lot :)

IE7 fixes: There were script errors in IE7 since I'm trying to do funky stuff with opacity on the search field. I've fixed that. Also, the number of subscribers wasn't visible in IE7. They are now.

Over and out.

IE7 hover bug: z-index ignored (and other properties)

2008-10-12T20:17:04+02:00

I'm implementing a rather different design right now for an intranet, and have found a bug I thought you'd like to know about. If you restyle things with :hover, you might have to add an extra property for the rule to be applied in IE7.

How is this design different? Well, it built on columns that are overlapping each other. When you hover one of the columns, that column get placed on top (temporarily). You think you need javascript for this? You don't (if you can live with not supporting IE6).

#menu, #content, #sidebar {
   z-index: 1;
}
#menu:hover, #content:hover, #sidebar:hover {
   z-index: 2;
}

Simple isn't it? Now you just have to absolutely position the three columns. By the way, working with absolute positioning is ok as long as you don't need a cleared footer below the three columns. Strange that not more people use this.

Anyway, the above doesn't work in IE7. It should, because IE7 supports :hover on all elements, including my "div columns". Some googling led me to an old IE6 bug where some elements are ignored on links. The bug talks about IE6 and the color property being ignored, but the same seems to apply to IE7 and z-index.

So, long story short, just add display: block to the hover rule and everything works fine. As the link above dictates, many different rules work, the important thing is that it must be a new rule, which you haven't used before on that element. But you don't set display: block; on divs, do you? So it should work fine.

Hope it helps some frustrated soul out there :) And long live funky designs.

Yellow fade with CSS and a simple image

2008-10-04T20:19:09+02:00

Via Think Vitamin I find a cool way to highlight the current element. Lots of people do this by calling some kind of javascript library, it's so common it's been dubbed the yellow fade technique. But javascript isn't really needed, you just need CSS and an image.

First: you can jump to any id on the current page by appending #some-id-here to the url. This includes all the "semantic" ids you've added to the page such as #content, #sidebar, and so on. Very useful if you want to point out a certain section of a page to a friend, just look at the source, try to find an id nearby, and add it to the url.

If you want to make things even easier on your own site, you can visually highlight things that get referenced via the above method. That's where the :target psuedo selector jumps in to save your day. Please note that :target is CSS3, and only currently works in non-crap browsers. But perhaps this effect is something not all users really need?

a:target {
   background: #234af5;
}

This highlights all links that get referenced via the URL with a nice blue color. So they need an id added. Makes perfect sense for all kinds of documentation where you want to refer someone to a certain method or even sentence.

But it gets better:

:target {
   background: url("/images/yellow-fade.gif");
}

We've removed the limit of only targeting links with by using :target straight off. So all targeted elements will get affected by this rule. What next? Well, we use a small animated image to fade from one color to the next. It's a really easy way to add dynamics to a page.

Try the effect by jumping to the code example above.

I really think this makes internal links a whole lot more useful, especially for jumping to the bottom of the page, where it's not possible for the browser to scroll down enough to get the targeted element to the top. Needless to say, I've added this effect to this site too. Hope you can find something to use it for too.

The Open Web: Can it deliver?

2008-09-01T22:58:08+02:00

It's ringing through my head as Microsoft releases Silverlight, as Adobe forces another version of Flash or Air, and as Sun tries to push JavaFX into the spotlight. It's a dark whisper when I read how many still use old browsers (hello IE6!), or when I see Javascript being used poorly by otherwise knowledgeable programmers. It's getting obvious when people complain over how hard and hacky HTML and CSS is.

People are simply not getting their job done fast enough. Just because we've hacked and hacked to the point of getting used to it, doesn't mean our way of writing web apps is the best way. In the end it about delivering to end users or paying clients, and they care more about what you deliver than how. I'm not saying we are working slower than before, it's the opposite, new tools makes web development less annoying. But I am saying that we get less work done in relation to the expectations.

So what do they expect? Well, they want flashy effects. The want application behavior. They want snappy response times, bright colors, and "Wow!"-reactions. For our clients, the web is getting more crowded every day and they need to fight harder and harder for people's attention. That means you need to fight harder on their behalf.

Say you are a pro open standards developer, like me. What tools do you have to grab people's attention? Valid HTML? DIVs with fading color? AJAX? No way man. A good Flash developer can get a wow reaction by the time you've chosen doctype (or at least by the time you've booted IE6).

So you turn to Google, and look for the latest and hottest in standards development. And you find that you need to use Javascript and Flash (sIFR) to render custom fonts. You find that you need to use (Adobe) Photoshop to add highlights and shadows on your headers. You find that you have to hack severely to be able to use alpha transparent images. To do any kind of animation, you need a big Javascript library, because browser makers have not yet (yes, it's 2008) been able to collaborate on how the language should work.

You say that standards have to take time. That everyone needs to come together and thoroughly discuss important issues. The right committees and councils needs to be formed. Meanwhile Microsoft prepares for the release of Silverlight 2.

Have you no sense of urgency?

Why adding variables to CSS is a good thing

2008-08-07T16:29:24+02:00

Via Simon Willison I find that Bert Bos, one of the creators of CSS, has written an article on why variables shouldn't be included in CSS3. I thought I'd try to explain why I think they should.

Professional perspective#

Bert posts statistics of stylesheet usage from the W3C site, and means that most stylesheets are very small, and on those, variables are not really needed. I agree. You can get away with simple search-replace in those simple cases. But Bert also finds that there are bigger sheets: "largest hand-written style sheet: 1462 lines (bought from a Web design company)". I work at one of those companies, and almost all CSS files I write exceed 1000 lines.

In those cases, I think CSS variables would help me a lot. Especially for margins. Matching several margins together by copying the same value over and over again isn't maintainable. Search replace on a pixel value is a sure way to mess up your whole stylesheet: who says you only use 5px for those margins? So there is a use case for some kind of variables.

So we need variables, but how?#

Bert then suggests that those people should use a solution such as PHP to generate CSS. So we should invent a new language for generating CSS with PHP? And another language for generating CSS from Ruby, from Java, from .NET, and so on. Why shouldn't we go this way? It's the path HTML has taken. And this is a hard nut to crack. How is CSS different from HTML? Why should CSS have variables when HTML doesn't?

I think the answer is that we should add variables to both languages. They are very similar in nature, so they should be treated the same. Because what has changed since when CSS was created is that we've started building bigger and more complex sites. And if CSS starts to be too cumbersome to use, people will start looking elsewhere, to Flash, Air, Silverlight and so on. CSS needs to adapt to the more complex sites people are building today.

I'd rather see CSS follow the times and add variables, than seeing frustrated professionals move to proprietary technologies.

So what about beginners?#

Bert's article deals a lot with beginners, and how it will be harder for them to understand another level of abstraction. Lets make it clear at first that CSS already is too hard for beginners. To make a very simple layout you need to understand floats (yes, almost everyone needs columns), and floating is really confusing (ever tried to explain float/clear to someone?). Even for someone like me, who has worked with CSS for years, floats still puzzle me regularly.

People will give up on CSS when they encounter floats (yes, I've seen this), not when they find CSS variables. They can just choose not to use variables, while they really need to know floats. Also, CSS variables are easier to understand than cascading values. I mean really, if I set font-size on body, why do my links get larger? That's a very similar concept that is central to CSS.

Summary#

CSS Variables make it easier for professionals to do their job. It doesn't require inventing new template languages. It doesn't make the language overall harder either. The people that can handle floats and cascading, can handle variables too. We need variables.

Don’t waste time writing HTML and CSS

2008-07-10T00:02:50+02:00

When you've worked with front-end development for a while, you start thinking about effectiveness. So without further ado, here's my four best ways to be a more effective front-end developer. Feel free to add more ideas as comments!

1. Do you need HTML or CSS for this?#

Lots of times when I get stranded on hard problem and sit back, I realize that I really shouldn't be trying to use CSS to solve all layout problems. Assuming a rounded corner box will have to scale in all directions (up to 8 images!), when it really is fixed width and height (1 image), is an indescribable waste of everyone's time. Look closely at the design you're trying to implement: does it really have to be as flexible and scalable as you think? Shifting to that mindset saves me hours of work per day.

One thing that many developers forget is that not all designers care for exact pixels. If something is really hard to develop, walk over to their table and suggest a change. You'll soon start to notice that designers are real people too, and that they have as much flexibility as you do. It's just as easy to call them up, so don't let shyness waste your time.

2. Try to set properties once#

When you know you have to do something (see above), try to do things once. This is really tricky in both HTML and CSS, languages that have no variables, and generally makes code reuse a pain. But it is possible.

With CSS; set widths of elements once, and trust inner elements to fill their parent. That's the default behavior of block level elements, and you can set display: block, or width: 100% on most other elements. Don't set heights at all if you can avoid them, and let elements expand to fill their containers. Combine similar CSS selectors to avoid typing things twice, and make new ones for common properties when few properties differ. Use floats and clearing instead of absolute positioning, and you'll won't have to micromanage positions all the time.

With HTML, make sure that you really know the template language. I've fighted with ASP.NET, JSP, JSTL, Smarty, WordPress Themes, RHTML, and Django's Templating Language, and now know enough about all of them to be productive. You should never have to type the same structure out twice, even in HTML. If your template language have loops, if-clauses and includes you really have no excuse to copy large chunks of HTML around. Refactor your HTML and make your own life easy.

3. Learn your text editor#

When code reuse isn't possible, use search/replace in your favorite text editor.

Replacing all instances of one HTML tag name with another is about replacing "element>" with "element2>" (without the opening bracket). That way you replace both opening and ending tags at once. Check to see if your editor supports regular expressions in its search/replace tool. If it does you can save lots of time by learning it. Matching a HTML tag is "<[^>]+>", a starting angel bracket, one or more non-brackets, followed by an ending angel bracket. Naive regexps can make you match the starting bracket of one tag and the end of another, which makes for a mess.

There's lots of little tricks like that, if you learn them you save massive amounts of time.

4. Make sure your environment supports you#

There's more than the text editor that you have to work with. One essential part of front-end development is trial and error. It sounds silly but no matter what your skill is, sometimes you must resort to trying and testing your way to a solution. With HTML and CSS, this means being able to quickly make a change, switch window, and see that change in the browser. If that cycle takes more that 5 seconds, you're losing valuable time.

Don't use a virtual machine (even if it's only for IE6) that you can't quickly Alt-Tab out of. If you're stuck using one, you need to have the text editor on that machine too. It's worth your time fixing it.

Don't accept build processes that makes you wait more than 5-10 seconds before you see your changes. With trial and error coding you will then waste 50% of your capacity doing nothing. Most often you can bypass this by copying just the HTML and CSS to the right place, without touching other source-code. I've managed to do this in all kinds of crappy environments, and it's always worth it.

So.

I hope some of the above can help you save some time each day. The little things add up you know. What's your best time-saver?

Upside down text with CSS

2008-06-26T22:34:31+02:00

Previously I've talked about reversing text with CSS by simply setting a few CSS attributes. Today we will try another trick: turning text upside down.

It's actually possible using a simple CSS property and works cross-browser today. The property to use it "text-gravity" with a value of "inverse".

<span style="text-gravity: inverse">
write upside down text
</span>

… and this is the result:

ʇxǝʇ uʍop ǝpısdn ǝʇıɹʍ

I'm really surprised to learn that so few people know about this property, and I recommend you to continue reading the W3C specification of text-gravity.

Update: Sorry, I lied :) The above is done with a UTF-8 character generator (see the link the the "specification" above). Amazingly, you can find that most characters have their upside down equivalent somewhere else in the huge Unicode alphabet. Neat trick :)

Feed readers should show comments

2008-06-15T17:25:48+02:00

One thing I've noticed lately is that I read fewer comments. It isn't that strange really: I read blogs using a feed reader and it doesn't show a links to comments. I see a couple of reasons why comments are not cared for in feed readers:

Why not #1: Feeds are meant to be fast#

Many subscribe to feeds to be able to get news before everyone else. And getting things fast means getting it before anyone else have commented. Why add a lot of zeros below each feed item?

But, it isn't unusual that I read posts that are a couple of days old. I don't read my feeds every day, rather every second or third day. In those days there are most likely comments on good posts, and of course I don't want to miss them. The older a post is, the more likely that it will have interesting comments.

Why not #2: Comments are hard to detect#

Perhaps feed readers have a hard time detecting if there are comments to a post or not. Comments are not included in the post, so wouldn't they have to parse through the feed link for comments?

No, there is a tag called <wfw:commentRss>, that's possible to use in both Atom and RSS (If I'm not mistaken), that gives a link to the comment feed. That means feed readers could easily get the comments too. The best thing here is that all WordPress blogs (and others too) have it already. It's just a matter of using it!

Why not #3: Each post will be too long!#

If there are 50 comments to a post, the item in the feed reader will be too long to read. That would also affect download time and therefore make things slow.

Yes, it will mean downloading more data, but you also get more information. Each feed reader is free to implement comments any way they like, and I doubt it will be to expand the original post with all 50 comments. I little link that expands comments (don't download any extra data until you expand)? Only show the first five, and a link to the page for more? There's lots of good options here.

Promote contributions more#

Adding comments to your feed serves to promote your user's contributions even more, and I'm really surprised that not everyone does it. I'm using feed burner for my feed and can therefore use a feed flair (Click your feed / Optimize / FeedFlair / Comment count) to add a link to my comments at the end of the post. That's a first step.

What would be much better was if feed readers would get better at promoting comments. Could we get them to somehow?

New theme up for friendlybit.com

2008-05-22T01:04:54+02:00

Hi! If you're reading this blog through your feed reader, today is a good day to break out of it and have a look at the site. There's been several little changes throughout, and I invite you to click around and explore things. Let me know if you find anything broken!

Comments have moved up to the top and gotten more space. That includes the comment form which have been an insult to people wanting to comment. I'm hoping you reward me by correcting me even more often.
I'm using Google for my searches. Instead of trying to patch the builtin wordpress search I'm just linking to google from the header. It gives both faster and better results.
Design-wise it's much "lighter" than before. The old one felt hard and heavy, and didn't look to be as open as it in fact is.
Widgetized. I'm using wordpress widgets all over the place, which makes the administration of things like the "recent comments" easier. I just log in and change a number from the admin interface.
Fluid width (between 1000 and 1250 pixels).
Much nicer CSS, with a structure that you can actually follow.
I've promised you the number of feed readers clearly visible, and I'm still going to get it done. But I'm not done yet.

No matter what I will keep what I've always done with comments: I will read each and every comment you post, and I won't close articles for comments even though they are a year old. I will keep replying to (almost) all posts within a couple of days. I won't delete your comment just because I disagree with what you're saying, and I will go back and correct the original article with any errors you find.

You are what makes this blog what it is. I could have written all my texts in word instead (and some of you probably wish I did sometimes), but that would have been totally meaningless. Feedback is what makes this blog go around.

Thanks!

Style tables with CSS

2008-03-14T01:10:28+01:00

I don't deal too much with tables. Not because I don't want to but because clients hardly ever want to use them. My guess is that they are too hard to create with todays WYSIWYG editors, and therefore get left out. It happens though that I have one or two static tables I need to style, and then I get to use a couple of my tricks.

All of the examples below work across browsers. Including IE6.

Add a gradient to your cells#

One easy way to make tables look better is to add a subtle gradient to the cells. That's easy to do. But make sure you also set a background color with one of the edge colors from the gradient, and use the top or bottom keyword. You never know the height of your cells when people zoom the text.

td {
   background: #2B2B3C url(item_gradient.gif) repeat-x bottom;
}

Remove the space between the cells with CSS#

When designing tables you rarely want the ugly double border between two cells that appear when you set a border on td. Neither do you want the space in between them… Many believe the only way to remove that space is to use the cellspacing and cellpadding attributes in HTML. You don't:

table {
   border-collapse: collapse;
}
td {
   border: 1px solid silver;
}

See? No ugly HTML attributes needed.

Obey the set width#

Many of you have probably seen tables that do not stay within the width you have set on them. It can be long words or sometimes URLs that are wider than what can fit. By default, the browser puts content before style, and therefore expands the table to show the content. But what many don't know is that you can change them to always obey the set width:

table {
   table-layout: fixed;
   width: 100px;
}

Easy, and now the table will be 100px, no matter what.

Styling columns#

Sometimes you want to style some columns differently than all other cells, and I've seen that most people add a special class to each of the cells in that column. Wouldn't it be nice if there was a way to just specify the class once? There is!

<table>
<col class="first">
<col class="second">
<tr>
<th>Header 1</th>
<th>Header 2</th>
</tr>
<tr>
<td>Cell 1</td>
<td>Cell 2</td>
</tr>
</table>

col.second {
   width: 100px:
}

Convenient isn't it? There's one thing you should know though… The col attribute only allows four attributes: Border, Background, Width, and Visibility. What the heck? Well, there is performance issues with implementing more complex things so W3C decided not to include it. So what if you need to set, say, text-align on a column? You can be clever:

col.second {
   text-align: right;
}
td:first-child + td {
   text-align: right;
}

The above works because IE allows setting more properties on columns than the spec allows (Hixie explains it well). Firefox on the other hand, ignores the set text-align, but instead allows you to use a sibling selector to select the "second td after the first one" (you can add another "+ td" to select the third one, and so on…). Voilá! Cross browser column specification.

That's all for now, did you know all of them?

Documenting CSS

2008-02-27T23:55:00+01:00

Just like all other programming the CSS needs documentation. I'm afraid I'm rather bad at it: the times I'm lucky I've been able to document by simply talking to the developer taking over, and the unlucky times I've left no documentation at all. Talking directly is of course superior to everything else, you don't waste time explaining things that are obvious (differs from person to person), but you don't always have that luxury. So what I thought I'd do is list things I think are important to document, for the times when you won't be available for answering questions.

Don't be fooled to think all projects are alike. Sometimes you're under tremendous stress just to get the basic CSS up and running; it isn't reasonable to expect the same kind of documentation then… But most often you have an hour extra to just jot down a couple of lines about your interface.

How is the CSS file(s) structured? When you build large sites you often end up with over 1000 lines of CSS, and if you don't structure them, you'll end up with a mess. Even if you DO have a structure, it takes a lot of time to figure out someone else's code. To give you some ideas of your own, I wrote about how I structure my CSS previously. You don't have to use that one, just be conscious about your choice, and document it.
Where do I add new styles? Either it's obvious from the previous structure or you need to make it obvious how to add new stuff. What if I'm adding a deviation from how a certain section looks, should I put it near that section's styles, or near all other deviations? This question is especially important on sites with lots of campaign components with custom CSS. Trust me, your cleverly crafted structure will become a mess if you miss answering this question.
What can I do with existing styles? To make sure design ends up in the CSS and not in the HTML there needs to be some kind of overview of all available classes. Else people are going to hack things and try to duplicate your code. How do you handle columns, clearing, quotes, and floated images? Did you think of it yourself or do I have to add my own code? A good way might be to make a document where you tie the different classes to how they look when used.
How are different browsers handled? Struggling through browser hacks is a real pain in the ass, unless those hacks are properly documented. What browsers do you try to support, and which of them have you tested in? Did you plan for the future?
(Optional) Web standard basics. Working with web standards is rather different than working the old (table based) way . So if you know that oldschool developers will work with your code (are you sure they won't?), it could be a good idea to shortly summarize the modern web mindset. I recommend using a lot of links here, not to waste time; people are very different in what they know.

If you've answered the questions able you've come a long way. Your code is understandable, and will stay in shape for much longer. Not to mention when you're looking at some code in a year, thinking: "Who wrote this shit?! It's a mess!", and then figure out it was you.

Now, is there anything essential I'm missing, that you want to add?

IE8 and Doctype switching

2008-01-26T17:44:50+01:00

The topic of this week has been IE8s new rendering mode, and the strange way to trigger it. As usual, I've decided not to comment right away, and instead first read what others are saying and try to form an opinion.

I believe the best articles that talks about the switch are these:

Legacy, by James Bennet, puts this move in a bigger context. I believe his most important conclusion is that Microsoft are now clearly positioning themselves towards big old corporate intranets, reiterating "Don't break the web".
Has Internet Explorer Just Shot Itself in the Foot?, by Andy Budd, talks about how Microsoft marginalizes their own browser. Most people won't know about the switch, and end up in IE7 mode, so there's no real need for anyone to upgrade. IE7s rendering engine needs to be with us, forever.
Microsoft koan, by Mark Pilgrim, elegantly points out that strange code (unknown doctypes, including html5) will be rendered in standards mode, and ordinary code (proper doctype) will be rendered in IE7 mode. Seems twisted?

The real strangeness#

What I can't understand in all of this is how IE7-specific sites can be such big of a problem. Because that what all of this fuss is really about. That's why we need a new switching mode and they need to ship the IE7 rendering engine with IE8.

So, now there's a couple of different sites.

IE6 specific sites. My guess is that these are the majority of sites out there. These will break as much in IE8 as they did in IE7. "Don't break the web" does not apply to these sites.
IE7 specific sites. These are much fewer and got updated rather recently (badly, to work only in IE7). The new switch is there for these sites. With the switch these sites won't break.
Sites built to the standards. These were also updated rather recently, but unlike the above sites they were built to the standards. Fixes for IE6 and IE7 were properly only sent to just those browsers, and will not be sent to IE8 (conditional comments anyone?). If you targeted IE7 with your conditional comment, IE8 will not get that fix, breaking these type of sites. Well, unless IE8 will execute IE7 conditional comments, when that engine does the rendering.

So let's look back at the previous articles, keeping in mind the IE team mantra: "Don't break the web", the very reason why this fix exists.

First article (1): My guess is that many corporate intranets belong in the first group of sites. They haven't been updated in a while, and won't be either. This group of sites will be just as unhappy with IE8 as they were with IE7. This can't be about those sites. IE team mantra: "Keep breaking the web just as much as we broke it before".

Second article (2): This switch will increase the number of sites in the IE7 specific group. This will be at the expense of the standards group. When a developer not knowing about the switch sees that his site works in IE7 and IE8 (which will be the same), he will stop working on it. IE team mantra: "Freeze the web to IE7".

Third article (3): Since unknown doctypes will send IE8 into standards mode, there will be even more breakage than before. What? Well, sites with broken doctypes, that previously sent IE6 and IE7 into quirks mode and relied on that, will break. IE Team mantra: "Break the web".

Additionally, modern developers that don't read the IE blog, and don't know about the new switch, will keep getting IE7s strange behaviour on their sites. And since the switch also can be made via a HTTP header, even copying the full HTML and CSS of a site might break it when looking at it locally. IE team mantra: "Make people read our blog, or go insane trying to develop to the standards".

What it all comes down to#

This is a terrible idea, both technically and in how it was presented. If the same idea had been presented in a more open manner, "we're thinking about solving this problem like this… what do you think?", people would have been much more willing to help, and had probably came up with a better solution.

WaSP really acted badly by not first talking to the community, or at least discussing things internally, and instead just presented how IE8 will be built. Also, since this won't help developing standards based websites, and instead help IE7 specific sites, I'm not sure what the WaSP has to do with this issue whatsoever.

On the constructive side of things, I think the best way forward for IE8 is to change the switch to be opt-in, letting IE7 specific sites switch to IE7 rendering if they want to. That's makes sure IE7 sites that break are easy to fix, and does not break havoc on the rest of the web. Don't set the default to worse rendering than you can produce.

With the above change, I'm looking forward to another modern web browser, IE8.

Sharepoint 2007 from an interface developer’s view

2008-01-20T12:10:42+01:00

Like Cameron Moll (Skinning Sharepoint and Pointedly unskinnable), I've been working with Sharepoint 2007 (aka MOSS) recently, and I hope you don't mind me posting a few articles about my work here. I've found far too few blog posts that really go to the depth in explaining how things really work. I'll try to do that here, but I hope you can respect my wish that this does not turn into a helpdesk.

"Customization"#

Let's start. Sharepoint 2007 very, very hard to customize. If your job is to customize the interface in any major way, you have a lot of work ahead of you. You might think you're a much better interface developer than me, but you still have a lot of work ahead of you. You need to accept that.

When you read about Sharepoint 2007 on other sites you will find that people are really ecstatic about it. Just check the comments on how to customize the calendar. Reading carefully you will find that he's comparing it with Sharepoint 2003, not with other products, or even a standard ASP.NET site. That's a big difference. Sharepoint 2003 was much worse, but that does not mean things are good now. This is a common pattern, people that like Sharepoint compare it to the previous version, not with better ways of doing things.

As most CMS:es, Sharepoint gets sold to customers that don't know programming. They see a product that can handle all the features they want: blogs, wikis, forums, calendars, document libraries, workflows, and so on. All features you could ever want is included, from what is called "out of the box". The problem is that the system is built so that all of those "out of the box" features are hard to customize. Things like changing how the wiki renders, is really hard. Often it's easier to rebuild that feature from scratch, than customizing what Sharepoint ships.

This is the main reason, from my point of view, that you should pick another CMS.

Specifics#

I don't believe you trust me on my words, so I thought I'd be more specific now, and talk about the issues that make Sharepoint 2007 hard to work with (customize). Let me stress that these are not all the issues, just the major ones that an interface developer has to tackle.

Development#

From what I've read from larger projects, the recommended development environment for a Sharepoint site is a virtual machine. For us, we needed a 36 Gb image, a size that required me to get a new external hard drive, just to store it. Also, running in a virtual machine means that you only can use about half of your RAM, which means everything gets slow. As if that wasn't enough, a new virtual machine means you have to reinstall all your programs, browsers, plugins again. Web development shouldn't have to be like that.

Accessibility#

Sharepoint has gotten a lot of bashing for not being accessible, so they've added some features to account for that. Some of those are really good individually, but looking at the general mess that is the HTML that Sharepoint spits out, the pretty page above fades in importance. One major problem is that you still need javascript enabled for many of the accessibility features. Enabling "Accessibility mode", among other things, makes dropdown menus appear as new windows (popups) instead of dynamically writing HTML to the page. And this is after they "fixed" it.

Page size#

A standard Sharepoint site uses lots of default Javascript and CSS in two files called core.js and core.css. All in all they add up to over 250 kb. Yes, that's not a misspelling or extra zero, a default page in sharepoint takes at least 250 kb. This is not counting the HTML, a huge, table-ridden, inline-javascripted, mess of things.

If you go through lots of trouble, you can strip those files out, but that means you can't use any default components. Since much of Sharepoint depend on those, you don't really want to go that way. It's a mess, and Microsoft themselves recommend you try to remove some of it to boost performance. Preferably by using AJAX to load the js file later. Seriously.

Javascript and Browser dependencies#

Except from core.js, the javascript is spread out all over the place. As usual in many CMS:es, javascript is not treated as a real programming language, so there's no structuring whatsoever. Sometimes it's script tags, sometimes inline, sometimes external mini files, and most often automatically generated code. It's a real mess, and is a big reason for the HTML size being so large. Many of the scripts do not work in browsers other than IE, which means you really need IE to properly use the admin interface.

From the browser compatability info you can read that there are level 1 and level 2 browsers:

"Level 2 web browsers support all of our basic functionality so that users can both read and write in our content sites, perform site administration, etc. Some functionality may not be available, some functionality may be available in a more limited form, and some visual rendering may not be as optimized as our Level 1 browsers. We also will not support Level 2 web browsers on the Central Administration site."

These are the Level 2 browsers: Firefox, Netscape, Safari. Opera isn't even in the list. Is this the new, modern way, of handling cross browser compatibility?

Changing the CSS#

I previously said that most CSS is included in a file called core.css. The file in itself if huge, with thousands of class names, and no structuring whatsoever. Heather Solomon has made an attempt to make things workable by making images of what each class specifies. It's not even nearly a complete reference, and helps some, but using Firebug is a faster way. Another thing the CSS sheet above does, is show how completely unorganized the CSS is. Have a look at it.

As with core.js you can't really remove core.css, since lots of built-in functionality depends on it. So what you need to do is start deciding which of those rules you need to overwrite and which not. Have fun!

To add to the insult, if you just add your own CSS as an external file and try to link to that on your own pages, core.css is appended as the last stylesheet in the source code. This of course means that all your changes get overwritten, and you need to hack around things by using the tag directly (instead of sharepoint's own csslink-control), or add your custom files via the admin interface. Since core.css is just a list of simple class names, you can also use CSS Specificity to make your rules count, but that isn't mentioned in any of the troubleshooting blog posts. None the less, it's tedious do work around.

Most of Sharepoint is upgraded to use .NET 2.0, and its concept of Master pages and aspx pages. For those of you that don't develop in .NET the two can be explained as a templating mechanism, where each Master page has general placeholders where you can insert aspx pages. In each aspx page you specify one master page, and all of the placeholders you want to fill with content. It's a pretty good system.

Sharepoint taps into this system by making up two strings "~masterurl/custom.master", and "~masterurl/default.master", that you use instead of specifying your own masterpages. Users then specify masterpages in the admin interface, potentially breaking the entire site. Also, Sharepoint assumes there's just one masterpage per site, so if you thought you could use one masterpage for twocolumn layouts, and another for threecolumn layouts, you're wrong. The solution here is to break out of the Sharepoint way and hardcode real urls instead of doing things the Sharepoint way.

There's also things you can't change. The admin interface has a masterpage called application.master, which controls pretty much everything that has to do with built-in Sharepoint things. You don't ever change this file, since it's quite easy to seriously break things then. The problem is that this file also specify the look and feel of the admin interface, and if you're building a site where people are expected to add stuff, they will spend time in the admin interface. There isn't a good way around this, and you probably end up just changing some colors via CSS and let it be.

Default .NET controls#

The default master pages that ship with Sharepoint is horrendous and I'll post more details about them in a later post. But even if you roll your own master pages from scratch you still have the standard .NET-problem with controls. Using controls in .NET is a way to package functionality that you can easily add to your pages. A developer just needs to copy a DLL file, and call the control, optionally sending in some parameters. Easy.

The problem with this approach is that a control consists both of logic and HTML. So if you want some built-in logic that renders, say, the breadcrumb trail, you also get the HTML the author of the control deemed appropriate. In Sharepoint, a breadcrumb trail can be a doubly nested table, with display: none; controls to enable accessibility, and a doubly span nested link. It's just a terrible mess, but there's no other way to get to the breadcrumb logic, except from building a new control from scratch. Be prepared to work with terrible HTML.

In summary#

If you want to examine the points above by yourself, there's a MOSS example site up at wssdemo.com.

This article is a interface developer view at Sharepoint 2007. If you look at the system from other viewpoints, I'm sure there are good things there. That's not my point. What I'm trying to say is that Sharepoint 2007, is beyond repair when it comes to interface customization, and you should do everything in your power to avoid working with it. If I can give one interface developer the arguments to convince a customer to pick another system, this article was worth it. Thanks for reading.

IE8 renders the acid 2 test

2007-12-20T00:27:21+01:00

I'm not sure why I don't see that many people talking about the fact that IE8 renders the acid 2 test perfectly now. It really seems Microsoft is starting to move forward again, after starting to feel some pressure from the open source world. Will they be able to pick up the speed needed to get 96% marketshare again? Time will tell.

Update: Good interview about IE8 on channel9.

Future of web standards (my take)

2007-12-20T00:35:18+01:00

Stuart Landridge sums up the ongoing debate about the future of CSS. My thoughts on this are that we should:

Let browser makers run loose with implementing new features, based on feedback from web developers.
Have a standard body (or some other group) that look at those existing features and see how they can be standardized.
Have browsers change their implementation of the features to match what the standards body proclaims.

Step 1 stops the bad idea that is to have a committee of people do innovation work. You need people both that know what web developers want and what is possible to implement. Browser makers do this.

Step 2 makes sure the wild features that browser makers have played with get usable on real sites. To be usable a certain feature needs to be usable across (a majority of) browsers, and web developers of today know this. Before reaching this stage features will be played with, but not used on production sites.

Step 3. Browser makers having implemented a feature differently from what the spec suggests need to change their implementation to match that of the standard. This step means that the standards body need to have the trust of the browser makers.

For the features of a certain browser, this means that a feature will move from "experimental", when it's played with, and to "standardized", when there is a spec and the feature conforms to it. Browsers need to specify this somehow.

I believe this is a much saner process than what is going on right now. Let's try it.

CSS3 Media queries instead of the media attribute

2007-11-21T18:21:50+01:00

In my previous post about the media attribute I talked about how strange the media attribute is, and that its usefulness isn't that obvious.

As a followup I want to point you to an article that Russell Beattie wrote about CSS3 media queries. Media queries are a way to check the capabilities of a user-agent instead of checking what kind of media type it claims to be. This makes a lot of sense to me. Does it really matter if someone is using a small computer screen or a big mobile phone? What about if they use a big ass table? (aside from the pun, I really think Microsoft surface is cool)

Checking for capabilities of a certain user-agent makes much more sense: "if available width larger than 200px, show two columns instead of one". If they are dynamically evaluated (I don't know if they are), they allow you to build truly dynamic layouts, that work virtually everywhere. That's what I call accessible layouts.

An interesting parallel is comparing checking user-agent strings and object detection in javascript, and the media attribute and media queries. I believe media queries is the natural next step. Today, the different types of media have started to mix; just look at TV:s and computers, or handheld computers and mobile phones. The type of media is not as important, capabilities are.

Although queries do not solve all of the questions I put forward in the previous post, they do pose an interesting alternative. Agreed?

(CSS3 Media queries are as a standard currently a candidate recommendation (which means it's safe to implement), and is currently supported by Opera 9 and Safari 3.

Update: Opera 9.5 evaluates the queries dynamically, Safari does not, thanks zcorpan)

Media attribute – what have you done for me lately?

2007-10-29T00:06:54+01:00

I've been thinking for a while about the media attribute on link tags. Some people might find that thinking deep thoughts about HTML attributes is kind of strange, but I know you, my dear readers, know the feeling ;)

An example, just so I know we're on the same page:

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

This makes sure devices that support the handheld media type (mobile phones?) should load that stylesheet, but no others. It seems simple doesn't it? By using a simple attribute you can style things differently for certain devices. But there's several things to keep in mind, that actually make this attribute a lot less useful.

Problem number 1: Presentation and content are coupled#

One of the big selling points of CSS is the separation of presentation from content. And while I believe that's still a good thing to have, not everyone agrees about it's usefulness. Some time ago Jeff Croft wrote an article about how unusual it is to only change the CSS and not the HTML of a site. While he's mostly making a point of why we should use a certain CSS framework, there's a good point hidden there: Right now it isn't possible to separate things completely.

Designers have of course known this for centuries. They will tell you: you need to adapt the design to the content you're designing. If you're building a site for a shampoo, you might use water and bubbles in your design. If you build a web development blog, you use an image of blueish sky… ehm… Well, you get the point. Good design adapts to the content. They are coupled.

You can't just switch out the content and expect the design to still work. Sure, you can make small adjustments, and make these available as alternate stylesheets, but larger changes just doesn't work. The problem with the media attribute is that it's made for big design changes (switching media), but with no changes in content. How often can you just restyle a word document to get a powerpoint slide? What about converting that slide to something nicely viewable on a mobile phone? That's what the media attribute is there for.

My point is: switching to another media needs much more than just a change in design. You need to change the content to fit that media too. And if you change the content, why not change what stylesheet you link to? This is why I rarely use the "handheld" or "projection" values.

Problem number 2: Load time#

You could think that the browser only loads the one stylesheet that matches the media it's currently showing. Not true. All stylesheets, no matter what media they are tied to, are loaded at startup.

This means that the more media types you account for, the longer the load time for any of them will be. Very annoying.

Problem number 3: User agent support#

While being able to design for specific user agents might sound like a good idea, the media attribute still requires user agents to support it. If a large part of user agents refuse to apply your style using the media attribute, why not use another method directly? Just to get an idea of how messy support currently is, you can read the css-discuss summary of the handheld problems:

"Some current phones apply "screen" styles as well as "handheld" styles, others ignore both, and in some cases the phone carrier runs pages through a proxy that strips styles out even if the phone could recognize them, so it's a crapshoot figuring out what will get applied"

As you see, the value of the media attribute isn't entirely obvious. Sure, you might be able to use it for print with good results, but that's not all it's there for. Right?

@media Ajax London, here I come

2007-10-28T23:09:37+01:00

Just a short note that I'll be attending @media Ajax London, 19th-20th November. If you see me, come by and say hello!

I’m an interface developer

2007-08-20T23:17:55+02:00

In his latest post Roger Johansson asks the question Are we designers or developers?. I have a simple answer for that. None of them. Let me explain:

First we have these people calling themselves developers. And boy do they know programming… and math… and… no that's all. Many have a masters degree in computer science, a degree that pretty much tells you that they once gave five years of their lives to programing, how cool is that!? It's not unusual to find people that think in those terms too. You can recognize them by their 10 year old, unmatched, clothes and you'll rarely talk more than 1 minute with them. Very efficient.

Then we have the designers. Either real females, or people very close to females, that just can't stop talking about this abstract thingie-thongie that just like, you know, exploded in a big burst of colors and like… "EHEM! Sorry!", you hear them say, regaining consciousness and flying back to earth. Their clothes, at least you think they are clothes, often look like they where meant for something else. Perhaps for building steel pumps, or killing animals… or both. Well, at least these clothes are matched… or very purposefully not at all matched (not at aaaall like the developers). You can talk with these people for hours, probably even days, and still only touch upon the delicate topic of "a glass of water". Oh, and they "create" things too. Very deep.

So where the heck does the interface developer come into all of this? Well, imagine you have a real project at hand. Real people that need some new website to do their work. Real deadlines, money that switches hands. Smiling business people that promises things and shake hands. Seems like something you know of?

Now, imagine bringing a developer and a designer together in a room, for like a month, working together with this new website. Concentrate hard and try to see the images before your very eyes. Will they accomplish anything?

Hell no! In 5 minutes they will have started arguing about who should be the first one to open the door, and in what way. One talking about the most efficient way to turn the handle, and the other one defending herself by talking about cosmic beams from Saturn. After the first day the developer will have sore cheeks, after being constantly bitch slapped while hiding under his desk. The third day the designer will sit shaking in a corner after the electric shock induced by the steel helmet the developer built. None of them will survive the fourth day, let alone the project.
Very yes! When you meet them after the month has passed you find two harmonic people that smiles to each other and really seem to have connected. They explain to you that the demonstration will be in two parts, first the designer and then the programmer. The designer shows you an app that really touches you, at least you think so, although you not fully understand it. The programmer shows you the other part of the app, one that instantly shows the number 369. They finish the presentation and look at you. You stand up, walk out, lock yourself into a nearby free conference room, and shout with all the power in your lungs: "HOW THE F*#CK AM I GOING TO DO MY TAXES WITH THIS SHIT?!#". When you come back you find them congratulating each other for making the deadline.

You see? There's something missing there. Some kind of link between the two. Someone that can walk into a room with two screaming people and calmly say: "Hey, you both kinda run linux (SuSE vs. Mac OS X), and have a "cold" desktop background (default plain blue vs. modern interpretation of Vasnetsov Snegurochka), what a coincidence!?". There needs to be someone that can walk into the same room the next day and explain that they are talking about two different kinds of "abstract methods". There needs to be a link.

But there's more: An interface developer is silly enough to learn languages that doesn't even have variables. Even though he know that his code will be sent as uncompressed plaintext and will be rendered by broken excuses for programs, he won't cry himself to bed every night.

He will also gladly adapt a design to something it wasn't really intended for, and he even will make it look somewhat good. He will skip adding those fabulous shadows, to make the deadline on time, and still think of himself a good person.

You see, even though "interface" reflect the visual graphic things, and "developer" relate to hard logic code, interface developers are real people, not a combination of two halves. I am one.

Min-width and Max-width template

2007-05-28T20:57:31+02:00

Some problems seem to appear again and again, and one of them is page width. How wide should a site be? Should you adapt to 800px resolution? 1024px? Fully fluid with percentages? Perhaps elastic using em-units? There are lots to choose from. What I've found is that there's one solution that almost always works. You most probably already know it, but I thought it might be helpful for some to have a template you just copy and use.

The idea is to use a fluid width but limit it by using min-width and max-width. As with almost all CSS tricks, we do a little bit of hacking for Internet Explorer 6 (IE6). Link to the working min/max template is available, and an explanation follows.

I'm picking 760px as the minimum width. It fits within a maximized browser window on 800×600 resolution, accounting for scrollbars. Next we need some kind of max-width, and for this I'm going to pick 960px. I could probably go a bit higher but 960 is nicely divisible with a lot of numbers, 3, 4, 5, 6, 8, 10, 12, 15, and 16, making for nice columns (see Gridding the 960). Lastly we need some way to tell the browser to follow the width of the browser window when resizing, and width: 100% does that.

#wrapper {
   min-width: 760px;
   max-width: 960px;
   width: 100%;
}

This assumes that you have a div with id wrapper around all your content.

The above works perfectly in both Firefox, IE7, Opera, and Safari. But (as usual) there's one culprit: IE6. To solve this I'm going to use the fact that IE allows for javascript execution inside CSS files. Have a look at the code below:

#wrapper {
   width: 960px;
   width: expression(
      (document.documentElement.clientWidth > 962)? "960px" :
         (document.documentElement.clientWidth  762)? "760px" :
            "auto"
   );
   height: 1%;
}

First, the element gets a width by means of a IE expression(). The expression looks at the window width and if it's too wide it sets it to 960. It also limits it downwards to 760 pixels. At last we need to set trigger hasLayout on the element, and I usually use height: 1% for that (zoom: 1 works aswell).

Update: Martin suggests we add a default width when IE have javascript turned off. Excellent, added it to the example. The default width will be applied in IE if javascript is turned off.

Update: Matthjis notes that there is a bug in IE6 that causes it to freeze sometimes when using the same number for the conditional as for the max or min-value. Updated the code to reflect this.

(The expression is built up with two tertiary operators, so (condition)? "true value": "false value";, with a couple of numbers in it. Check it, it makes sense.)

The IE6-stuff above will of course not validate (and doesn't work in other browsers), so what we do is enclose it inside a conditional comment. The final min-/max-width example has all the code you need (I've added centering too), but you should of course move the code to an external file.

Happy hacking!

Reverse text with CSS (32 very special hex digits)

2007-05-06T18:13:32+02:00

Sometimes you wake up and feel that big things are moving around you. You follow the news and find that people are uniting over something simple as a number. You read about people calling them rebels.

I think this is a good time to show a little CSS trick.

Let me present two properties that together reverse a string of text: direction and unicode-bidi:

<p style="direction: rtl; unicode-bidi: bidi-override;">
0C 88 65 36 5C 65 14 8D B5 3E 47 D9 20 11 9F 90
</p>

The result, when this is posted on your blog (*hint*) is the following:


0C 88 65 36 5C 65 14 8D B5 3E 47 D9 20 11 9F 90

Am I a CSS rebel now? And are they going to sue me on the basis of my HTML or my CSS?

Transparent PNGs and IE6 standalone

2007-04-28T20:44:31+02:00

I'm one of many that have installed IE6 standalone and it really is a great solution to running both IE6 and IE7 on the same computer. Frequently people claim that IE6 standalone and the real IE6 render things differently but I've never seen that happen. Until now.

Why an alpha transparent image?#

I'm working on a site with several alpha-transparent areas, where authors should be able to switch images and an semi-transparent box should cover half of that image. The users are not skilled enough with image programs to be able to add the transparent part to the image, and adding it to the image would prevent it from expanding when the containing text was zoomed. So I decided to use CSS together with alpha transparent PNGs to solve it. Let’s get to business.

Alpha transparency on modern browsers#

Fireworks, my favourite image editor, allowed me to set the opacity to 60%. It smoothly exported my image to PNG and I positioned everything where it should be. Two background images later, one that the author could specify (added with a style tag in the head, not with inline styles), and one with the transparency. Everything worked flawlessly in Firefox, Opera, and IE7, as expected. Easy!

IE6 and AlphaImageLoader#

IE6 does not support PNG images like that, so I decided to use what I always use to fix that, the AlphaImageLoader Filter. Note that the fix doesn't make the background specified with CSS work, it adds a new element to the page, on top of the element you apply it to. It's also proprietary, meaning it won't validate, so make sure add it to the page by using conditional comments.

One thing you need to know to use the filter is how the sizingMethod property works:

crop - Clips the image to fit the dimensions of the object.

image - Default. Enlarges or reduces the border of the object to fit the dimensions of the image.

scale - Stretches or shrinks the image to fill the borders of the object.

So there is no way to repeat an image as we're used to from CSS. Luckily, since I wanted a solid semi-transparent background repeating and scaling is the same, so I just did:

#breadcrumbs {
  filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(
    src="semi_transparent.png", sizingMethod="scale");
}

Making links work in IE6#

You could think that we've hacked enough to get things up to speed with IE6, but no. Links on top of images loaded with filter does not work. The text of them are selectable, but you can't click them. Fortunately Ingo Chao fixed this in 2005 (some people are WAY ahead) by simply adding an inner wrapper with hasLayout enabled. Thanks Ingo!

Everything set, and tested in Firefox, Opera, IE7 and IE6 standalone. Phew!

Differences between IE6 standalone and IE6#

After deploying the design on the client's server I quickly got a bug report back: "The breadcrumbs have a grey background, not a transparent one". I double checked the client's browser version to be IE6, and tested again locally on my own computer: it worked for me but not for the client. Confused I started looking for another computer with IE6 on (something that was surprisingly hard) I found one at the reception. Gotcha, the PNG was broken there too. I confirmed that IE7 was not installed and downgraded my own to IE6 again. Let's get to work!

After much fiddling with CSS I moved over to Fireworks again. It has three different versions of PNGs you can export as: PNG-8, PNG-24, and PNG32. I tried switching from PNG-24 to PNG-8 and *blam* it worked!

I'm not sure why this works, but after reading the comments on the Multiple IE page, I have a guess. To get filters to work in IE6 standalone two files are added to the IE6 folder. The authors picked them from an updated version of IE6; could it be that Microsoft updated the filters somewhere between my downgraded version and the latest IE6? After Googling I found an update to IE6 called SP1 which changes the behaviour of alphaimageloader. Quite likely, and very tricky to find.

Anyway, I hope this long story taught you something, I sure did it for me: Next time I'll use Iepngfix.htc instead :)

IE7 Zoom Bug: Text width incorrectly calculated

2007-04-28T17:44:03+02:00

IE7 shipped with a new and improved Page Zoom feature that lets you zoom more than just the text of the page. While I think I like it (there's many saying it will make developers lives easier), it has its bugs.

The most recent one I've seen is its failure to correctly calculate text width. I've found no fix for this, except adding a right-margin, something that renders the box too wide instead of too narrow. The calculation seems to a little bit better with font-style: italic;, but it's still incorrect.

It you have a fix, let me know in the comments (the usual stuff does not seem to work).

I guess the Page Zoom is hard to implement, since basic things like that breaks. At the other hand, Opera has had it for years, and Firefox will in version 3. I really look forward to explaining this to customers :)

Separation in the blink of an eye

2007-01-23T10:10:11+01:00

I've seen them so many times: pages where the HTML is mighty fine (!) but the CSS looks like it's taken straight from Dreamweaver. While I hate having to deal with those kinds of designs there is something good about them. They prove the point that HTML and CSS are two separate units, and that it's possible to mess up one of them and do fine on the other. That's after all the point of CSS…

Now. A much more unusual combination is good CSS together with bad HTML. So I put together a little example for you. Separation illustrated (only works in Firefox, I'm lazy). I've made all lines about 80 characters long and removed all other whitespace. Enjoy!

How's that for a company website?

Dear Justin Timberlake…

2006-12-12T12:10:24+01:00

You really are my big hero. When you swing your hips and slide over the floor so the ladies at the front row faint, I know I should have gone for superstar instead of web developer.

That Michael Jackson dance-alike thing you've got going really works; just look at your huge fan base, all eager to be like you. Paparazzi follow every step you make, eager to tell the world about all the little things you're up to.

This is why it surprises me that your website (justintimberlake.com) is using technology from 1996. How would it look if you walked around promoted something like the mullet haircut?! Having a website like yours is just like that, you're promoting a technological mullet!

What's even worse, some of your fans are following suit and use the same ideas for their fan sites, with technology that blocks access for many users, that prevent search engines for finding them, and that adds extra work for them when updating.

So, how do we solve this problem of yours? Well, there's many options available. Let me tell you about my favorite:

Start by sneaking out of your fancy house. Make sure you avoid as many paparazzi as possible, but the idea is not to shake them all off. I'm sure you're much more skilled in these areas than I am. Now, meet me somewhere with a computer that has an internet connection. You probably want to send me a plane ticket: I'm guessing Stockholm, Sweden is a bit too far away from you.

Anyway, the idea is that I will teach you what I know about web development right there. You get a free course from a famous blogger (oh well, semi-famous in small parts of Sweden). The languages used are not hard to learn, don't worry about that, they are designed to be easy. You're a smart guy, so I'm sure it will go smooth. After the first day you will know all about structuring your site, after a week you'll be able to reconstruct your current site with modern technology. After that there's no limit.

When you've mastered web development we'll add a final twist. Accidentally, we'll reveal what you've been up to for the few paparazzi that are still following you. The headlines will be huge: "Justin Timberlake learns secret web arts" and "New way to grow your fan base: Justin explains". It will be great, and the media will go crazy! So, what do you think? Send me an e-mail at emil@emilstenstrom.se if you're interested.

Or, you could just hire someone good (ask for web standards and accessibility)… But what fun would that be?

Update: Sorry Justin, I'm not gay, this is just about web development ;)

IE6 bug: Ignored selector hover bug

2006-11-27T22:04:42+01:00

IE6 bugs seem to pop up all over the place recently. This one is a very small one, but it might affect people that are building tabbed navigation or CSS-based tooltips. The problem is that IE6 ignores selectors in the form of a:hover [selector].

The problem#

Say you want to build a tabbed navigation where tabs move slightly when you hover them (that was how I found the bug). Since you want to reuse the images for the tabs you divide them into two pieces (according to sliding doors). But to do that you need two elements that react on hover. One can be the link but you need one more. So you add a nested span and your code looks like this:

<ul>
    <li><a href="url1"><span>Home</span></a></li>
    <li><a href="url2"><span>Contact</span></a></li>
    <li><a href="url3"><span>About</span></a></li>
</ul>

You cleverly position the span and the link, and add a couple of rules to your stylesheet. You also want the text to move slightly, just like the background, so you add some padding.

a:hover {
   background: url(...) no-repeat left top;
}
a span {
   display: block;
}
a:hover span {
   background: url(...) no-repeat right top;
   padding-top: 10px;
}

You look at the site in Firefox, Opera, Safari, and IE7 and everything works just fine. But what's that? Why doesn't the text move in IE6? You start removing CSS and HTML to pinpoint the problem and end up with a very small testcase with the bug intact.

The solution#

Looking at the testcase I was just confused. I was pretty sure I'd seen IE6 do selectors like that before, but why didn't it work now? HasLayout and the other usual IE6 fixes didn't work.

I loaded up my IM client and started asking people if they knew anything. Simon noted that everything started working when you changed the selector to a:hover, a:hover span. Ok, so setting and then resetting that rule seemed to work. Some further experimenting revealed that just setting any padding to a:hover (setting it to zero worked well) also solved the problem.

That was good enough, an extra a:hover. So here's the testcase with the bug solved. The bug is apparently fixed in IE7.

How to structure large CSS files

2006-11-21T21:55:47+01:00

Many methods exist to structure your CSS. This article tries to describe the method I use. I call it the "Tree method", since it structures the CSS like… that's right, a tree structure. I want to stress that it isn’t my invention; I just describe and give reasons for its rules.

Everyone that has built a bigger site has had to deal with the mess CSS so easily become. There are ids and classes all over the place, and to find where a certain class is defined you usually need to use some search feature in your editor. Matching the other way, from the CSS to the HTML is even harder; you don't even know what file a certain class is defined in. It’s a mess.

The Tree method tries to structure the CSS into logical blocks; blocks taken from the HTML. It also aims to be easy to understand for anyone. No secret codes or difficult ordering schemes.

Order your selectors like the HTML#

One of the problems of mapping between the HTML and the CSS is that they usually differ in structure. The HTML is (if you’re lucky) structured like a convenient semantical tree while the CSS often is ordered by something random like fonts, colors, and positioning.

To make moving between the two worlds easier we want to make them as similar as possible. Is the HTML divided into header, content, and footer? Then make sure that's the three major parts of your CSS as well. Have you put the navigation above your header in the HTML? Then order it like that in the CSS as well! Any other structure makes moving from the HTML to the CSS much harder. You might be able to find all font manipulations in one part of the CSS, but only if you know that this particular developer uses that exact scheme. No, let’s keep it simple.

Here's a simple example where we just order the selectors:

#header { ... }
h1 { ... }
h2 { ... }
#content { ... }
p { ... }
em { ... }
strong { ... }

When grouping several styles into one definition I just put the group above both of their specific styles. #header, #content comes before both #header and #content.

Always use the "full path" to elements#

The above is very easy to get an overview of, but the experienced developer knows that very few sites are that easy. Something you often want is a way to define different styles to different parts of a page. Let’s say you want green links in the navigation, but want to keep them blue everywhere else.

For this we use sub selectors. The selector #navigation a lets you give all links inside your navigation another look. But let’s take that further. Why not always write the full path to your elements? Why not use #navigation ul li a instead? Doing this gives a developer looking at your code a lot of information about how the HTML and CSS belongs together.

Lets add that to the previous example:

#header { ... }
#header h1 { ... }
#header h2 { ... }
#content { ... }
#content p { ... }
#content p em { ... }
#content p strong { ... }

This does change the meaning from before. Before we selected all the level two headers; now we only select headers inside of the header division. Extending each selector with a "path" has made our CSS rules more specific, and specific means more control for you.

This also makes for fewer new ids and classes; just specify the path to an element instead of adding a class for it. Don't add a new class or id unless you really need to.

We still have the issue of "common styles"; styles that we want to apply to elements in different parts of the tree. Since they should be applied to all elements they don’t fit in the tree structure we've built. Instead we make a section in the beginning of the file (or a separate) with just "general styles". Don't add rules to this section if you only use them once in the document, you want as much of your code to be in "the tree" as possible.

Indent your code cleverly#

To make the code even easier to understand I always add indentation (for those that don't know that word: it means spacing in front of blocks of text). Indenting makes the tree structure we're trying to build even clearer, you can easily find the major sections and dig down from there.

Lets add indention to you our example too:

#header { ... }
   #header h1 { ... }
   #header h2 { ... }
#content { ... }
   #content p { ... }
      #content p em { ... }
      #content p strong { ... }

Don't take indentation too far. If you're styling tables and using thead in the markup, but don't change the style of it, you can skip that indentation level. Double indention just for the sake of it is just a waste of space.

Special case: Templating#

We also need to deal with rules that only appear on some of our pages. Perhaps we want the home page to look somewhat different than the sub pages? We solve this by giving an id or class to the body element. Doing this lets me specify styles for just one specific page, and setting the id or class on body makes me able to change anything in the document based on that.

These page specific styles need a place in the tree too. Here I tend to break from the above scheme and put them together with the style they change. So body#page_home #header h1 is one step below #header h1 in the tree. That makes it easier to see all styles for a certain element, instead of scrolling back and fourth (like you need to do if you don't remember your general styles). Keep your templates together with the style they change instead of completely separate.

If you want bigger changes, perhaps a totally different look on some pages, there's no reason to group things according to the scheme above. Move them to a separate file instead.

Each declaration on its own line#

Indentation combined with full paths makes some lines rather long. This means that putting all declarations on one line will force you to scroll horizontally, something we already avoid on our sites. The simplest way to prevent horizontal scrolling is to use one declaration per line, so that's what the tree method uses.

… in alphabetic order#

Grouping of properties is another issue. I've seen grouping schemes based on all sorts of things; from splitting things into "positioning", colors, and fonts, to people adding their properties completely randomly. I've chosen to just order them alphabetically. It's one of the few methods that bring some order while still being simple enough. I've seen total beginners do this by themselves; something I believe is a good argument for it. It's intuitive.

A simple example to illustrate:

#content {
  color: Blue;
  font: 3.4em Arial, sans-serif;
  margin: 0.5em;
}

One complaint I've heard on this method is that it splits up things that belong together. People tend to keep position: absolute and left: 0 together, just to name one such pairing. It annoyed me at first too, but declaration blocks rarely contain more than 10 declarations, and the alphabetic order still makes them easy to find. Also, why handle position different than float and margin?

That's it! By following a few simple rules you can get a CSS-file that's easier to overview, a file that you proudly can give away to the next developer. I can praise its existence all day, but you're the judge of whether it works or not. Why not give it a try in your next project?

Update: Maurice van Creij writes in and says that he's using the same method. A good way to get started is to generate a CSS file from the HTML. He has written a javascript that does just that. Nice! Try generating a CSS file.

Update: Another part structuring your CSS is making sure you don't load too much. I wrote an article previously about combining static and dynamic CSS.

Update: This article got digged to the frontpage. There's a lot of good comments there (but as usual pretty harsh language).

Web development blogs you should read

2006-11-19T04:40:48+01:00

The web is filled with blogs about web development. I'm always looking for good blogs to add to my feed reader and I thought some of you might do that too. So let me list the webdev blogs I subscribe to right now (in alphabetic order):

456 Berea St - Roger Johansson is one of the most well known web developers out there, and it's for a reason. He posts almost daily about things happening in the webdev field. Everything from short comments with links to things to full blown articles.
Creating passionate users - Simply one of the best blogs there is, all categories. Deals with usability and making users happy. The posts are everything from hilarious to spectacular and I often get the motivation to write from here. Read an article or just look at one of the wonderful graphs. You'll love it.
Future of the web - Jesse Skinner writes for all skill levels. Articles vary from basic markup to advanced javascript tutorials. Often with a twist of humour added in the middle of an article. Nice read.
Monday By Noon - Jon posts articles weekly (as reflected in the name) about all things related to web development. His friendly tone and ability to explain things makes this site ideal for people starting out. The good thing is that the same style works for more experienced people too. Try one of the articles, I'm sure you'll like it.
Pixel Acres - Jonathan Nicol combines webdev articles with thoughts on how to deal with clients and co-workers. Well written and qualitative, what else do you need?
Robert's talk - Robert Nyman's blog, mixing personal posts with those that have to do with all kinds of interfaces. Entertaining read that feels balanced and well thought-out.
Rund kvadrat - Blog in Swedish about making money on the web. While this isn't the primary concern for many interface developers we should certainly keep it in mind. Does moving a certain link upwards increase the client's sales?

Well, and then there's all the big ones, but they tend to post too much about the conferences they attended and the books they wrote. Also, all their good articles end up on the big webdev news sites, which I also subscribe to.

Do you have any other sites that should be on that list?

IE6 bug: Encode and ignore

2006-10-11T21:12:01+02:00

I've previously talked about encodings and tried to explain how they work. This time I'll show you a bug in IE6 that is based on encoding problems. Because if you don't watch out, IE6 might ignore whole rules in your stylesheet. If you want you can see the example right away: Ignore encoding example. Open in in IE6 and compare with the rendering in a modern browser.

I've never seen this bug mentioned before so I took the liberty of naming it the "Encode and Ignore bug". If you find it somewhere else, please tell, and I'll use that name instead.

Now. Stylesheets unfortunately have no way of specifying encoding. So you type away in your favourite text editor set to some obfuscate Greek charset and of course expect everything to work. It often does. CSS works with very few characters; mostly you just use the letters A-Z, some brackets, and colons. Since most charsets have those positioned similarly there's no problem. But there are exceptions where you want to use other letters too: inside comments and in the future: in generated content.

Update: Niels Leenheer points out that there are two ways to specify encoding on stylesheets. Either using the method in the encodings article to send a proper HTTP header, or using the @charset "utf-8"; rule. The latter is just a rule you put on the first line of the CSS. Even seems to have decent browser support. Thanks Niels!

So this Swedish friend of mine is learning CSS and I'm helping him out when he notices a strange error. When setting his html document to be encoded in utf-8 IE6 starts to display the page differently. I had never seen anything like it and start digging through the code. After like half an hour I find the culprit: an "å"-letter in a comment!

What he had done was add a comment after one of the colors he used, /* ljusblå */ ("light blue" in Swedish). When IE switches the HTML to UTF-8 the CSS seems to be switched with it. In UTF-8 mode the incorrectly encoded "å"-letter means something else, and IE not only ignores the comment or the line, but everything following it (still inside the current rule). So about half of a rule was ignored. I researched further and found that it was only triggered when the strange character was at the end of a comment.

Interesting, and easy to miss. The solution is of course to encode your CSS in the same charset as your HTML, or if you're lazy put some characters after the culprit. A very simple (and kinda rare) problem, but I thought it might save you an hour of debugging sometime.

How web standards feels

2006-10-11T21:34:42+02:00

When talking about web standards many of us have started using marketing terms. Every day we hear about the bandwidth savings, the increased user base that are able to access your site, how well it affects SEO and so on. But none of that was what got me into all this. Let me tell you about the thing that convinced me: the feeling.

For me the web standards revolution started with a feeling that something was wrong. "There has got to be a better way", was a thought that buzzed in my ears when nesting my tables to create some padding.

I first saw CSS in other people's code, often embedded in style attributes with text-decoration: none; to remove underlines. I started experimenting, but the deeper aspects of how it could change the way websites were built didn't occur to me. It was just another tool to place things where I wanted them, and make things look like I wanted.

At that time I didn't know any server-side language so all my sites where frame based static HTML, often with a fancy javascript enabled select box for navigation. I did use some CSS just to remove the underlinings on my links, but that was it. Something still felt wrong, was this really the best way?

The "AHA!" feeling came much later; I'd love to say a certain moment when I understood but it wasn't a certain text or piece of advice, it grew on me. Suddenly everything felt like it had its place. It wasn't always obvious where that place was, but you could reason your way there. When the strength of CSS occurred to me, it was like finally understanding a tough mathematical formula. Yes!

So go ahead, show me your pretty charts of workday savings, CSS Zen garden remakes, or new techniques you can use. I like them, I really do, but I'm pretty convinced it's the "AHA!" feeling that finally wins people over to the web standards side.

What won you over? Can you convince someone else using that method?

(Inspiration from Motivating others)

Don’t use "Divs for layout" please

2006-09-11T22:07:23+02:00

Proud people all over the world show their new sites and proudly proclaim: "I used divs for layout!"

There's a problem with the above. Every time someone uses the phrase "Divs for layout" they spread the misconception that divs are some special kind of element. Beginners are tricked into thinking that everything you add to a page should be in a div. I've seen great looking pages filled with; you guessed right, only divs.

Some would say that these types of sites actually are worse than table sites. I don't agree. If you look at it in a wider perspective these people at least are on the right track. They are slowly learning and I as I've tried to convey earlier I think it's ok to start out bad and gradually improve.

So, why is it so bad using only divs? Because the idea of HTML is to convey structure. What structure does your content have? Are some parts more important than others? Are you using lists, but not the list element? Find the tags that best fit your particular purpose. There's lots of elements out there. Any good front-end web developer should know (almost) all of them.

Now, could we please stop using the phrase "Divs for layout"? If you want an alternative I would say "CSS for layout". Spread the word my friends!

IE6 resize bug (position: relative becomes fixed)

2006-09-04T22:08:49+02:00

One bug kept popping up on the sites I built, and I was almost going insane. The bug I'm talking about is specific to Internet Explorer 6 (IE6) and has to do with what happens when you resize the page. Here's an example page showing the bug. Open it in IE6 and try resizing the window. Let me explain:

Update: Paula comments that IE7 beta 2 has the same problem. Thanks Paula.

Setting up the IE6 resize bug#

To see the bug in action you need two things: You need to center your page using the body element and you need to be using a fixed width (not percent) on the element. If you use this you will quickly notice that all elements you set position: relative on, will stay fixed on the page when you resize the window. They behave as if you just set position: fixed on them, but only until you reload. It's really a fun effect (if you know the fix).

Example code:

body {
   margin: 0 auto;
   width: 760px; /* Any fixed or fluid width */
}
/* Affects all elements with position: relative; */
#example p {
   position: relative;
}

Here's a live example of the IE6 resize bug with borders added for clarity.

The bug is kinda rare you could say. But using body for centering is a great way of getting rid of one extra container div, so I have been using it more and more lately (IE5 can't handle that, but you don't support it do you?). Anyway, not being able to use position: relative is not ok.

Making things behave as normal again#

Fortunately the fix is very easy. You simply add position: relative to the body element. *Blam* All previous broken elements start behaving like expected again. Here's the same example with the bug fixed.

That's a couple of hours less IE6 adoption time on my next project. I hope it helps someone out there too.

KTH goes web standards

2006-08-23T00:36:28+02:00

Sweden's largest technological university, KTH, just launched their new site and I'm proud to say that I've been responsible for the HTML and CSS for it. I'd thought I'd take some time and tell you about the techniques I used and the reasons behind using them. Let’s start with some background:

About KTH#

KTH is an initialism for "Kungliga tekniska högskolan" which translates to "Royal Institute of Technology" in English. It's the biggest technology focused university in Sweden with almost 17000 registered students for 04/05 (source). Add over 3000 employees to that and you'll start to see the number of people affected by the update. KTH hosts a lot of content, Google reports 1,930,000 pages. Not all pages are included in current the update, but it gives a pointer to what kind of site we are looking at. In summary, a standards based update of KTH affects a lot of people.

Polopoly and the HTML#

I entered the project quite late in the process (Valtech found me), about a month before launch. Most of the back-end work had already been completed and authors responsible for different parts of the organisation had started filling the database with content. The CMS used was a platform known as Cortina, based on top of the CMS framework Polopoly.

Everything was modular and the changes I wanted to do to the HTML nicely cascaded out over the site. When you look at the HTML you'll notice that it contains a lot of strange whitespace, making the code somewhat difficult to read. That's because of the template language used, JSTL, which leaves whitespace after each element. I therefore recommend using the HTML validator extension for Firefox , selecting view source, and then using the button "Clean up the page" in the bottom right corner. That makes the code a bit easier to read for you on the outside. I hope you won't be too upset over that :)

You'll find that all new pages validates as HTML 4.01 Strict (or at least very close, I know of some ampersand encoding errors on one page) and I'm very proud of the outputted HTML. It maps the structure of the content nicely and is easy to browse without CSS enabled. It contains very few elements that are there just as "style hooks" and the id and class names describes the contents of the elements, not their design.

CSS and the techniques used#

The new site makes full use of CSS for its layout. We targeted mainly Firefox 1.5 and Internet Explorer 6 with the new site but using web standards I wouldn't be surprised if it works well in other modern browsers too. For those of you that like fancy terms I can say that the site is a fixed width, zoomable, source ordered, 3 column equal height layout. I'll talk a little about the fancy terms above and explain the reasoning behind them.

Fixed width layout#

Let's start with the most controversial of the design decisions. The site is optimized for 1024×768 pixel resolutions and up. This was a hard decision but given the content of the site, the design at hand, and the target audience we felt that it was a good one. Let me explain our reasoning:

KTH has a lot of information to display. Many different parts of the site need to get exposure and the wider 1024 format made that possible. Many of the images were also designed for the wide format and changing the width would mean we would have to examine all of them and decide how to cut each one. Surf around on the site and you'll see the problems that would bring. Objects in images, meant to be centered, would be offset and some items would be cut. Those content and design issues, together with the somewhat "technological" target audience, convinced us that 1024 was the right decision.

Zoomable layout#

We wanted to make the user able to change the font-size if they wanted to. This meant that quite a few boxes needed to expand with the text, to prevent the text from overflowing them. This was solved by selectively using em units making the boxes expand with the text-zoom. This worked well, and I'm especially proud of the front-page, with all the different elements expanding and collapsing together. There are a few glitches in the zoomed layouts, a couple of pixels missing here and there, but from the testing we have done those are few (there’s currently one line too much content in the middle box, making the zooming uneven, don’t worry about that :).

Source ordering and skip links#

The layout is a rather typical 3 column layout with a header and footer. The leftmost column is for navigation, the middle one for the real content, and the right one for additional information. In terms of importance the content is the most important, followed by the additional information column, followed by the navigation. This called for use of a technique known as source ordering, having the content in one order structurally and in another visually.

Using source ordering is a good way of making it easier for non visual browsers (screen readers, text browsers, and search engines) to get the most important information first. This is not the right article to explain the method in full (some wrapper divs and some clever floats); I'll save that for a later article. Anyway, what matters is that there are some advantages to using this method and that we decided to use it.

Others prefer to be able to jump to whatever place in the source they want. For this, "skip links" are quite effective. Skip links are internal links (links pointing to an id somewhere on the same page) that you put in the beginning of the HTML. Clicking the link moves the focus to the corresponding place in the content. We felt that this was a simple way to provide navigation for users with CSS disabled. The skip links where hidden for everyone else.

3 column equal height#

As many of the column layouts today this one was made with all columns of equal height. It's a common complaint amongst the "table for layout" users that these kinds of layouts are too hard to do with CSS. They are not. An easy technique for doing this is known as faux columns and is simply: putting your columns in a wrapper, floating them left, and setting a background image in the wrapper. The wrapper expands whenever any of the columns expand and shows more of the tiled background image as needed. It's a simple technique, it works well, doesn’t contain any hacks, and is easy to learn. CSS vs. Tables: 1 - 0.

Front page grid#

One of my favourite parts of the site is a feature that most users only will notice over time: The top left part of the front page can be switched between five different layouts, depending on what the editors feel fits their content best. This means that the editors are given a big chance to "design" the front page; a very nice move from the designer.

For me, as the one responsible for implementing this, I had a couple of though days. But I learnt a lot and ended up using a min-height set with em units on the different boxes. This way I could make boxes at totally different parts of the page zoom together. IE6 handles height as min-height so setting "fixed" heights in a separate file for IE ensured that the design worked there too. After using and testing this method for a couple of weeks I must say that I like the it, it gives me a nice grid to work with, but not a fixed one as with tables. This one expands depending on what the content requires. I recommend you to try it out.

Conclusion#

The developers behind the new KTH website have constructed a site that was incredibly fun to work with. I consider myself lucky to having worked with such a good team and have learnt a lot in the process.

Also, as a student of KTH for many years I know that the site will be well received by fellow students; and at the end of the day, isn’t that what matters?

Valtech: my new employer

2006-08-22T21:20:29+02:00

Just wanted to let you know that I have accepted a job at Valtech. My title will be "technical consultant" (which could mean anything, I know :), and you have probably already guessed that I will be focusing on HTML and CSS; interface design in different forms. I started working last Thursday so today was my fourth day and I must say that I really like it there. A friendly atmosphere amongst (very) skilled developers is what I've seen so far, and I know how much that counts when it comes great results.

Anyway. I'm sure you'll just think I'm practicing my sales speak so I'll stop there :) (I’m not damnit!). As I said I'll be working as a consultant, which means I'm dependent on customers wanting interfaces made. So feel free to contact me or my employer (Swedish link) if you have an interesting project you need help with.

(Don't worry, I won't stop posting here, I have a big post about my first project coming up)

Correcting the 20 pro tips (.NET magazine)

2006-07-26T05:01:06+02:00

.NET magazine is a fairly big web development magazine. I've recently been referenced to its articles from many separate places, and often found the articles to be of good quality. The last one, called 20 pro tips, was not too good though, so I'm going to go through and correct it. I'm not trying to attack the magazine here (remember "friendly" in the URL), I just want people to know these things.

The article consists of 20 points that a pro should know. Here are the points I found errors in:

Stylesheets: importing vs linking (point 3)#

The point is that importing is better than linking since many older browsers will not apply the CSS then. This is correct but they also go as far as suggesting developers to add a separate stylesheet for Netscape 4 (NS4). As someone that has experimented with NS4 I can say that its CSS support is bad. Really bad. Considering the near zero percent of NS4 users I would strongly advise against fixing your site for it. That is of course, unless your site logs suggests you have a lot of users with that (old) browser.

There's also a code error here, simple.css is included twice, and the second @import reference should probably be advanced.css. Not a big error but might confuse someone.

Smarter gradient backgrounds (point 4)#

Again a good point. CSS can be used to repeat background images on any element, not just body. This means you can save on file size by replacing big images with smaller ones. The article then suggests using 1 pixel wide images which is something old versions of IE has problems with. A lot of repetitions can easily get the browser very slow so my best bet would be to make them at least 5 pixels wide.

In the code you would be better off using shorthand notation (I know, this is not a big deal). To add an extra pedagogic twist something else than body could have been used:

form { background: white url(background.png) repeat-x; }

IE Box Model Hack (point 8)#

A lot of confusion here. Internet Explorer 5 (IE5) uses another box model than the modern browsers. The padding and border are not added to the outside of a specified width, but instead included in it. This means that if you specify a 500 pixel wide box and add a 10 pixel border to it, it will still be 500 pixels wide. Some say that this is a better way of calculating widths but that's missing the point. The point is that according to the W3C box model the padding should be added outside of the width.

This problem does not appear in Internet Explorer 6 (IE6) if you include a proper Doctype.

So IE5 is broken, should you care? Again, check your logs if people still use the ancient IE5. My guess is that they don't which saves you a lot of work. There's probably no need for this hack.

Also, the Box model hack is Tantek's hack using the voice-family property to add a "}" to your CSS. It's really ugly. The article uses the same name for another solution to the problem: wrapping the offending element in another element and moving the padding to that box. That's a much cleaner way of fixing the problem.

Space saver (point 9)#

Don't use inline styles for styling. Try to keep all your styles in the external CSS file. Two more general ways of saving space across browsers are outlined in my cross-browser CSS article (the star-selector and using a premade CSS file that resets browser defaults.

Format fundamentals (point 11)#

Good points about image formats. Use 8-bit PNGs instead of GIF, it makes you smaller files.

An addition: JPEGs are generally smaller than 32-bit PNGs but that's because JPEG removes information in your image to improve compression. Remember that, if you use JPEG.

If you use PNG you need to know that IE has problems showing them in the exact correct color (technical explanation of the PNG color problem). If that matters a lot to you, use another format (remember that all PNGs change color in IE, so images still match each other). Friendly Bit uses PNGs only.

The ‘title’ and ‘alt’ attributes (point 12)#

Don't use the title attribute unless it's needed to convey what you mean. In the example it does not make sense at all, why repeat the alt text? The main point is still true though, always use the alt attribute and make good use of the title attribute.

Wrapping text around images (point 17)#

Come on! Using the align attribute is going against what was just recommended, use of semantic markup (point 14). Alignment is style and should be added through CSS, nothing else. Adding a strict Doctype and validating will generate an error on this kind of ugliness. Use img.typeOfImage instead.

That's it for now, hope you learned something. I just wanted to make sure my readers know more than the .NET readers :)

Static and dynamic CSS combined

2006-07-16T18:56:03+02:00

Some of you have probably heard "dynamic CSS". It originates from a need to serve different CSS at different times, to different people, or on different pages. You do this by first generating the CSS on the server and then sending it off to the users requesting it. There are problems though, since the CSS gets regenerated each time you lose the advantage of caching. You could send HTTP headers so that the file gets cached anyway, but then it's no longer dynamic right? This article presents a way to both have dynamic CSS that changes on each request, and make sure the user loads it from cache when it can.

How dynamic CSS works#

Sometimes you want to send a different set of CSS rules depending on what page you are on. An example could be if your site was module based. Depending on what page you surf to you might get a calendar, some list of latest news or a small box showing the weather in, say, Stockholm.

The functionallity is not too hard to build with some server side language, but what about the CSS? Is it really necessary to load the calendar's CSS on the news page, where the calendar is hidden? The same thing applies for each of the modules you have on your site; that list of news has certain CSS rules tied to it that isn't needed on the gallery page. You get the point. So how do we solve this? We could do it my generating it on the fly (I'm using PHP here, but any other language would work):

PHP source:

<?php
// This line makes sure the browser handles
// the file as CSS and not PHP.
header('Content-Type: text/css');

if ($module['calendar'] == true) {
   echo '
      .calendar { width: 300px; }
      .calendar table { background: pink;}
   ';
}
if ($module['newslist'] == true) {
   echo '
      .newslist { list-style: none; }
      .newslist li { display: inline; }
   ';
}
[and so on every new module added]
?>

Generated file:

.calendar { width: 300px; }
.calendar table { background: pink; }
.newslist { list-style: none; }
.newslist li { display: inline; }

You save this file as "dynamic_stylesheet.php" and link it like you would if it was a static CSS file. Everything works fine and all the dynamic CSS makes the file sent to the user quite small. Both you and your users are all happy. The site starts growing.

Problems with dynamic CSS#

After a while you start getting reports of the site getting slow. After some research you find that it's in fact the dynamic CSS that does it. The file has gotten quite big and regenerating it each time is a lot of work. So you read up on caching and find that all that's needed is a few lines at the top of your dynamic CSS file:

<?php
header('Cache-control: must-revalidate');
header('Expires: ' . gmdate('D, d M Y H:i:s', time() + 3600) . ' GMT');
?>

This makes the browser load the file from cache for one hour instead of requesting it again. Problem solved! Right? Well, this means that you won't get a regenerated file if you visit a new page on the site. The browser will load the style from cache instead and your users will get an unstyled calendar (or any other module) for an hour. Pretty annoying if you ask me.

Say we solve the problem above and get the page to only get cached on a per page basis. There's still something that feels like a bit of a waste: we require the user to download the entire page again if just one of the modules changes. Say the user moves from the news list to checking out a certain news item. They will probably look pretty much the same, it's just that the news list's CSS won't be needed on the news item page. We would need some way of only telling the browser to only cache parts of the files and make the loading of those parts dynamic.

@import to the rescue#

Caching only fragments of your style is certainly doable in a lot of ways. The easiest I have found is using CSS's own @import command. You simply change the example above to:

<?php
// This line makes sure the browser handles
// the file as CSS and not PHP.
header('Content-Type: text/css');

if ($module['calendar'] == true) {
   echo '
      @import "calendar.css";
   ';
}
else if ($module['newslist'] == true) {
   echo '
      @import "newslist.css";
   ';
}
// ...and so on every new module added
?>

Generated file:

@import "calendar.css";
@import "newslist.css";

This makes the individual CSS files get cached by the browser (just like directly linking a CSS file would) while still allowing each page to dynamically add the style blocks it needs. A simple solution to a hard problem, just the kind of solutions I like best. What do you think?

Finer details of floats

2006-07-09T15:40:06+02:00

The other day I was working on one of those two column layouts. I quickly got into trouble by something I thought was a bug. It was a bug, but not in the browser(s) I thought. Let's go.

A two column layout I said, but this one was a bit different. Each column consisted of a number of boxes, much like a newspaper kind of layout. I wanted the boxes ordered a bit different though: Content editors on the site ordered articles by importance in a single list and when that was transferred to a two column layout I wanted the second most important article to the right of the first article rather than below it. In the HTML source the boxes were ordered like the editors wanted and my job was to make them display in two columns.

"This can't be that difficult" I thought and floated all odd numbered divs to the left and all even numbered divs to the right. Behold the huge gap on the left side. I was stumbled. IE displayed it like I thought it worked, Firefox and Opera both displayed the gap (note to self: it's seldom a bug if both Fx and Op display it the same).

So, where does the gap come from? I went looking in the CSS specification on float positioning and found an interesting list of the rules that govern floats. As with almost all specifications they are not meant to be easy to read, so made a version of them where I use some sample code to explain each of the rules.

This is the sample code you need to have in mind:

<div id="parent">
    <div id="child">...</div>
    <div id="child2">...</div>
</div>

#child { float: left; }
#child2 { float: left; }

#child and #child2 must stay to the right of #parent's left border.
#child2 must be to the right of #child since #child is earlier in the source. If there is not enough space to the right of #child, #child2 must be moved below #child instead.
If #child2 was floated right and #child and #child2 could not be fitted on the same line, they still must not overlap.
#child and #child2 must stay below #parent's top border.
#child2's top border may not be higher than #child's top.
If #child was display: inline; #child2 must still not be above it.
With #child and #child2 both floated left on the same line, #child2 may not stick out outside of #parent's right edge, unless it is already as far to the left as possible.
#child and #child2 must be placed as high as possible
#child and #child2 must be placed as far to the left as possible.

The tricky one here is rule 5. It means that if #child was moved down for some reason, #child2 will have to move down too. Check the example again. See the space above box5 and compare it to the top of box4. Box5 can't be above box4 according to rule 5 above. This is clearly what's going on here. If we made box2 smaller than box1 there would be a space above it by the same reason.

Note that the list of rules is a prioritized list; rules earlier in the list are more important than the latter ones. To Internet Explorer, rule 8 seems to be more important than rule 5. Strange move by IE.

I hope this gave you an "Aha!" feeling, it certainly gave me.

Challenge: Marking up the world cup

2006-07-03T23:25:37+02:00

It's at the end of the world cup and it's everywhere (fotball for those that live in a cave :). It might be that I spend too much time with thinking about the web but I got this little markup issue on my mind. I'm not entirely sure how I would solve it but I have some ideas.

How would you mark up the FIFA World cup 2006 single elimination bracket? If you don't know what it is, have a look at the page linked to. It's basically 16 teams that play against eachother, one to one so half of the teams get kicked out in each step. Next step is with 8 teams, 4 teams ans so on. Pretty straight forward.

Now. Say you got contacted by FIFA to make that chart to put up on the web. Very skilled in Web Standards like you are, you start to think about what kind of data this really is. Is it a list? Ordered, unordered, nested? Is it a table, with the rounds as headers? Is it perhaps a definition list, mapping games played to teams? I don't have any 100% true answers, I'm hoping for your help there.

The second problem is of course the style. What methods would you use? There's quite a lot of boxes to place. Percentages? Can you make it zoom well?

Pasting code in comments to this blog is a bad idea (they just get messed up), so put it up on your own site instead an link to it by leaving a comment. Add a little explaination of your thinking of you wish. Can you do it?

Update: Here's my suggestion of markup and CSS for the world cup bracket.

Reminder: Cross browser font sizes

2006-06-30T18:15:09+02:00

I'm sure most of you have already read the excellent experiment on font sizes but it's important enough to summarice here.

The problem is how to make as many browsers as possible display fonts in the same size, without using pixels or other absolute units. Why shouldn't you use fixed font sizes? Because they make Internet Explorer unable to zoom the text with text-zoom, something that's bad for accessibility.

When you start experimenting with this problem you quickly get into problems. I tested in Firefox 1.5, Internet Explorer 6 and Opera 9 and it was incredibly hard (Want a challange? Don't read on, try it by yourself) even with just those few browsers. Opera has problems with units it seems. If you use em:s you can't use more than two decimals, Opera will round it them differently than the others.

Anyway, Owen Briggs solved this for us in a very simple way:

/* Set the size in percent on the body */
body { font-size: 76%; }
/* All other sizes should be in em units with maximum of one decimal */
p { font-size: 1em; }
h1 { font-size: 2em; }
h2 { font-size: 1.8em; }

From my simple tests it seems to work fine. Did you know?

Beyond the web with CSS: PrinceXML and S5

2006-06-25T00:37:34+02:00

Right now, depending on what kind of presentation you will be doing, you use different techniques. I'm not talking about "presentation" as in design here, I'm talking about web sites, printed paper, slide shows and so on, different types of media. How many of you use the print feature in browsers for your reports? Didn't think so.

Wouldn't it be nice if there was only one set of standards you needed to learn? One set that worked for all kinds of documents. One where encoding problems of differences in alphabets had been solved. One with a huge community of developers that gave of their time to help you with problems. Wouldn't that be nice? Good thing that set of standards exist: HTML and CSS.

Printing like it once was: Word and LaTeX#

The ordinary Windows user uses Mircosoft Word for editing text. Word is popular for its ease of use and hides all the code from the user, instead showing the document like it will be printed. This of course pushes the filesizes up because of inefficient code, just like with any WYSIWYG editor. Word supports the separation of structure and design by it's templates but hides this feature behind menu selections instead of promoting it as the preferred method. It also uses a proprietary format for storing the documents, something that makes sharing documents harder. Word costs a lot, but if you're lucky it's included when you buy your Windows machine.

For scientific work, LaTeX is very popular. LaTeX takes a very different approach from Word at editing text by requiring the user to mark up structure with its own markup format. It comes with a few predefined designs that you pick among by writing some markup in the beginning of the document. The document is then compiled by a command line program into an intermediary format that can be sent to a printer. If you know what you're doing, this makes it easy to get those default designs out fast. The problem with LaTeX is when you do want to change the design. This requires you to dig deep into TeX syntax, a language not known for its ease of use.

Example of some LaTeX code:

\\documentclass{article}
\\title{Cartesian closed categories and the price of eggs}
\\author{Jane Doe}
\\date{September 1994}
\\begin{document}
   \\maketitle
   Hello world!
\\end{document}

Printing with web standards: PrinceXML#

The runner up in the print category is PrinceXML. It's based on ordinary (X)HTML/XML together with CSS and outputs PDF documents ready for printing. The CSS support is quite remarkable, managing to render the Acid2 test according to standard and supporting new CSS3 features like cross-references without problem. The handling of page sizes, page footers and headers comes from the CSS3 Paged Media module and too works well from my testing.

Below you can see an example of what can be done in PrinceXML. First we add a counter that keeps track of what number each block with the classname figure as. Then we add that number before the figure's caption. Lastly we add a parantesis with the figure number too all links that link to a certain figure.

.figure {
	counter-increment: fig;
}
.figure .caption::before {
	content: "Figure #" counter(fig) ": "
}
a[href^="#fig_"]::after {
	content: " (see figure " target-counter(attr(href), fig) ")";
}

I am currently using the program for my degree thesis, a 34 page giant that has quite strict rules it needs to follow for styling. PrinceXML handles things just like it should. It costs a bit, but if you write a lot of documents it's probably worth it. If you can handle a promotional first page a free trial version is available on the web site.

Slide shows like they once were: PowerPoint#

Microsoft is in the lead in the slide show area too with its well known Microsoft PowerPoint. Interestingly PowerPoint goes a long way towards separation with it's easy to use layout modes. You pick a layout from a easy to overview list of options and then just click and type to fill it with your content. What isn't included is design. Much like LaTeX, PowerPoint lets you pick from a number of premade templates but makes it hard to make your own. Given that ease of use is more important for PowerPoint than customization you could say that the product is successful. For someone like me though, that wants to make my own designs, learning how to make PowerPoint templates isn't easy enough to be interesting. PowerPoint also uses a proprietary format and costs mucho dinero, but if you are lucky it was included when you bought your computer.

Slide shows with web standards: S5#

Eric Meyer is the author of a web standards based slide show system called S5. It's rather easy to use for someone used to HTML and CSS. Pick your favourite properly marked up HTML file, add <div class="slide"> around a block of content you want on its own slide, link some javascript and CSS and you're ready to go. The slide show is then run in a web browser in fullscreen mode. It supports incremental display and resizes with the browser window, just like PowerPoint. It's also completly free.

Summary#

It is possible to use HTML and CSS for both web, print and slide shows. In fact you can combine all of them and by using the media attribute on your link elements. That way the same document can be shown on the web, be rendered as a PDF in PrinceXML and displayed in a slideshow with S5.

Isn't this standards stuff quite fantastic?

Real hackers don’t use CSS

2006-06-11T15:15:58+02:00

Back in the old days of 1996 there were two kinds of people. Those who understood the web, often referred to as "hackers", and those that didn't. A hacker could throw together a website in a few minutes, filled with the latest possibilities that the web offered: animated gifs, scrolling marquee text and blinking red text for the really important stuff. It was a glorious time and the hackers really ruled the web. It started growing.

Hackers and designers#

With growth came the designers. They wanted to use the web just like the unlimited piece of paper it was. So they sent their designs, the same designs they had previously printed, to the hackers and said: "I want this on the web". The hackers looked at the designs and didn't like them at all. But the designers were the ones paying their salaries so they had no chance but to do what the designers wanted.

When the hackers started working they quickly came to the conclusion that this was harder than they had predicted. Then a smart guy that really knew his way around the web found a tutorial describing how to do something called "image maps". The hackers cheered! They could take the dreaded designs and put them up on the web as images. Then add transparent clickable areas on top of the images that linked to other images. The hackers' status had been reinstated and the designers looked at the results and were happy, "It looks just like we want" they said.

How to make a website, a hacker’s guide:#

Convert the designers images to JPG
Add an image-map to each one of them
Make sure all links work
Show the designers

Hackers and customers#

Here entered the customers. The company website, that looked just like the designers wanted and was coded just like the hackers wanted, was very slow. Sometimes it took over 15 minutes for the customers to get the info they wanted from the site. Phones started ringing in the hackers' offices and they all gathered to try to solve the problem. This was when the major breakthrough in the web history came.

One clever hacker suggested that they split the images in many parts and used tables to put them back together. The older hackers scratched their heads, "Tables? Where did they hear of them before?”. After some research they found that tables were sometimes used in research reports to show a grid of values. “Just put some images in those cells instead and it will look just like before”, explained the clever hacker. He continued, "… but that doesn't make anything faster. To make the page faster we split it so that we can remove some parts. If there is a large block of blue somewhere we can remove that image and set a background-color on the cell instead!". There was much rejoice and the hackers got to work. Many had problems dealing with splitting the images in the image programs, but after a couple of weeks of training they mastered it.

The years passed by and the hackers got better and better at taming tables to do just want they wanted. Someone came with the idea of putting another table inside the first one. That made the code a little easier to maintain since they didn't require the use of row- and colspan. Additionally that made it possible to add margins to your text, something that made the designers happy. Someone came with the clever suggestion that sometimes text can be removed from the image and written in the cell instead. This made the designers a bit annoyed since sometimes the customers got the wrong font but it wasn't an issue big enough to start a fight over.

How to make a website, a hacker’s guide (version 2):#

Convert the designers images to JPG
Slice the images so that the big one-colored areas can be replaced with a table cell
See if any of the text can be removed from the image and set in a cell
Link each individual image correctly or use an image-map.
Make sure all links work
Show the designers
Show the customers

Hackers and standardists#

The earth shook and the web standardists entered the scene. The standardists said to the hackers, "You are doing things all wrong, you need to redo your sites and learn everything from scratch again". The hackers laughed. Their customers were happy, the designers were happy, they were happy, why should they change? The standardists spoke again, "but your page will load faster with standards". The hackers looked back and remembered how slow their sites once were, they looked at the adoption of high speed internet connections and they reckoned that speed wasn't a problem.

The standardists were now annoyed, why couldn't the hackers understand why standards were better? They gave it one last chance and said "But if you use CSS for layout your sites will be much easier to maintain!". In reply the hackers showed all their table skills they had acquired over the years. One guy had 16 nested tables to show. Another guy used frames to layout his site and had a whopping 25 frames in a spectacular pattern which all the other hackers envied. The hackers really knew what they were doing. They said, "There’s no need learning this new stuff, it will just take a lot of my time and it isn't any better".

How to make a website, a standardist’s guide:#

Look at the design the designer gave you, figure out what parts the design consists of.
Start writing the HTML corresponding to those parts. Try to avoid adding elements to the HTML just for the sake of design. Make sure all content in the design is represented in the HTML (text preferable).
Link a CSS file to your HTML and start adding style to the document. Test in the modern browsers and read guides with common bugs to fix problems you encounter.
Show the designers and explain why they can't have it look just like it would on paper.
Do user testing to determine things work or not.
Release it to the customers and be open to feedback.

Conclusion#

When you, as a standardist, talk to hackers about standards, keep in mind that they are good at what they do. There's a reason they are doing it a certain way and it works. Just throwing out a "Tables are so -96" won't bite; you need to be smarter than that. Don’t forget that you were once in the same seat, and use the same arguments that made you switch.

And yes, that guy using frames for layout in the text above, was me.

Concept: Four layers of web development

2006-06-03T18:45:07+02:00

When thinking about web development on the client side, I tend to think of four different layers. Any (well built) framework will cater for all of these layers and all good developers will be aware of them. The layers I'm thinking about are: Data, Structure, Design, and Behavior. This article discusses all four of those and explains how they relate.

Data layer#

The data layer is the most important one and strangely the one most people get confused about. HTML is not the data layer, the content is. The data layer is the raw data that you are presenting, the text, the images, the sound, the video, whatever content you want to serve. For bigger sites the data is often stored in a database or perhaps XML files somewhere and then processed server side every time someone wants to access it.

This layer is also where all websites should start. What content do you have? If the content is bad no pretty design or fancy Web 2.0 technique is going to cater for that. In fact, content together with bad uses of the other layers, might still work!

One last point to make about data is that you should make sure to use the best possible media for representing your content. If it can be text, use text! Don't use images for text, narrate your podcasts (or at least provide a text-summary), put your videos online with descriptions to them. Having that text there helps you convey your point, search engines will find you, your users will be able to skim read while it loads and disabled users will get access to at least some of your content.

Structural layer#

The structural layer is where the much misunderstood HTML comes to play. HTML's job is to take the data it has received from the data layer and add some structure to it. Mark up what parts are headers, make sure lists get the HTML that best describes them, split the page up in the important parts and so on.

HTML also adds some semantics to the data but since it's quite a limited dictionary we have to work with I believe this is secondary. If you happened to have the kind of data that HTML happens to catch with its elements be sure to use them, if not make sure you at least capture the structure of it.

You know you have done this level right if your site works with nothing but data and structure.

Design layer#

The design layer is where you define the looks of your data. Design requires a good basic structure to be useful. On the web you should use CSS for this layer, a language that has been built upon the idea of a solid structure and is remarkably powerful. As you know CSS targets certain elements and then defines their look. Without a solid structure this is not possible.

Good designers often point out that only working with the looks of a site will not accomplish good design. They also work on the structural layer by making sure structurally important content gets the most exposure in the design. This is also strengthens the idea that structure is a layer upon which design works.

Behavioral layer#

Behavior is the last layer I'm going to talk about. It's the one that's least important; data, structure and design are all more effective in conveying your message. None the less, added behavioral functionality can be powerful if executed properly on top of the other layers.

Javascript is the most used language for adding new behavior to websites. With the whole Web 2.0 and AJAX wave we are experiencing many new sites that adds a behavioral layer without even thinking about it. We should be careful; becoming dependent on the new behavior (the site not working without it) means you will lose many potential visitors, the most important single one being search engines. Behavior should always be added separately and only enhance the experience for those that has it enabled. This is what's called unobtrusive javascript.

Putting it all together: four tier web development#

Putting all these four parts together we get the following:

Is this the same mental model you use? Let me know through comments.

Update: Threehouse has an image up showing the four layers in the context of javascript connection the layers together.

Inline CSS should not be allowed in strict doctypes

2006-05-28T22:48:10+02:00

As many of my readers already know all pages should include a doctype. The doctype tells the browser (or other user agent) what kind of document it can expect and what standards it follows.

You can divide doctypes into two categories. The first category consist of the transitional ones, the ones that allow old syntax and still validate, and the other one consist of the strict ones. I have repeatedly recommended the strict versions for a simple reason: it's the best ones for separating design from content.

Just to show an example, transitional allows the following:

<body bgcolor="blue">
<center>

Strict, by its very nature, requires the use of CSS instead.

What I find strange is that inline CSS is valid in strict. Inline CSS is when you use the style attribute to set design information inside of the HTML. As an example the two deprecated pieces of code above can be done with:

<body style="background: blue">
<div style="text-align: center">

How is that any better than the transitional versions? Inline CSS goes against all the logic involved in the idea of two distinct doctypes. Why should you want to include design information inside of a document that you just explicitly stated would separate the two?

I hear the obvious reply: "What if I load design info from a database? I need to use inline CSS then!". To me, that sounds like a perfect case where you need to go transitional, if you can't manage to separate the two - don't.

Strict doctypes are for documents where the webmaster has taken the time to clearly separate the content from the design, not other hybrids.

Improving the web; Blogging, Google and Web standards

2006-05-20T00:12:31+02:00

The web has really changed the way we do things. Remember those paper timetables? No need for them anymore, we simply type in our destination on a box and get a step by step guide for what to do. Finding recipies? No need to look through books any more, just type in a few ingredients on your favourite food site. The examples are countless but there is no time for us to sit back and relax just yet. The web can be improved. We can get more people to publish their stuff online, we can get better tools for finding relevant info, and we can make the information accessible to more people. In this article I'm going to talk a little about each of those three points.

We need more information#

We need more information. People will argue and say "No, there's enough junk online already" but I don't care. More information is a good thing. The web is currently not a good representation of the world at large. The is a million technology weblogs and five about shoemaking. Another million sites about how it's like to be a teenager today and another five about life as an 80 year old. You know what I'm getting at? We need a wider variety of people on the web, not only people that are just like us.

Another thing to remember is that text only is one facet of information. With today’s bandwidth available we can look at live video from all over the world. We can listen to live radio and music just as easy as we read the web. We then have a look at availability. I'd say that at most one out of 1000 people publishing on the web is using something else than text (This site is no exception). I know that there are people out there that have a video camera, that have a microphone, and know how to put it up on the web. But they don't.

This lack of variety in information is a real problem. It builds barriers towards people we just don't know anything about and it fools us surfers to believe the world is smaller than it seems. "No, there can't be any problems with the Chinese government, we would have heard about it!” or what about "Christianity must be the biggest religion, just look at what people are writing most about".

There are ways the tackle this problem and the concept of blogging is one of them. It makes it easy to almost anyone, anywhere to just start writing in a few minutes. You can be anonymous, you don't have to tell the truth, there's no age check and it doesn't cost you money. This opens up to real diversity on the web. The technology exists, what we need to do is get people online and make them use it. So tell your friends to pick something they love or hate and blog about it. We need more information.

We need relevant information#

The next step, after we have gotten a larger and more diversified web, is to start filtering it. I'm not talking censoring here, I mean filtering in the sense to "filter what you want". This can be tied to a certain task you want to accomplish or it can be a strong interest of yours that you want to follow. It doesn't matter which, what matters is that there are ways to easily find relevant information.

There are many ways of determining relevancy on the web and the one most successful is linking. Links are like recommendations; anyone that links to a site is telling their readers a certain site is recommended. It's relevant for the subject at hand and it contains good information. If you are just looking for random information about something looking at a few links might be enough. For example, if Roger Johansson links to something web related I can be pretty sure it's good.

For more task oriented queries we need something else. If someone is looking for a plane ticket they will probably not know who the authority in that area is. Google is the search engine that has had the greatest success with solving this problem and the solution is simple. Gather the recommendations for as many sites as possible and reply to queries with what most people recommend. Just think about it, if 100 people recommend FlyPlane and 1000 people AirFlight, who would you go for?

In reality it isn’t that simple, but in essence that’s how search engines work. Something that is important to note is that the system encourages people to write good content. Why is that? Simply because good content gets linked to, and more links means it's probably more relevant. This way Google and all the others are actively encouraging people to improve the web. Good, isn't it?

Making information accessible#

So, we have lots of information from all over the world and we have the tools to find the most relevant info at any point. The last step is actually delivering the information to our users. This is where web standards come to play.

In the early nineties browser makers raced to get the coolest new features included in their browsers. The result was things like blinking text, different methods of representing "layers" and scrolling text. Web developers had a hard time keeping up with browser differences and often you had to construct two or more separate pages to send people to depending on what browser they used.

The W3C acknowledged this and presented a solution. Instead of browsers trying to find the coolest additions, let a standards organization handle the new additions. Let hundreds of people sit together and discuss new ideas long before they are implemented. When everyone has had a chance to say their meaning and problems has been eliminated you release a document presenting the new features together with implementation details. Now the browser makers can race over who supports the most recommended standards instead, and webmasters can just pick a set of standards that is well supported. One way of doing things instead of many incompatible ones.

Right now, the current recommendation is to use the strict versions of HTML of XHTML for structure, CSS for design and Javascript for behaviour. Using those standards means that your site is accessible by more than just the few browsers you have tested with. Both people and automated crawlers that that are after just your content can easily skip your design. People with old browsers will still be able to view your content, even though they don’t see the design the still get the content.

If you adopt the recommendations I mentioned above you have gotten quite far, but there is more. Accessibility is an area in web development that has gotten far too little exposure. It's focused on making it easier to people with various disabilities, varying from broken arms and color blindness to dyslexia. Previously people cared about old browsers, it’s time for a shift towards caring about people instead. Read up on accessibility, Mark Pilgrim's Dive into Accessibilty is a good start.

In summary#

I've gone over three areas where I believe there is space for improvement on the web.

More diversified information. Get your friends on the web!
Better tools for filtering all the information depending on what we need. Build new and better tools for doing this!
Use web standards and care about accessibility. I try to help in this area with the help of this blog.

Now I'm interested in your comments. What do you think? Are there more areas we need to look into?

Emulating tables: Automatic width

2006-05-07T01:59:50+02:00

Moving from tables to layouts based on CSS is a tough move for many. Things don't behave the way they use to and some effects are much harder to do with CSS. This article is about one of the tricks you might want when trying to get table-like effects using CSS: the dynamic width column, where you let the width be decided by an image. You may jump ahead and look at the dynamic width column right away if you want.

The problem#

What we are after is a way to emulate a simple effect when using tables. Look at this code:

<table>
    <tr>
        <td><img src="/files/post-media/huvet_southpark.png"></td>
        <td>Some sample text here</td>
    </tr>
</table>

The code above will render two columns, and the width of the left one will be equal to the width of the image. This can be useful on a very dynamic site, where you don't know the width of the image and so you don't want to set it using CSS.

Looking at the code above you might see the problem though. Tables are for tabular data, and and image and some text are certainly not tabular. We need something better.

The solution#

When you start to look at the problem you quickly realize that the image needs to be floated. There is just a few ways to put things side by side in CSS and floating is one of the few ways that works like we want it to. The image moves to the left and text flows around it. This looks all nice but if you add a border the other column you see that they are not really side by side. All that has happened is that the text has been moved to the left, not the container.

This can be solved by setting overflow: auto; on the right column. After setting this the container nicely contracts and sits where it should. IE6 doesn't play by the same rules though. Here you instead need to set height: 1%; to make it behave.

This final CSS looks like this:

img#cartoon {
   float: left;
}
#example div {
   overflow: auto;
   height: auto !important;
   height: 1%;
}

Update: After Rowan Lewis suggestion I now use height: auto !important; to send a correct height to modern browsers. IE6 does not understand !important and will therefore overwrite the height with the 1% value.

And the following HTML:

<div id="example">
    <img src="/files/post-media/huvet_southpark.png" id="cartoon">
    <div>
      Here's all the text
      Even more text here!
      Even more text here!
      Even more text here!
    </div>
</div>

Have a look at the example of the table-like behaviour.

Open letter to the IE Team

2006-05-03T13:37:07+02:00

Dear IE Team,

I have carefully followed the development of Internet Explorer 7 (IE7) and really liked what I've seen. Especially the CSS bugfixes are wonderful, the tabs are really needed, and the team talking about the development on your blog is really nice too. You are doing a great job and you should receive credit for it.

One thing keeps bugging me though. Soon you will release the browser on Windows Update and people will automatically start upgrading, replacing their old browser (IE6) with the new version. I use Windows Update so my version will be upgraded too, and there's the problem: I'm a web developer and I need to test my sites in more than one version of each browser. IE7's ability to replace IE6 instead of working standalone will for me be a pain. As I see it I have the following options:

Get another computer. On that other computer I could have the old version of IE installed, with security bugs and all, and then move from computer to computer while testing.
Install a virtual machine on my current computer. This means I could have the old IE6 on the virtual machine and test there. While this sounds pretty good it still means I have a reserve a large part of my computer for IE6 testing, something that feels very strange to me. I looked up what Microsoft Virtual PC costs and found $129, an expence that a student can't take just like that
Drop support for IE6. If you really could get all your current users to upgrade this would be a viable option. The problem is that you will not, at least for the comming five years. You will have the non-XP Windows users that won't get the oppurtunity to upgrade, you will have the modem users that will not have the bandwidth to upgrade and you will have the clueless people that will have no idea that there is an upgrade available. This is not a problem for you, because you are just working with the new version, but it is a problem for me as a web developer, because I have to deal with the old version for a long time still.
Hack IE7 to work standalone. I have found some tutorials on how to make IE7 standalone but the problem with that is that it's a mess. Look at it, copying of registry entries, DLL files, and EXE files around. If this is what you want us to do, why not ship a nice and thoroughly tested version of this script yourselves?

So, this is my dilemma. Which of the options do you want me to use?

Web Development Pack

2006-04-24T17:20:05+02:00

When I move to a new computer, I keep installing the same tools again and again. I always have problems finding them because they are spread out all over the net. This article is an attempt to gather the links to the important web development tools in one place, as a resource for beginners.

(Update 2009-02-16: This is an update to an old article, I can't have old stuff polluting the site)

Browsers you need#

For modern web development today it's important to test in more than one browser. The current best practice is to first test in one that has good support for standards and then move on to the older ones and fix your site for them.

Mozilla Firefox is a great browser and a serious challenger to Internet Explorer. The best web development feature of Firefox is all its extensions that are available. I have made a special section about good extensions to use below.
IE Tester helps to test your site in Internet Explorer. It is the browser that is used by most people over the world (because it ships with Windows, not because it’s the best one). The good thing with IE Tester is that it lets you run multiple versions of IE at the same time. No need for virtual machines. Consider hard if you need support for IE6.
Safari / Chrome are two good browsers based on the webkit rendering engine. Webkit's greatest merit is that it was one of the first browsers to complete the Acid2 test. Safari is also very popular on the Mac, so you probably you make sure it works.
Opera is another good browser with a little fewer users. The Opera team has put great effort to make any standards compliant site work in Opera so there’s no reason why your site shouldn’t work. There’s a few quirks though and it can therefore be worthwhile to test in it.

Firefox extensions#

Firefox extension system has made it possible for thousands of developers to make little snippets of code that add useful features to Firefox. There are a lot of extensions out there and so I’m sure I’m missing many but here’s the list that I just can’t live without (related to web development):

Firebug is the best thing that has happened to front-end development. It lets you click elements in the browser, and shows what HTML and CSS is needed to render the element you clicked. Excellent! Makes everything so much easier. Allows manipulation that is updated in realtime
Web development toolbar is an extension for Firefox that enables all kinds of useful features. It can give you borders around all your elements, it allows you to edit CSS in a sidebar and see the changes instantly, it allows you to remove images just to name a few. I can’t work at all without this one.
HTML Validatior is the third must-have extension. It validates pages you visit on the fly, and shows a small red cross in the statusbar if you don't validate. Great way to quickly discover errors in your HTML.
ColorZilla is extremely useful for finding out HTML color codes from images, something you will do a lot when coding graphic intensive pages.

Other programs you might need#

You're not only going to be surfing to your site, you're also going to need a program to write your code in, a graphics editor, and a FTP program to send your files off to the server with.

I've always had problems finding a text editor that I liked. They either don't allow me to use the windows shortcuts I've learned to love, don't allow proper color coding of the languages I care about, don't handle setting up project in an easy enough manner, or handle character encoding badly. So I've just resorted to using whatever editor that fits best with the environment I'm currently working in. Netbeans for Java, Visual Studio (non-free) for .NET, and Komodo Edit for Python and PHP.
Fireworks (non-free) is a graphics editor that lets me work with both vector and bitmap files. It allows filters that can be easily removed and tweaked without breaking the original. It also has a nice slice feature that let's me export parts of design mock-ups quickly. There's no free program worth its name.
FileZilla is a good open-source FTP program I keep coming back to. I fire it up and it just works every time. It's fairly feature-rich but you don't need to know all of it to get it going. If you do want to play with advanced stuff it's there. Easy to use, fast, many features.

That's it. All that is left is for you to either agree or disagree.

What beginners ask for (and what I tell them)

2006-03-27T22:22:07+02:00

Being in an IRC help channel lets you meet a lot of people. Many are fresh beginners that just wrote their first lines of CSS and stumbled over something they found strange. When you look at their questions from a perspective you quickly find that many of them are repeated and come back over and over again. This article is an attempt to list a few of the important concepts that people seem to have trouble with.

Separation of content and design#

Separation is the fundamental idea that CSS builds upon. Ten years ago there was only one way to make pages that worked across browsers: you mixed everything in one large file and copied that file if you wanted pages that looked similar. Then Håkon and Bert came up with CSS and things got much easier. Their idea is to make the code easier to maintain by extracting everything that has to do with design, put it in an external file and link to that file when we want a certain look. CSS is all about design and HTML is all about content and structure.

Even though this sounds good in theory there are a lot of cases where it's hard to determine whether something is design or not. Is the company logo design or content? When you start thinking about those kinds of problems you know you're on the right track. You can find a couple of examples of the separation I'm talking about in my beginners guide.

Clearing floats#

Floats and clearing is another problem almost everyone has in the beginning. What I like to use when I explain how floats work is the old align-attribute on images. Long time ago, when you only could use HTML for design, and wanted the text to "flow around the image" you used:

<img src="/files/post-media/image.jpg" align="right">

The above code is clearly design (placement of the image) so we should use CSS instead of HTML for this.

img#id_of_image { float: right; }

CSS is not restricted to float only images, all elements can be floated. This opens up to both new layout methods and confusion. To place three divisions side by side, just give them a width and float them. You can see a layout based on this in my article about layouts or the 3-column example.

Clear is also important to know of. Setting clear: both; on an element makes it move downwards until it's below all previous floats. That was how the footer in the above example was made.

Floats and clears are not always easy to understand though. One thing people often ask about is what's wrong when their container isn't expanded to contain everything inside it. Eric Meyer excellently explains both that problem and its solution in the article Containing Floats.

Validation is a timesaver#

Why is validation so important? Because I just can't stand you forgetting your alt attributes? Because I think that valid pages are better than non-valid? No and No. It's because validation finds the simple errors. If I misspell width or some other property a validation will find it. If I nest my tags incorrectly a validation will find it. If I forget to close a quote in a link? A validation will find it. Validation is a great timesaver because it actually finds all the small errors that humans have trouble finding. To make validation even easier I use the Html Validator extension for Firefox. A little icon in the bottom right corner tells me when I have an HTML error. Validation is a great tool, use it.

Accessibility is not about blind users#

It could be that I'm trying to explain why someone should add labels to their form. I say something in the lines of:

Me: "Not having labels hurts your site’s accessibility"

User: "But I don't have any blind users on my site!"

Accessibility is about making it easy for as many as possible to access your content. With, often simple, means you can make it much easier for people to access your site. Let me give you some examples or people your can help by thinking about accessibiliy.

User	How you can help
Partly color blind	Don't use only color to convey information
People unable to use a mouse. Either because of some physical disability or simply that they are linux hackers and dislike it.	Make sure keyboard navigation works as intended
Young users or users with another native language than yours	Don't overcomplicate your text
People with a slow connection	Mind the size of your site

The list could continue for a whole article. People from those groups would very much like to see your site and buy your stuff just like anyone else. Read up on the basics of accessiblity, it helps a lot of people. Robert Johansson has written a nice article about how you could evaluate your website's accessibility.

Some things are harder to do with CSS, that does not mean CSS is a bad language#

People that are switching from tables to CSS often complain about what a bad language CSS is for not supporting [insert favourite feature]. I did so too in the beginning. What makes me like the language is all the other powers it gives me. It is not possible to do everything as easily with CSS as it is with tables. But other things are much easier, and some things aren't even possible with tables. There are good parts and bad parts and to me the good parts greatly outweigh the bad ones.

Equal height columns#

The last thing I'm going to talk about in this article is equal height columns. The problem is that your have two or three columns of content that stretch down the page. You want the columns to stretch as far as the longest column but the content inside does not expand the columns that far.

This problem is most easily solved by a technique known as faux columns. Add a container to the columns you have and then add a background image to that container. The image will repeat down that page and make it look like your columns take up exactly as much vertical space. I've added a faux column example for you to look at.

Challenge: What’s the worst you can do?

2006-03-11T16:09:26+01:00

After reading through the comments on my levels of CSS article I find that I few people seem to think that the article is a way to ridicule beginners. It's not. It's a way to document the steps that I think I have climbed. Some people also thought that this set of levels is a good indicator of how good sites you will make. That's also false. Being Level 5 or 6 in the list means that you are a good coder, nothing else. It does not mean that a site you make is any good, I've seen many sites that have great code but that still makes me want to kill someone. Don't confuse good web developers with good coders. "Don't be a rotten standardista" as Molly Holzschlag would put it.

The challenge#

To give you a perspective of how bad it really could be I'm challenging all the readers of Friendly Bit. It's kind of a competition (with no prize) about who can make the worst site. The rules are simple; you are to construct a page, using HTML and CSS (and Javascript if you think you need it) that has a design that is as hideous as possible. I want pages that make my eyes bleed, that make small children cry and makes Maddox write hate articles about you. Think of all the good things you've learnt and do the opposite.

Inspiration for a truly hideous design#

I won't be giving out any prize but what I can do is help you with some ideas of bad code.

Make use of the <marquee> tag. It makes any content inside it scroll in the speed and direction you choose. Did you know that you can wrap <body> in a marquee tag? That's right, your entire page will move automatically. You can also nest several marquee tags inside each other. Ohh yeah!

Another good tag you can use is the <blink> tag. Can it be applied to, say, a table? I hear you ask. But of course. You can have a full screen blinking table on your company homepage.

Continuing with the good ideas we have the oldschool frames we all have come to like. Did you know that there are no set upper limit on the number of frames you can load? You can have thousands of them! You can even mark up a whole tabular grid with frames alone.

This challange is about terrible code as much as it's about terrible design. So don't go with well-formed or the basic foundations of HTML. Did you even try putting tags inside other tags? <font <font size="2"> size="3"> is quite fantastic don't you think? Make your page upside down by adding the <head> below the <body>, but only after you have added your own <neck> tag to the mix. Surprise me!

How to accept the challenge#

To join all of this you just have to make the page, put it up on your server and link to it here. Post a link as a comment or simply trackback (link to this post) from your own blog and it will show up here.

Finally: Don't forget the lesson behind all this. When you see a site with bad code, know that there's a lot of much worse sites out there.

Interview: Why did CSS succeed?

2006-03-02T12:14:22+01:00

When you are looking to reach the upper skill levels of a technique it's always a good idea to start with looking back. The history often says much about the fundamental building blocks and why they work like they do. What were the basic driving forces behind it? What need did it fill? When examining those kinds of questions you can get a far deeper knowledge of what you are working with.

In an attempt to gain some of that knowledge I contacted the authors of Cascading Style Sheets, level 1 (CSS1, notice the nice background image) and asked a few questions about the development on the first CSS specification.

Håkon Wium Lie promptly answered my questions. He's currently the CTO of Opera, making one of the better browsers out there. This was done by email so don't be surprised if earlier answers reference later ones :) Here's the interview:

Emil Stenström:

First I'd like to extend a big thank you from the web development community for coming up with the fantastic idea that is CSS. The language has become a huge success and thousands of people daily exchange ideas of how to best use its power CSS. New people also learn the language each day and big corporations rebuild their sites because of it.

Håkon Wium Lie:

Thank you for your kind words. As we'll get back to later in the interview, CSS is the result of many people's ideas and efforts. Without a strong community around CSS, the specification would not have succeeded.

Emil Stenström:

1994 when CSS where first proposed there were many different languages available that also made it possible to style web pages. What arguments where there that made people choose CSS instead of any of the others?

Håkon Wium Lie:

There were, indeed, a bunch of proposals on the table. First, there were the style sheet languages that had been developed before the web. FOSI, DSSSL, and "P" should be mentioned. Second, there were around ten different style sheet proposals for the web. Several of them were based on earlier languages, but most of them brought new ideas to the table. There was also a healthy interchange of ideas and CSS picked up its shares.

In the end, I think CSS succeeded because it took the web — as opposed to a paper-centric publishing model — seriously. The web introduced some new requirements for style sheet languages, including progressive rendering, screen-based formatting (e.g., pixel units), media-specific style sheets, link styling, and a certain robustness in case one resource (e.g., the style sheet itself) is missing.

It so happens that I'm about to defend my PhD thesis on this subject. So, if you're interested in the history of style sheet languages in the context of the web, I can offer you a few hundred pages to read.

http://people.opera.com/howcome/2006/phd

Emil Stenström:

I can imagine that getting the language from the idea stage to it being accepted by the W3C as a recommendation was anything but a walk in the park. There where surely other authors that wanted their language to succeed instead. How much did work did you put in to promoting the language? Did the features it contain work in promoting the language in itself?

Håkon Wium Lie:

Most of the ten proposals I mentioned above were not serious contenders. The one proposal that had the most backing, beside CSS, was DSSSL-Lite. Many people in the SGML camp were upset when W3C (on March 5, 1996) announced that The style sheet efforts will be based on Håkon Lie's Cascading Style Sheets (CSS) initiative, to be further refined by a group of experts within the W3C.

http://www.w3.org/Style/960305_News.html

One important reason for W3C promoting CSS was support from implementors. Microsoft, amongst others, had committed to implementing CSS at a Style Sheet workshop held in 1995. Compared to DSSSL-Lite, CSS was easier to support since it wasn't Turing-complete and didn't require a transformation step. So, in a way, it was the simplicity — the lack of features — that won people over.

The fact that Microsoft haven’t followed up on their promises of supporting CSS and other web standards is very sad. I proposed the Acid2 test to support them along the way:

Emil Stenström:

CSS got accepted as a recommendation and browsers started to implement the language. This was the real test to see if the specifications where clear enough. Are there sections or parts of the first specification that you wish that you had written differently or emphasized more?

Håkon Wium Lie:

All in all, I'm very happy with how CSS1 has stood the test of time. Compared to many other standards, there are few ugly compromises and not much feature creep. Looking back, I probably would have argued to drop a few features that havn't seen much use (first-letter and first-line), and I would have split a few overloaded properties ('display' and 'white-space' come to mind).

I CSS2, I think we should have seen the rise of JavaScript as an opportunity rather than a threat. A 'style sheet object model' should have been built into the thing rather than being an afterthought.

Emil Stenström:

Many people shift between thinking about CSS as something written by a few people, perhaps even only the two of you, and it being written by an organization of thousands of people. Which of those are closest to the truth? How many are approximately involved in the writing of a specification (ie. CSS 2)?

Håkon Wium Lie:

Lots of people have to be involved. Otherwise, a specification is likely to die a lonely death. In the beginning, however, it's better to be only a few people in order to establish a foundation quickly. For CSS, that happened in the summer of 1995 when Bert Bos and I worked intensely around a white board for a few weeks. He came up with many key ideas, including the forward-compatible parsing.

After that, CSS became a work item of the W3C's HTML working group before getting a working group of its own in 1997. CSS2 came out of that working group. I would estimate that around 10-15 people were actively involved in working out the design of CSS2, while four people are listed as "editors". CSS1 didn't have "editors", it had "authors".

Also, there was a strong community of users on the www-style mailing list that helped us shape the specification, write test suites, and complain in all the right places and do all the other things that are necessary to make a web standard succeed. The real work starts when the specification is finished…

Emil Stenström:

Attribute selectors and generated text where available in one of the early browsers, Argo, over 10 years ago. Those features were not included in the first spec but instead moved to CSS 2. Why were they moved and do you have any ideas of why they are still not implemented by some browsers? Do you have any ideas of things we could do to get implementations available faster in the different browsers?

Håkon Wium Lie:

Generated content is very cool and it's sad to see that Microsoft's IE7 — coming out 8 years after CSS2 became a Recommendation — will not support it. This is remarkable since Dean Edwards has added support for generated content in his "IE7" project; by adding a link to a JavaScript on our page, IE will happily display CSS2 generated content. So, I believe the decision not to fully support CSS in IE is political rather than technical. Thankfully, there are some other browsers around. May I mention Opera, here?

http://www.opera.com/

Emil Stenström:

Talking more about the future of CSS, there is much work going on with the CSS 3 spec. We will see text shadows, gradients, and multi column layouts, just to name a few. Which new features are to most exciting to you? Is there anything that isn't in the spec yet but will soon be that you want to tell us about?

Håkon Wium Lie:

Personally, I'm very exited about the print-related features. Being able to write our book in HTML and style it with CSS was great fun and confirmed our belief in CSS beyond screen use. It required a few features not present in CSS2 and they will be described in CSS3.

http://www.alistapart.com/articles/boom

Just like I got involved with Opera to ensure that someone implemented CSS correctly, I’m now also involved with Prince to ensure that someone gets CSS printing right.

http://www.princexml.com

Emil Stenström:

Thanks again for taking the time to answer these questions. Perhaps some of my readers will be the ones coming up with the next big thing™.

Håkon Wium Lie:

Cheers

Min-width for IE revisited

2006-02-22T21:41:56+01:00

Much has been written over the years of how to get min-width to work in Internet Explorer (IE). Min-width works almost like width but it only sets a lower bound on the width ("You can't get any narrower than this!"). Very useful when building layouts that are supposed to work on many screen resolutions. This article is a remake of Stu Nicholls variant but removing most of the divs he uses. An example is availiable.

If all browsers supported standards#

The question that triggered this article was someone that wanted the page to be 90% wide but no less than 500px. For those of you that know CSS2 you know that this can be done by simply setting:

#element {
   width: 90%;
   min-width: 500px;
}

Since no versions of IE support the min-width property we will have to try something else.

What has been done before?#

To solve this problem there has been suggestions of all sorts of things: Javascript, Proprietary CSS expressions, One that doesn't handle both width and min-width, and One using four (!) extra divs. When looking at the different solutions I quickly came to the conclusion that I didn't want to use javascript. It would be better if it could be accomplished using CSS only. That rules out the two first versions. Dave Shea's does not handle both width and min-width. The last one uses a lot of divs, are really all of them needed?

Stu's solution is set to work in IE 5, an old outdated browser and by removing the code to make it work for that one we will be able to lose some of the code.

IE5 has a broken box model, so you can't set both margin/border/padding and a width on the same container and get consistent behaviour across browsers. I know of two ways to sidestep that bug: The first one is using the ugly box model hack which incorporates a parsing bug in how IE 5 handles the voice-family property. The other way is to use two containers and set the width on one of them and the margin/border/padding on the other. Stu uses the latter variant and therefore has two unnecessary divs. Two down, and counting!

Next up we can use the <body> tag just like if it was a div, setting the width and min-width on that one. Another div bites the dust. If we can handle using a solid background color another one can be left out.

With everything summed up we can get min-width for IE on any container using only one extra div. This works under the constraint that we don't support IE 5 and that we can handle a single color background. I hope that helps someone out there.

Extra fluid layouts with javascript

2006-02-13T01:00:31+01:00

I'm a big fan of vector graphics. Because of that I love Macromedia Fireworks and the way it handles all elements like vectors. The good thing about that is that they can be resized and zoomed without them losing their sharpness.

This got me thinking about how to add some vectorization to CSS layouts. My idea was that you should let the width of the screen decide the font-size of, for example, your headers. This could make for nice fluid layouts and might even add to usability in some cases. There are probably other uses for this but I leave that to you, please use the comments if you come up with something.

Start by having a look at the dynamic font-size example just so we're talking about the same thing. Try resizing the window and reloading and see that the headers really do adapt to the width of the browser window.

How it's done#

First we need a way to meassure the width of the text in the default font. For this I use my own little getTextWidth() that were constructed in my line-break script. It simply takes a piece of text, attaches it to the page, meassures it's width and removes it again.

function getTextWidth(text) {
   var ea = document.createElement("span");
   ea.innerHTML = text;
   document.body.appendChild(ea);
   var len = ea.offsetWidth;
   document.body.removeChild(ea);
   return len;
}

Ok, now we know the width of some text in it's non formated state. Next up is to scale it as much as needed.

function scaleUp(elem, targetWidth) {
   var blockWidth = getTextWidth(elem.innerHTML);
   var defaultSize = parseInt(elem.style.fontSize || '100%')
   var newSize = Math.floor(0.9*targetWidth/(blockWidth/defaultSize))
   elem.style.fontSize = newSize + "%";
}

As you see scaleUp() determines a percentage by looking at three things: it's unformated width, it's current width and the target width. Font-size and text width does not seem to follow eachother perfectly so an additional multiplication by 0.9 is needed.

This handy little function is then called with the element you want to scale and the width in pixels of how wide you want it. The calls look something like this:

var element = document.getElementsByTagName("h1")[0];
var width = document.body.offsetWidth;
scaleUp(element, width);

That's it, hope you find some fun use for it.

Update: After doing some research I see that Eric Meyer is already using something like this in his slideshow system S5. Well well, it was a funny exercise none the less.

Frames or Iframes with CSS

2006-02-01T23:50:59+01:00

A frequent request from people new to CSS is trying to get a behaviour similar to frames while only using CSS. Many have read that frames have a lot of problems but do not know much more than that. This article will try to explain why frames are bad and what to do about it.

Update: I've updated this technique using position: fixed in a new article, have a look at those templates instead! (Although this article is still good for background information).

Why are traditional frames such a bad thing?#

Let me start by just listing a few bad things about frames.

Prevents users from bookmarking the exact page they're on. Instead the bookmark will lead to the frameset. This is clearly not a good choice for larger sites where finding a certain page might be a problem, but even users on smaller sites might find it annoying. I do.
Poor support by some parsers leads to problems. Many screen readers, mobile phones, and search engines have problems parsing frames. This means some of your users might miss out on your content.
Content order problems. Just like with tables, frames give screen readers problems when deciding which order to read the frames. If it reads a 2×2 frameset will not know whether to read the content like two rows or like two columns. The order might be important for understanding the content and frames has nothing built-in to help with that.
Search engines might split the ranking up on the different pages. I just discovered this by looking at one of my old pages (no, I won't show it, it's terrible :). There, the PageRank has been split up on the framed pages and the frameset has no rank whatsoever.
Invalid code. If you're using separate frames for navigation and content your links will need the target attribute to make links from the navigation frame open in the content frame. That attribute is not supported when using a strict doctype so you will have to use transitional. The doctype won't matter if you want to get rid of borders cross-browser though, to do that you need invalid markup.
Printing is a problem. How should the different frames be handled while printing? There's no good solution to this.

People that are good with javascript sometimes say they like frames because they make it possible to save information about the user even though the user clicks links. A variable can be saved in a frame and be accessible to the other frames even after they are reloaded. Another pro-frames reason frequently heard is that it saves overhead since not the entire page gets reloaded.

Personally I think that the first is a bad reason to use frames. Using server side scripting to save session info is much more robust since that will mean the applications still work if the user reloads the page. The other reason of only reloading a part of the page is nowadays done by using javascript together with XMLHttp (some like to call it AJAX). To me, the bad parts of frames greatly weigh over, even for applications.

Getting a scrollbar on any element using CSS#

Aside from all of the above frames are not structure. Think about it. When working with frames you define that you want a couple of rows and columns, which should scroll and which shouldn't, and which should have borders. These are things that many of us would never dream of doing with tables but some still use frames like that.

Instead we should define that kind of design in our CSS files. How? By using a few lines of code you can easily limit any element to a certain width/height and let it scroll if the content overflows that size.

<p>Here's some sample content that I would like to scroll</p>

p {
   width: 200px;
   height: 80px;
   overflow: auto;
}

It's easy, you're saying: "limit the paragraph to this size and give the box a scrollbar if the content gets too big" (Other valid values for overflow are "hidden" and "scroll". The former just cuts everything that sticks out, that latter adds the scrollbars even if they're not needed).

The above method works when you want something that's similar to iframes but it doesn't work right away for traditional frames. Those usually span the whole width or height of the page and leave the rest of the page scrolling. But what stops us from taking any element and stretching and placing it like a frame? Nothing. Let's do it.

Mimicking traditional frames#

The idea here is to use divisions to group our content. Then position those divisions as if they where frames and limit their site and set overflow: auto like we did above. Frames use the syntax cols="200,*" to say that the first column should be 200px wide and the second one "cover what's left". The second part is a bit harder to do with CSS.

There's no way to say 100%-200px but there's a trick we can use: floats push the content away. So if we set a width on the left block to 200px and float it left, the other block will be as wide as possible (default for block level elements) but it's content will be pushed 200px to the right. Here's an example of two columns with a fixed left in action. By just changing float: left; on navigation to float: right; we get the other example: Two columns with the right one fixed.

(Technical note: we don't need to add any margin-left since overflow: auto; clears too).

The above works well for columns but what if we need rows instead? When using frames we specify rows="100,*" and as I said this is not possible directly with CSS. We can't use the above trick either since we're dealing with height here. Setting height: 100% will just make it as high as the window, leaving no space for the other row. The solution here is to cheat a bit. If we make the first column 100px high and the lower one 100% high but then remove the first one from the flow we will be pretty close. The first row will be on top of the other one but that can easily be solved by adding a padding-top the same height as the first row.

We're almost there now, one last thing: the latter row scrolls on top of the first one because of the order in the source (latter elements stack on top of earlier ones). So what we do is force the first one on top with position: relative. This solves the problem except that it also covers the scrollbar now. An easy (and ugly fix) is to add a margin-left of 16px to the top column making the scrollbar visible again. Browsers seem to use the same scrollbar width so that's it, an example of frame rows using CSS.

I've tested this in IE 6, FF 1.5 and Opera 8.5 on WinXP and it seems to work fine. Broken in any other browsers? Let me know through the comments.

When looking at this I see that this is also a good way to mimick blocks that are position: fixed, something that doesn't work in IE. This method might be good in a situation where you need that one.

Building a poker template

2006-01-23T03:31:06+01:00

This is the first article in a series of niche templates I'm building. You can have a look at the finished template before we start if you want.

About the niche#

Today's topic is Poker sites. Poker, and card games overall, are hot these days and they are all over news. There are TV commercials for big international gambling sites even here in Sweden. Being in that kind of spotlight and receiving massive traffic must make those sites better than the rest, don't you think? Let's google for "poker" and have a look at the top 10 results (23 Jan 2006).

#	Site name	Doctype	Validation errors	Layout method
1	Pokerroom.com	Transitional	22 errors	Tables
2	Poker.com	Strict	62 errors	CSS
3	Pokerstars.com	None	48 errors	Tables
4	Pokerpages.com	None	336 errors	Tables
5	Pagat.com Poker	None	52 errors*	None
6	Worldpokertour.com	Transitional	56 errors	Tables
7	Pacificpoker.com	None	72 errors	Tables
8	Partypoker.com	Transitional	22 errors*	CSS
9	Paradisepoker.com	Transitional	1 error	CSS
10	Homepoker.com	Broken	146 errors	Tables

*) These sites required that we set a character set manually to even see how many errors there were.

What do we see up there? Poker.com and Paradisepoker.com do pretty well. Poker.com uses Strict doctype which means that their validation is stricter than the others, but 62 errors is still too much. Paradisepoker.com almost validates as Transitional which is a good thing compared to the other sites in the list.

Three sites use CSS for their layouts instead of tables. This is a good thing and they should be commended for it. However, that does not mean that they can't be better. All three with CSS layouts overuse divisions and spans terribly, often making the page a mess without CSS turned on.

Does this guy do nothing more than whine? I hear you ask. Yes I do. What I will do is nothing special; any one of you reading this could have done it yourself. I'm going to build a simple HTML document mimicking the front page of a poker site. If you are planning to build a site like that (or even if you are the developer of one of the sites above), you should definitely keep reading. The idea with all of this is to make it easier for people to follow the standards.

I will only include the front page of the site but it won't be hard to transform it to something simpler later on. Remember the purpose here: to show that it's possible to combine logical markup, valid code and make it look just the way you want it to. We need some kind of content though, so let's start with that.

Plan what features you want#

The features for the template will be my picks of the top10 above. Let's put some time on analyzing what features a decent poker site has.

The purpose of most of the sites seems to be to get people to play on their site. Most have some kind of client that is easily available from the front page and that button is the most important part of the page. Aside from that we need features to build a community around the game. Let's pick a forum as our community builder. Beginners need to have somewhere to learn the basics and everyone might need support from experienced staff sometimes. To build a good community you might also need news of some kind, displaying the largest prizes might give the site more players. Finally, all respectable sites have some info about the company behind it and if the site is big, they have a search. We want to earn some money too so let's add in a little advertisement. Sum this up in a list with descriptions.

Play poker button: One big button telling people to click it.
Beginners guide and support: Show on the front page that you don't need to be a pro to play and provide a quote from a professional player that illustrates this. Link directly into the guide to show experienced users that there might be something there for them too. Add frequently asked questions to this part too. Give users somewhere to turn to if they have problems.
News: Front page should link to a couple of top news and at the bottom have link to a dedicated news-page with more info.
Forum: Users should feel that this is a site with lots of people. Link to the topics in the forum most posted in to show them just that. This site is live and kicking.
Search: Search might be important both if you look for either a poker term or for a feature on the site. Add search for both the forums and the news here and let people decide which of them to search.
About us: Trust is important if you want people to part from their money. Put a picture of the staff online and quote reviews and happy customers (Don't fake this stuff. Never)
Advertisement (Ads): Ads need needs to be marked up as what they are. We want users to click on the ads only if they like the service the advertisers are serving

We now need to transform this to HTML somehow. When you do this yourself, try to think as little about the color, fonts and such as possible. Focus on what content you want to show your users and build the HTML based on that.

On the next page we will get down to business and start coding. You want to see what I'm talking about don't you?

Time has come to go through the list of features and write the code for them. The question which we should keep in mind here is "What content do I have?".

Play poker button#

Ok. We want a poker button. Some people prefer to use

<input type="submit" /> for all kinds of buttons. Those buttons are made for submitting a form though, and that's not what we want here. When you think of it, is this "Play button" any different from a link? I think not. We will make it look like a button with CSS later on. Let's use the HTML of a simple link:

<a href="play-poker.html">Play poker</a>

Advertisement#

All sites cost money to run and getting that money is often done with some kind of advertisement on the site. What kind of ads should we use for this template? Looking at the top10 it seems that images are more common than text so let's use images. Don't forget to let advertisers specify alternate text to their images so you don't have to make something up for the alt attribute.

<h2>Advertisement</h2>
<a href="url_to_advertisers_site.com">
   <img src="/files/post-media/play-roulette-online.png" alt="Advertisement: Play roulette online" />
</a>

Beginners guide#

To get beginners to play on our site we need to at least teach them the basics. How? People don't like manuals and they are often hard to navigate in. The best would be if no manual were needed at all, but let's be realistic, some people will still need help. A good approach is to use questions in natural language to lure people to read the guide. Keep it simple and easy to read. To mark that this is the beginners guide we add a header with that name in. Don't be tempted to use any other header than h2, the h1 will be used for the name of the site and this is a second level header, nothing else. To mark up the questions we use a paragraph of text with links. At the end we add a link to more information. The class "more" there is just a way to say that this paragraph is different from the one above.

<h2>Beginners guide</h2>
If you are a poker beginner you might want to start by reading
<a href="help/rules-of-poker.html">the rules</a>. When you are done with that
you can <a href="#help/register.html">register an account</a> with us. Don't worry,
to join is free of charge and you can even win some money in our
<a href="help/monthly-tournaments.html">monthly tournaments</a>.
More questions are answered in the
<a href="help/frequently-asked-questions.html">frequently asked questions</a> section

News#

People playing poker are probably interested in poker news too. By having news on your site your users don't have to go somewhere else looking for them. This will be a separate section so we should add a header here too, h2 is appropriate. The news items themselves are just items in an unordered list, so let's use the HTML for that, <ul>. End it all with a link to the news page that we wrap it in a classed paragraph like before.

<h2>News</h2>
<ul>
<li>23 feb: <a href="news/highest-prize-ever">Highest Prize Ever paid...</a></li>
<li>5 jan: <a href="news/caught-cheating">Top player caught cheating</a></li>
<li>10 dec: <a href="news/how-to-improve">How to improve your betting</a></li>
<li>1 nov: <a href="news/pokercompany-featured">PokerCompany featured on...</a></li>
<li>30 okt: <a href="news/murkus-baltomi">Murkus Baltomi the new...</a></li>
<li>24 apr: <a href="news/planned-downtime">Planned downtime on Sunday</a></li>
</ul>
We maintain an <a href="#news/">news archive</a> too.

Forum#

The forum posts can be handled much like the news. A header, a simple list, this time ordered by with the most active on top. End it with a now familiar classed paragraph.

<h2>Forum</h2>
<ul>
<li><a href="forum/forum.php?topic=7">Best strategy with one...</a> - 124 repl.</li>
<li><a href="forum/forum.php?topic=572">Anyone know of a store...?</a> - 115 repl.</li>
<li><a href="forum/forum.php?topic=17">What's the name of the...</a> - 89 repl.</li>
<li><a href="forum/forum.php?topic=67">What your biggest pot?</a> - 51 repl.</li>
<li><a href="forum/forum.php?topic=23">There was this guy in...</a> - 49 repl.</li>
<li><a href="forum/forum.php?topic=325">Help me get my...</a> - 36 repl.</li>
</ul>
<a href="#forum/">Our forums</a> are always filled with people to answer your questions.

Search#

The bigger the site gets the more important it becomes to get a site search. A search clearly resembles a form; the user fills in a few values and sends them to the site. A simple textbox for the search query with a submit following it.

Just in case you're not familiar with the modern way to make a good form I'll go through the elements used below briefly.

A <fieldset> groups similar form elements together. For example, if you have two separate fields for first name and last name, you can signal that they are both part of the full name by adding a fieldset around both of them.

Using <legend> we then tell what the meaning of the fieldset is. For the previous example we could use "Full name".

The last "new" tag here is the <label>. It simply shows that there are a relation between the text in front of the button and the input box right next to it. A good thing about this relation is that it enables you to click on the label and have the input selected; something that is particularly useful with small radio buttons. This is what the HTML looks like:

<form action="search.php" method="get">
<fieldset>
  <legend>Site search</legend>
  <label for="phrase">Search: </label>
  <input type="text" id="phrase">
  <input type="submit" value="search">
</fieldset>
</form>

About us#

Everyone wants to know who they're dealing with before they make a purchase of some kind (I believe that's one of the reasons some e-shops have problems, but that's a completely different story). Anyways, it's easy for you to put up an image and some quotes from people that are happy with your services, so do it. The header and "more" paragraph should be familiar by now.

<h2>About us</h2>
PokerCompany has been in the business since 1997 and is...
Want to read <a href="about/">more about us</a>?

On the next page we will take all the pieces of HTML and put them together. It's getting interesting, don't you think?

What a structured document looks like#

We have carefully constructed all the markup for the important parts of the site. Notice that we've said nothing about the look of it yet, we’re strictly dealing with content.

We will first add all a good doctype (strict), character encoding and the other things needed for validation. I will not go over this again, it was described a couple of weeks ago in the beginner's guide. This is just copy and paste, so don't skip this part.

Aside from that we also need to add some "hooks", namely classes and ids, to make it easier to style the document (If you don't know what those two are I recommend you read through the beginners guide before continuing). Good class and id names have something in common: they describe the content. So using "tinyredbar" is a bad name and using "latestnews" is a good one.

The basics, the bits of HTML we constructed above and the hooks, together form a good logical structure to start with. When looking at that page you will notice that it doesn't look pretty. When you view the source of it you will see though - that's what I want to see when I look at the source of your front page. I get all warm when thinking about it; pure, logical, and accessible content. It's now time to position things where we want them.

Apply some fancy CSS#

For me the design part always starts with an image program of some sort (Macromedia Fireworks lately for its ease of use). After a while of fiddling around with images and colors I decided to go for something like this draft (Note that I'm a programmer rather than a designer so don't expect wonders here :).

When you site there with your image in front of you and are on your way to start with the CSS there is one thing you should remember: do the positioning before you do the decoration. The positioning is the hard part and it will get even harder if you start to mix in colors and fonts. Let's all follow what I just said and start with the positioning.

Think of every tag you have on your page as a little box. By enabling borders on all your elements you can get a good idea of what I'm talking about. When deciding how to position these boxes it's always wise to start to look at "the flow" of the document. The flow is what you just saw when you looked at the structure above, content is just stacked on top of each other and most tags occupy the full width. By using some clever combinations of floats, clears and widths/heights it is possible to things to line up like we want.

Positioning the header#

Let's start by looking at the top. There seems to be four boxes here: a company name, company info, statistics, and the play button. The big image to the right can be added as a background, so we'll wait with that one. The first two boxes just need a smaller width to be where we want them (compare with how they where positioned in default flow). The last two ones need to be floated left and given a width (this will place them side by side).

#header h1 {
   height: 65px;
   width: 400px;
}
#header p {
   width: 400px;
}
#header ul {
   float: left;
   width: 130px;
}
#header a {
   display: block;
   height: 84px;
   width: 261px;
}

Next up we will deal with the navigation and search. Start by adding clear: both to the navigation to make sure we are below any floats from earlier in the code. To make the navigation list horizontal we add display: inline; to all list items. We complete the navigation by setting a width on the list and floating it left.

The search box is a bit harder. All that info won't fit in the tiny space we have left so my idea is that we hide the fieldset, legend and label. "Why go through the fuzz of adding them and then hiding?", I hear you shout. Relax. They're there because they help users that surf the site with CSS turned off, people like your rich grandmother (using Netscape 4), blind users (using screen readers) and Google. Visual users still know that the textbox is for searching because of the "Search" on the button afterwards, so we're not hiding important information. Ohh, and the header won't fit our design either so let's hide that too.

#navigation {
   clear: both;
   height: 41px;
   width: 720px;
}
#navigation ul {
   float: left;
   list-style: none;
   width: 400px;
}
#navigation li {
   display: inline;
}
#navigation form {
   float: right;
   width: 250px;
}
#navigation legend, #navigation label, #navigation h2 {
   position: absolute;
   left: -10000px;
   text-indent: -10000px;
   line-height: 0;
}
#navigation fieldset {
   border: none;
}

Positioning the advertisements#

Ahhh, ads, both hated and loved at the same time. Not to include ads on a big site like this would just look strange. Let's position it like we want. First move it down below the navigation by clearing. Then float it right to get it out of the way from the content below.

#adverts {
   clear: both;
   float: right;
}

Positioning the content#

This is going well; the content is next up for positioning. Note that I added a couple of divisions to this part of the HTML when merging. They will come to good use now as holders of the four sections. Each of the boxes is given a specific width and height and gets floated left.

#content div {
   float: left;
   height: 200px;
   width: 240px;
}

Phew, this feels like a whole days work doesn't it? On the last page of this tutorial we will put all positioning together and show an example of how everything looks when decorated. Click next below.

Putting it all together#

Now it's time to take all these small parts of CSS, put them in a CSS-file and apply it on the structure we had before positioned. Can you recognize the different parts from the previous page?

I could bore you to death by explaining every little margin in the decoration step but I won't. Instead I will just show you the prettied up version of the site. You can have a look at the second CSS file used if you want.

Final version of the site

Let's have a look at the same properties we looked at in the beginning of this article:

Site name	Doctype	Validation errors	Layout method
Friendlybit template	Strict	0 errors	CSS

Summary#

I hope this tutorial has showed you that CSS far from rocket science; could you not have done this yourself? The web really needs to be freshened up and made accessible for everyone, and with your help it can. Do your part by telling your friends, by holding a short presentation where you work, and by supporting webmaster you know work like this. Use your imagination, how can you make people understand?

Still here? Ok. If you're uncertain, ask yourself: can you afford to be left behind?

I hope this article gave you some insight to the development of a poker site. This article was the first is a series of articles about niche templates so be sure to check back for more. Any comments?

Building niche sites with standards

2006-01-23T03:30:56+01:00

I'm starting a new series of articles here at Friendly Bit. Through the use of web standards I will build a couple of niched sites and walk you through every step of the process. My hope is that this will make it easier for at least a few of you out there to understand what this web standards fuzz is all about. The use of web standards together with your creativity will make building websites fun again.

The first niche examined is online poker. The examination ended in a tutorial on how to build a poker site. What are you waiting for? Go read it!

My hope is that the templates will spread all the way to the niche markets they are made for. I appreciate any help with that. No matter what, I hope they will be great articles to learn from. Do you have anything to add? Use the comments.

Line Breaking With Javascript

2006-01-22T00:00:00+01:00

Over the years there have been numerous suggestions of different ways of doing line breaks on the web. Browser incompatibilities, lack of support for standardized features, and the creation of browser specific features all helps in making it incredibly difficult. Searching and reading for a while quickly brought me to think the best current solution is quirksmode's wbr. It seems quite well supported but has two major flaws:

<wbr> is not valid HTML
The suggested solution does not work in Safari

So off I went to find a better one. I started trying some different combinations of spaces marked up with <span> tags and I tried some nifty CSS tricks before it hit me - this should be done with javascript. Javascript has wide browser support and after some research (and help from the people in EFNet #javascript) I actually got a working example up. I have been able to test it in FF 1.5/Win, IE 5.5/Win, IE 6/Win, Opera 8.51/Win+Mac, and Safari 2.0.3/Mac and everything seems to work fine in all of them.

How it works#

The idea here is to add ordinary <br>s and using javascript to measure the length of the text. The user gives a piece of text and a width in pixels and the script returns the text with breaks inserted.

The hard part is to find at which letter we should break. My first idea was to just loop over the text and keep track of the width in pixels. When we get over the given width, back one step and add a break at that position. But this will be slow for small font-sizes and wide columns so let's do something faster. Instead of looping through all letters we can use Binary Search (check the link if you're not familiar with it, it's good to know). This makes for a lot less calls.

We need a small change to the algorithm since we won't be able to find the exact width we're looking for (a letter is wider than 1px). Instead we break when we're down to knowing that it's between two letters. We then return the first letter's position. Here is code:

function binSearch(text, searchLen) {
   var left = 0, right = text.length;
   var breakPos = left, lastBreakPos = right;
   while (Math.abs(lastBreakPos - breakPos) > 1) {
      lastBreakPos = breakPos;
      breakPos = Math.floor((left+right)/2);
      if (searchLen  getTextWidth(text.substring(0, breakPos)))
         right = breakPos - 1;
      else
         left = breakPos + 1;
   }
   return Math.min(breakPos, lastBreakPos);
}

The code above uses getTextWidth() to get the width of a piece of text. getTextWidth() makes use of the offsetWidth property to get the width of a piece of text. Problem is that only elements that are rendered have the property set. This means we need to add it to the page, measure it, and then remove it. This code does just that:

function getTextWidth(text) {
   var ea = document.createElement("span");
   ea.innerHTML = text;
   document.body.appendChild(ea);
   var len = ea.offsetWidth;
   document.body.removeChild(ea);
   return len;
}

Good. We now have two nice helper functions to handle all the hard work. Now we only need some code to actually split the text and add the breaks. We do this by using binSearch() to fetch where the next break should be. binSearch() returns an index and we split the line and add the first part (including a break) to a buffer. We then repeat the same procedure on the last part of the string. We keep splitting until getTextWidth() tells us we're done.

function linebreak(text, maxLen) {
   var breakPos = 0;
   var out = "";
   var part1 = text, part2 = "";
   if (getTextWidth(part1) > maxLen) {
      while (getTextWidth(part1) > maxLen) {
         var breakPos = binSearch(part1, maxLen);
         part2 = part1.substring(breakPos, part1.length);
         part1 = part1.substring(0, breakPos);
         out += part1 + "";
         part1 = part2;
      }
      return out + part2;
   }
   else
      return text;
}

It's now time to use the function we have. The first line selects what elements we want to wrap. You can replace this with a loop if you want if you need to go over all the paragraphs in your document. The second line just fetches everything inside the paragraph and sends it to linebreak() for wrapping. The two lines are then made to trigger when the document is ready loading.

window.onload = function () {
   var e = document.getElementsByTagName("p")[0];
   e.innerHTML = linebreak(e.innerHTML, 200);
}

A working example is available that shows what it can do. So, what do you think? Could this be the best solution so far to handling line breaks?

Short web standards quiz

2006-01-17T18:34:51+01:00

Q1. What does "semantics" mean in the context of web development?

To use CSS for layout instead of tables
To validate your page according to a given W3C specification
To use the most appropriate HTML tags for your content

Q2. Which was the next CSS specification released after CSS2?

CSS3
CSS2.1
CSS2.0

Q3. In context of content, presentation, and behaviour. What language is appropriate for the behaviour?

CSS
XHTML
Javascript

Q4. If you want to mark that a certain word is short for something longer, which HTML tag should you use?

<acronym>
<abbr>
<em>

Q5. Which of the following is NOT possible to do with W3C's CSS2?

Change the color of the scrollbar
Make a div fill the whole height of the page
Change the distance between lines of text in a paragraph

Q6. One of the following is a valid doctype, which one?

HTML 4.01 Quirks mode
HTML 4 Standards mode
HTML 4.01 Strict

Q7. W3C's validator (with XHTML 1.0 Transitional doctype) would let through one of the following lines. Which one?

<adress>Sesame street 34Germany</adress>
<font color="red">Hello</font>
<em><table><tr><td>Data</td></tr></em></table>

Q8. The much awaited CSS3 specification includes the following feature:

An easy way to add shadows to your text
A way to open windows in new tabs
Possibility to animate (move) text and images

Q9. Which of the following is valid CSS2?

display: inline-block;
*
_width: 300px;

Q10. Which of the following is NOT valid CSS2?

p:first-letter
* html #container
tr:nth-child(2n) td

Are you uncertain about any of the questions? Just post a comment and I'll answer. (You can also use the comments just to show off or points out errors of course :).

Cross browser CSS for your site

2006-01-13T00:21:39+01:00

This article will go through some useful cross-browser CSS techniques I use to get my sites to look the same in several modern browsers. It's fairly easy to send out different versions of your site to different browsers. This should be avoided though since it will end up with you having to maintain the site as if it was in fact several. That defeats the whole purpose with standards, why are they even needed if you are adapting to the browsers instead? My opinion is that good cross-browser coding is to find the set of standards that are supported and then use them.

Validate your site#

Validation is a much debated area and many Level 2 bosses doubt that this procedure really helps. It does help though. It ensures that you didn't do any simple spelling errors, things that could be incredibly hard to find manually. A validator also checks for nesting errors (did you put a <div> inside of an anchor?) and other strange things like your character encoding. Information about each of the errors is available as links when they appear, just click on one and you're on your way to learn something new.

Validation is the simplest of my tricks to check. There are validators available for both (X)HTML and CSS. Use them! Any errors that show up on those lists could be a potential cross-browser breaker so if you decide to ignore any of them you should be really sure about what you are doing. There are reasons why each one of all of the errors on the validation page show up, so validate, fix, validate, fix, validate.

Stay in standards mode#

The next trick is not as obvious. Modern browsers have two rendering modes they use to display websites with: Standards mode and Quirks mode. Standards mode is a rendering mode that is made to work according to the W3C specifications as closely as possible and Quirks mode is a bug ridden mode made for older sites. Why have a mode with bugs you ask? It's a way for browser makers to keep their users happy. When you do big changes to your rendering engine a lot of old sites relying on browser bugs will break. Some might think that this is a good thing, why should sites still work when they are poorly coded? If you think like that you have forgot about who the web is for. It's not a place for experts only, it's made for regular users, that is, anyone with a browser. Those people need to see a working site if that's possible.

So a new browser is released with a more standards compliant rendering mode and pages start to break. This is a bad thing for users so browser makers decided to first identify pages that tried to follow the standards, and if they did, switch to the new and improved rendering mode. You will probably see why I recommend standards mode now. All browsers are trying to render things as similar to the specs as possible when in standards mode, while in quirks mode they keep all their old bugs just to help regular users.

So how do the browsers identify who's trying to follow standards and who's not? They use the doctype. If you're not familiar with doctypes, don't worry, they are easy to learn. A doctype is a tag on first line of your site file telling the browser what markup language you will be using. There are basically two doctypes you should select among:

HTML 4.01 Strict (what I recommend)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML 1.0 Strict (without <?xml ...> on the line before)

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

Using any of these make sure the browser switches to standards mode and your design not fail because of that. Using a strict doctype means that you will do your best to separate structure from design and the validator will give you errors in those areas. It's very useful. (Worth a small note is that the XHTML Transitional doctype also triggers standards mode, but while using transitional you don't get as many good validation checks so don't use that one anyways.)

There is one last catch one needs to talk about when dealing with doctypes and standards mode - the doctype needs to be the first tag in the document. If you put any HTML comments or strange characters before it IE will go crazy and switch to quirks mode. This has cause many developers countless hours of trying to fix things. Just don't do it!

Remove default styling of elements#

Another cause of many web developers screaming in the night is the default CSS that is applied to elements. If you don't use any CSS at all on your page elements will still have a certain look. Headers will be larger than text paragraphs and blockquotes will have padding. Sizes of text is something that is pretty similar across browsers but something that's not is padding and margins. Let me give you an example: With no styling an <ul> gets a padding in Firefox but a margin in IE. Solution? Set either the margin or padding to zero and set the other one to the indentation you want. You need to somehow remove the default browset styles.

These kinds of problems take up a lot of development time if not handled nicely. "Do definition lists in Opera have padding or margin?". "What about second level headers in IE 6?". Two schools of thought have evolved to handling this. The first one tells you to start by resetting all margins to their defaults at the top of you CSS file. This can easily be done by typing in *, * being a universal selector that applies the same rules to all elements.

Problem solved right? That's where the second school of thought comes in. They argue that too many default margins are reset. Why should we mess with users form fields, rendering them hard to use unless they are set to good values again? Instead you could just reset those elements that have differences, and leave the rest untouched. This is quite a lot of work to get right so Faruk Ate? built a "starting css" template that you can easily include in your head. Personally I prefer the *-method, but try both and decide for yourself.

Browser bugs#

This is the area where CSS gets hard. Even though browser makers work their asses off to follow standards they sometimes don't reach their goals. This leaves us webmasters with bugs that when fixed triggers new bugs, either in the same or another browser. It can easily get real dirty.

One of the worst browsers (that is widely in use) is Microsoft's Internet Explorer, version 6. Some claim they have about 80% of the browser market so it's not a browser you can just ignore. IE was a good browser when it was first released but by today's standards it's certainly not. No other browser caused me more pain while building the design of this page. Its shortcomings get painfully clear when it comes to rendering complex CSS layouts.

How do you handle these bugs then? The easiest (and fastest) way is not solving it yourself but reading up on someone else's solution. "Holly 'n John" have gathered the most frequent bugs on their page Explorer Exposed!. They give you examples of how to detect the bug, how it works and why (sometimes) and most importantly how to solve it. Sometimes the solution is just setting position: relative; or display: inline; on some element and sometimes you have to resort to strange code. The point here is that if your bug is on that page; don't waste time trying to figure it out yourself. Learn that list by heart.

So what do you do if your bug isn't on the list? You start by googling for a solution of course. Googling takes a few minutes compared to the hour you probably need to hunt it down. Don't underestimate this step.

If you don't find it somewhere you need to hunt it down yourself. Do this by making a copy of your page and then removing as much code as you can while keeping the bug. Then find out exactly what line (or lines) of code that causes it and finally try to find another way of doing what triggers it. This is much better than just throwing in hacks, you keep your code maintainable and you learn a lot more useful stuff than if you were throwing in nonsense code from the beginning.

If you for some reason do not manage to solve the bug with the above technique you either rethink what you are doing (not likely) or you go get your arsenal of hacks. Make sure the hacks are valid code. The one I use for IE when nothing else works is the "* html" hack. You use it but writing like this: * html #element. That selector selects all tags that have the child html that have the child #element. But "html" is the topmost element in the hierarchy so nothing is selected, unless IE can choose of course. The code gets applied in IE only. Note that it is perfectly valid CSS, it just doesn't select anything. Remember: hacks are your last resort when nothing else works.

Update 18 Jan: Richard in the comments point out that you can also use conditional comments to serve a certain <style> or <link> to different versions of IE. The "* html"-hack will not work in the comming IE7. Thanks Richard.

I hope you found something useful in this article that you can use when you get cross-browser CSS problems. I have now told you what steps I use, did I miss something? Do you do something differently?

Levels of CSS knowledge

2006-01-11T01:25:29+01:00

As you might have understood by now I'm very much pro web standards. The current widely accepted standards are: (X)HTML for page structure, CSS for design, and Javascript for behaviour. HTML is pretty well known by now, it has been there since the beginning of the web and there are tutorials everywhere that gets you started. CSS is starting to get a grip, large companies are switching their sites to CSS based layouts and the webdev blogosphere reaches more and more people.

When you promote web standards, like many of us do, you get to talk to a lot of people. If you promote it in a live chat room like #CSS on EFNet it gets even clearer: there are a lot of different levels of CSS knowledge out there. This article is going to list some of those levels along a rating of how this kind of developer will affect the web. Here we go:

Level 0#

"CSS? Isn’t that a multiplayer game?"

These people have probably never made a webpage in their life. If they did it was pure HTML and they barely knew what they were doing. We get some of these people in #CSS, not because they want to start learning but because they think they've come to another channel, often looking for CS:S. No need to worry about these people, they probably won't do many webpages in their lives so they can't do much harm.

Level 1#

"Yeah, I use it to remove underlines on links sometimes"

Different from Level 0, the people in this level do actually know basic HTML. They probably learned it at least five years ago and have made a couple of simple sites. They use very little CSS, only when they need to do simple stuff you can't do with HTML only, like removing underlines and setting line-height (No! don't even think about setting line-height with HTML). While these people could present us with some badly coded sites they rarely have any large and well visited ones. This means that they won't do much harm either.

Level 2#

"No, I don't like divs; tables are much easier to work with"

Instead of just playing with HTML, like those from Level 1, some continued their quest. They mastered HTML tables and started using it to make things look just like they wanted. Somewhere around reaching HTML mastery they stopped looking at new ways of working. They heard about other people using "divs to design their pages" and even took some time one day to try to learn what the fuss was about. After a few hours of not getting it they gave up, went back to the familiar land of tabled layouts, and stayed there. Many do know CSS syntax and sometimes even some background but they believe it's far too hard and ill-supported to use instead of tables.

Watch it! These are dangerous people, some even webmasters of big corporate websites. Since they have been in the business for a while many are leaders for their web departments. These are the people it's most important to reach, and if we do it means a lot for the web. Concentrate on these people all you standards advocates.

Level 3#

"Yes I've heard it's good, but I can't use it because of…"

While people in this group still don't use CSS for positioning they do know some CSS and perhaps heard good things about it. They've tried making simple layouts and some even liked how it felt to work with. Problem here is that something is stopping them. Perhaps they have a Level 2 boss, perhaps their website needs to cater for Netscape 4 users, there might be many different reasons but something is in the way.

These people need to know that while CSS does not work everywhere that isn't the end of the world. Old browsers will still get all your content, just pure content. Instead of them you will reach a new audience: there may be accessibility and usability benefits, newer browsers will get a richer experience and the site might even get easier to add content to (which will lead to more content). Tell this to the people in this group. If you're unlucky they are not be the ones making decisions but in that case their influence on Level 2 Bosses will still be worth it.

Level 4#

"CSS? Oh! Yes, I use divs for all my layouts"

It's not unusual that these people use only divs on their sites. Each part of their page gets a div, often with a carefully crafted id (#toprightredline or even #r5_c7 with r standing for row and c for column), and then they position their divs with absolute positioning by the pixel. The result looks good, hey, it even validates as XHTML 1.1(!) but what they have missed is that most of the benefits of CSS has been lost. These pages are terrible when it comes to a screen reader interpreting it. Same with older non-CSS browsers, they won't get the content… they will get one big block of text. When using bad class names and ids you loose the possibility to change the layout: if that red line needs to be changed to black you'll need to change all your HTML documents too (can be hundreds). Don't fall into the trap of telling them they are stupid or make them google "css", they know they are smart people and they did learn about CSS from google in the first place. Tell them exactly what could be improved on their sites. Tell them what the benefits are. Keep your cool and tell them why.

People of Level 4 produce sites that are rather bad. The damage is reduced though by them often being open to new ideas. After all, not to long ago they did manage to learn and start to use CSS.

Some of the reasons for people thinking this way is because of what WYSIWYG editors are doing. Most such editors produce terrible div-only code but I'm hearing that there are gradual improvements in this field. This is a good thing and hopefully this will help people move from Level 4 to the higher levels.

Level 5#

"I use CSS for design, it's better than tables because of…"

After a lot of reading, talking to people and thinking most people arrive at Level 5. This is where you both can use CSS and know why it's better. Some people in this level have minor problems on the sites they produce but it's nothing serious. When asked they can argue why separating structure and design is a good thing and they have worked with CSS long enough to know the common pitfalls. I'm guessing many of the readers of this article are on this level and I feel I am. But this is not the best we can do…

Level 6#

"What version of CSS? Yes, I do. Did you read my book about…"

For some people knowing how and why isn't enough. These people strive to improve how CSS is used and are publishing great articles on new ways of using it. They constantly go back to the basic needs CSS is filling and attack problems from new angles, often resulting in more great articles. Some have actually read the whole W3C specification on CSS (sic) and they certainly know which parts are supported by which browsers. They function as role models for beginners and do great things for the web with their influence. Many work with the Web Standards Project. If you ever find an error on their site there is a reason for it. Ask them and they'll tell you why.

That's it. I hope this article gave you some inspiration to keep pushing the web to new victories. At which level are you? Do you have examples of people in last level?

Simple CSS templates

2006-01-07T16:25:48+01:00

The most frequent question in the #CSS channel I'm in is about how you make a 2 column layout. Most beginners seems to have problems understanding how floats work since they are quite different from tables. So I sat down and made some simple layout templates for you. These layouts will all be made with floats since that's the easiest way to do things. I could have set out to use absolute positioning but that can get tricky when it comes to placing the footer. Let's stay with floats.

I'll recap how a floats work. A float is applied by simply setting float: left or float: right on an element in your CSS-file. The element then gets pushed as far to the left or right as possible and the next element will follow to the right (if floated left) or left (if floated right). The closest HTML comparision is the effect you get when setting align="left" on an image. In the beginning it helped me to think of floats like that.

There are basically two ways to make 2 column layouts with floats. Either you float all the columns (float-float) or you float all but the last one (float-margin). The former method makes it easier to work with clearing inside of the second columns though, so if you're going for a complex layout float-float might be better. The latter has the advantage that you don't have to set a width on the last column. It will fill whatever space is availiable. My favourite is still float-margin though, the automatically expanding second column makes sure the the full width is used no matter what.

For the examples below I will use the HTML I outlined in my previous article about CSS basics.

The float-margin method#

Let's start by looking at some examples:

Ok, so how does this work? The first example: The navigation is floated left which means that the next element will follow to the right of it. This sounds right but we are forgetting one thing, what happens if the navigation is very short? Then the text in the right column will continue below the float, probably not what we wanted. So, to fix this we add a margin-left to our content division. Voilà!

The 3 column example is based on the same idea. Here we start by floating the navigation left, floating the first content block right and finally add margins to the second content block. The last block needs to have both a margin-left and a margin-right to stop the text from continuing below the left and right columns. Makes sense? Take a look at the code and I hope it will.

The float-float method#

Another method of doing the same is floating each of the columns left. This means that the columns will show up on the webpage in the same order as you put them in the HTML (that was not the case in the previous example, content1 was to the right and content2 in the middle). Some examples for you:

There isn't much explaination needed here, only thing different from the float-margin method is that you need to set a width on all your columns. You should easily be able to expand this method to kazillion columns :)

That's all, be sure to poke around with the different layouts to get a feel of how they work for you. In my next post I will go through some less static layouts, namely elastic and fluid layout. Comments are availiable for questions.

Update: Added an article on Common questions beginners ask

Make a tooltip out of some columns in a table

2006-01-06T01:16:59+01:00

A worried user joins the #CSS channel on EFNet. He has a big problem with the site he's currently working on and wonders if there might be a problem with his markup. Let's see what he wants.

The site sells some kind of houses and each house has a few "options" (let's pretend a bigger door is one option) that the user should be able to select among. Each of these options has a name and costs a certain amount of money. When you move your mouse over one of the options, he wants more info to pop up in a small box. In the box there should be an image, a store name and strange number. What HTML should he use to mark that up?

We talked for a while and thought about definition lists containing a div with the extra info in, perhaps a two-column table with a div in the second column? After looking again it became pretty clear, if we just look at his data and not think about the design, all that was left was one big table. Everything that he wants in the tooltip are things that could as well be shown in a big table. So why not use exactly that markup and then use javascript to make some cells only pop up when the row was hovered?

This is the markup I propose:

<table summary="Options for your house">
  <thead>
    <tr>
      <th>Option</th>
      <th>Price</th>
      <th class="tooltip">Image</th>
      <th class="tooltip">Store</th>
      <th class="tooltip">SKU#</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Bush</td>
      <td>$3</td>
      <td class="tooltip a1"><img src="/files/post-media/bush.jpg" alt="An alabama bush"></td>
      <td class="tooltip a2">Alabama</td>
      <td class="tooltip a3">#23535151</td>
    </tr>
    <tr>
      <td>Bush</td>
      <td>$3</td>
      <td class="tooltip a1"><img src="/files/post-media/bush.jpg" alt="An alabama bush"></td>
      <td class="tooltip a2">Alabama</td>
      <td class="tooltip a3">#23535151</td>
    </tr>
  </tbody>
</table>

What you see there is a plain five column table with some classes spread out to make it easier to fetch what we want with the javascript later on. The whole table is given the id "info", this makes us able to separate it from other tables on the same page. Each cell that are going to be in the tooltip get the class "tooltip" and an aditional a1-a3 class that simply is used to position the specific cell later on.

Next we need to do two of things:

Loop over the table and hide everything with the class "tooltip"
Loop over all table rows and add a mouseover function to each of them that makes them show all hidden cells in that particular row

To fetch all elements that has a certain className we will use Jonathan Snook's fabulous getElementsByClassName. It takes two arguments, the element whose children it should loop through and the className it should look for. The function looks like this:

function getElementsByClassName(node, classname) {
   var a = [];
   var re = new RegExp('\\b' + classname + '\\b');
   var els = node.getElementsByTagName("*");
   for(var i=0,j=els.length; ij; i++)
      if(re.test(els[i].className))a.push(els[i]);
   return a;
}

Next we need to write the code that fulfils the list we wrote previously:

// Hide all classes with the className "tooltip"
var tooltips = getElementsByClassName(
   document.getElementsByTagName("body")[0], "tooltip");
for (var i = 0; i  tooltips.length; i++) {
   tooltips[i].className += " hide";
}

var tbodies = document.getElementsByTagName("tbody");
for (var i = 0; i < tbodies.length; i++) {
   var trows = tbodies[i].getElementsByTagName("tr");
   // Add a function to each tr that makes it show it's cells on mouseover
   for (var j = 0; j < trows.length; j++) {
      trows[j].onmouseover=function() {
         var childtooltips = getElementsByClassName(this, "tooltip");
         for (var k = 0; k < childtooltips.length; k++) {
            childtooltips[k].className+=" hooover";
         }
      }
      // And hides all child cells on mouseout
      trows[j].onmouseout=function() {
         var childtooltips = getElementsByClassName(this, "tooltip");
         for (var k = 0; k < childtooltips.length; k++) {
            childtooltips[k].className =
               childtooltips[k].className.replace(new RegExp(" hooover\\b"), "");
         }
      }
   }
}

A note here is that we don't loop over the first table row. That one contains the table headers and shouldn't react to us hovering it.

Last but not least we need a few lines of CSS to make the page behave like we want it to. Without either Javascript or CSS enabled a plain table should be shown with all cells visible. If you have both enabled you don't want the cells that contain the tooltip to take up space in the table. Here's the code:

.hide {
   left: -10000px;
   position: absolute;
}
.hooover { left: 80px; }
tr { position: relative; }
.a1 {
   border: 1px solid Black;
   width: 300px;
}
.a2 { padding: 20px 0 0 120px; }
.a3 { padding: 20px 0 0 200px; }

The "hide" class is added to any element with the class "tooltip". Why not make the tooltip class hide the cells right away you ask? The answer is that then a non js user would not see those cells at all. This way we get the best of both worlds. To remove the hidden cells from taking up space we remove them from the flow with position: absolute; and to hide them we use left: -10000px.

The "hooover" class get enabled when we mouseover one of the table rows. It just sets the left value to a far more visible 100px. Lastly we set some styles on the a1-a3 classes that makes the tooltip look a little better. We use a1 as a background and place the other two classes on top of it to make it look like they are in the same box.

And that's it, a table turned into a tooltip, another user is a little bit happier and all would be fine... Unless of course the user had left the channel before I could show him my solution. Damn.

Beginner’s guide to CSS

2006-01-05T18:11:00+01:00

In the chat channel I'm in, I get to talk to people on a daily basis that have never used CSS before, or are at the very beginning of learning it.. This article teaches all the basics you need to make your first CSS powered website. It is aimed at people that know a little HTML, and maybe have made a few websites themselves. Let's get started.

What is CSS?#

CSS is a language that adds style (colors, images, borders, margins…) to your site. It's really that simple. CSS is not used to put any content on your site, it's just there to take the content you have and make it pretty. First thing you do is link a CSS-file to your HTML document. Do this by adding this line:

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

The line should be placed in between your <head> tags. If you have several pages you could add the exact same line to all of them and they will all use the same stylesheet, but more about that later. Let's look inside the file "style.css" we just linked to.

h1 {
   font-size: 40px;
   height: 200px;
}
.warning {
   color: red;
   font-weight: bold;
}
#footer {
   background-color: gray;
}

You have three selectors up there, h1, .warning and #footer. A selector simply points to somewhere in your HTML document. It can be built in many ways and can be a combination of the following building blocks:

Element
Class
Id

I'm going to go through all three of them and explain what they do.

An element points at a HTML-tag somewhere on your page. In the example above we want to style the <h1>-tag. Note that using an element like that affects all tags with that name, so using p gives all p-tags a left-margin.

Using a class is just as simple. When writing .your_class you style all tags with a class with the name "your_class". In the example above we have .warning which will style e.g. <div class="warning"> and <em class="warning">, that is, any element with the class warning. Classes are used when you want to style just a few of your tags in a way, perhaps you want some of your links red? Add a class to all those links.

You need one more building block: the id. This time you style an element with the attribute "id" set to the id you have chosen. Ids work exactly like classes except for one thing; you can only have one id with a certain name in each of your HTML documents. In the example above we style <div id="footer">. If you look at the example it does make sense: a HTML document may contain several warnings but only one footer. Ids should be used when you want to style just one specific tag.

Using those three building blocks will take you far but when you get to more advanced layouts you might want to combine the building blocks into more advanced selectors. Just to give you two examples of what you can do: em.warning to style only those <em>-tags with the class .warning set. You can also use #footer a to style only the links that are nested inside the tag with id "footer". Pretty nice, isn't it?

I could go on forever about the advanced uses of selectors but this is a beginner tutorial so I won't. If you want all the finer details, go have a look at the excellent Maxdesigns Selectutorial.

Let's go on explaining the code above. Each of the selectors has a set of declarations tied to them. Each declaration has a property, describing what we want to change and a value, what we should change it to. Too many terms there? Are you still with me? Let me explain with an example: a. You have the selector a there, so all links in your document will be styled. We have two declarations: color: Blue and font-size: 3em;. Lastly each declaration consists of two parts: the property color and the value Blue. Phew! Well done for making it this far. The terms above are good to know since it gives you a way to talk about your CSS. If you join a CSS-channel asking for help with your code and they tell you "You have an error in your a-selector in the second declaration" you know exactly where! Right? :)

Now you will probably ask what properties there are. You have seen font-size and color but what else is there? The answer is that there are a LOT of things you can style and play with. Additionally (close to) all tags are equal in CSS, so you can set e.g. borders and colors of any element just like you could with a table if you used only HTML. Starting to see the possibilities?

I won't go through all the properties here, it would just bore you to death. Instead I'll point you to another great resource: w3schools section about CSS. Just select one of the menu options to the left to start exploring what CSS can do.

But don't you leave me all alone here, there is more to learn! Next we will talk about good and bad coding and there will be a lot of colorful examples for you. Sounds good?

CSS is all about separation#

One of the least followed parts of CSS is the very idea behind it, the idea of separation of content and design. The idea here is that all sites contain two major parts, the content: all your articles, text and photos and the design: rounded corners, colors and effects. Usually those two are made in different parts of a webpage's lifetime. The design is determined at the beginning and then you start filling it with content and keep the design fixed. So if you just want to add content to your site you don't want to be forced to mess around with the design, do you? The same thing is true the other way around, if you decide on a redesign, why should you have to mess around with the content, making sure it fits in the new layout?

In CSS you just add the nifty <link>-tag I've told you about to the head of your HTML document and you have created a link to your design. In the HTML document you put content only, and that link of yours makes sure it looks right. You can also use the exact same link on many of your pages, giving them all of them the same design. You want to add content? Just write a plain HTML document and think about marking things up like "header" instead of "big blue header" and use CSS to make all headers look the way you want!

This is a different way of thinking about webpages, and it's something that took a while for me to understand. To help you I have written some examples of good and bad coding. What's wrong with this?

<font size="3">Welcome to my page</font>

Comment: The font-tag is design and design shouldn't be in the HTML document. All design should be in the CSS-file! Instead do this:

In the HTML:

<h1>Welcome to my page</h1>

In the CSS:

h1 { font-size: 2em; }

One more example:

<b>An error occurred</b>

Comment: This looks right doesn't it? But if you look up what <b> stands for you quickly find bold. But bold is certainly design, so it still doesn't belong in the HTML document. A better choice is <em> that stands for emphasis or simply "this piece of text is important". So instead of saying "this text looks like this" you are saying "this text is important" and you let the looks be decided by the CSS. Seems like a minor change, but it illustrates how to select your tags. Use this instead:

In the HTML:

<em>An error occured</em>

In the CSS:

em {
   font-weight: bold;
   color: Red;
}

One last example:

<table>
  <tr>
    <td><a href="">first link</a></td>
  </tr>
  <tr>
    <td><a href="">second link</a></td>
  </tr>
  ...
</table>

Comment: Lots of people format their navigation menu like the above example. But is a navigation menu really a table? If you look up the definition of a table you see that it's made for tabular data, the same kind of data you would put in an Excel sheet. The example has only one column of data, and no headers… Some people state that they use tables because that means that they can get borders and a background color on their navigation, but that's exactly what your CSS file is for (not the HTML document). So what should we do? Look deep in the list of HTML elements at w3schools and you'll find something called an unordered list, <ul>. Have a look at this:

In the HTML:

<ul>
  <li><a href="">first link</a></li>
  <li><a href="">second link</a></li>
  ...
</ul>

In the CSS:

li {
   border: 1px solid;
}

This is probably a different way of thinking about HTML than you're used to but trust me, when you've worked with it for a while you'll see the power of it. Not only does this way of coding give you a more logical structure, there is also proof that this improves your ranking in search engines and makes it easier for accessibility devices to read your site. This way of designing is great.

Next we will build a simple HTML template to use as a start when building a new page. Like to see it?

Building a standards based HTML template#

We have talked a lot about the theory behind CSS and HTML working together to form a site with good structure that is separated from the design. But the first parts of building pages are always the same, you type

<!doctype html>
<html>
  <body>
    <div id="header">
       <!-- Header here! -->
    </div>
    <div id="navigation">
      <!-- Navigaiton here! -->
    </div>
    <div id="content">
      <!-- Content here -->
    </div>
  </body>
</html>

Ok, there might be some new stuff there so let's go through the lines one by one. First we state this document's doctype: what language we use. You might have heard of XHTML, another similar web language, but for a first page we don't need the features that gives us access to, keep it simple, just go with HTML. Also, the <!doctype html> above sets the document to use Strict HTML. To understand that you need to know that there are two kinds of rendering in a browser. One that follows the standards set up by the W3C, "standards mode", and one for older pages, called "quirks mode". Standards mode is what we want to use. It makes the pages render (almost) the same in modern browsers and it frees us from being dependent on a specific browser, we'll just follow the standard. Quirks mode is something of a bug mode. It's there to keep old pages looking the same as they did before browsers started trying to follow the standards and is therefore intentionally filled with strange bugs. A browser determines which rendering mode to use based on what doctype we use, so make sure you use the right one!

Ok. That's a lot of explaining for a single line of code, I'll be swifter now, next line. You have probably written <html> before in the beginning of your documents. My line is almost like that except that I have added lang="en" there. That line tells the browser which language we will use. Why does it matter what language we use? you ask… Well, there is assistive technology that read webpages to people out loud called screen readers. Those have to know what language it is to be able to pronounce the words. It's so easy for you to add those few characters so why not do it? If you don't plan on making an English page you can find your own language code by visiting WAIs Language Codes and check out the two-letter names there (Note: language codes are in lowercase).

Next we have the head of the document. The head contains a some of meta-information about the page, like character encoding, title and what stylesheet (CSS file) to use. The charset there is the trickiest one so let's take that first. There are a lot of different letters in a language. When computers where first constructed the engineers only thought about the American/English language, they didn't even think about the swedish letters å, ä, ö or the deutsch umlaut ü or what about the &-sign? There are a lot of characters and at first there was no general consensus on how to handle them. Then someone came up with the smart idea of grouping them into sets, groups of characters that are used in certain parts of the world. So, what the meta-tag does is simply to state: "This person wants to input western characters (latin-1 characters)", and this tells the browser what character set to use. A more genaral approach is to use the utf-8 character set but that quickly gets tricky. Finally we have a text/html there that simply tells the server to send the document as a HTML, not like an image or something like that. The <title> and <link> you should be familiar with, if not, google it :)

That was a lot of info on just a few lines of code, I hope I didn't give the impression that this stuff is hard, because it's not. To use the stuff above you just copy and paste it and start filling it with content.

The body of the document consists of a bunch of divisions, let's add some content to them:

...
<div id="header">
  <h1>The name of this page</h1>
</div>
<div id="navigation">
  <h2>Navigation</h2>
  <ul>
  <li><a href="first.html">First</a></li>
  <li><a href="second.html">Second</a></li>
  <li><a href="third.html">Third</a></li>
  </ul>
</div>
<div id="content">
  <h2>Content</h2>
  Some sample content, add your own here
</div>
<div id="footer">
  This page is written by [Your name] and builds on a <a href="http://friendlybit.com">Friendlybit template</a>.
</div>
...

What have we done here? First you should note that a quick overview of the document tells you quite much about the content. You can easily see that some stuff are headers (h1, h2) and some are just a list of links (ul, li, a). Let's go through the code quickly:

First we have a header. A header is something that's most often a big image and some text. Some pages don't have the header in the HTML at all, they just link to an image and have the text in that image. Problem with that is that neither search engines nor screen readers can get the title text. With the title text being the most important piece of description a visitor has to what page they have come to, you do have a problem. So trust me, keep that text there.

Next up we have the navigation. Navigation should almost always be marked up as an unordered list of links. I've seen the strangest variants of this with tables, nested tables, ``-tags after each line and so on but the only content there is a list of links, why make it something it isn't? Using a list doesn't mean it will have to look a certain way, remember that all design is handled in the CSS later on, this is just HTML we are dealing with here. Note: you can easily remove the bullet marks with list-style: none;, that's not a reason to use some other HTML.

The most important part of your HTML document is the content. This is the reason people will visit your page and this is where you should put most of your effort. Mark your headers with appropriate header-tags and make sure they look different from the ordinary text, this makes it easier quickly get a grip of what you're are trying to say. Use paragraph tags around your paragraphs to make is easier to style your text. The CSS text-indent: 2em; adds some space before only the first word in each paragraph, just to name one simple thing you can do with CSS when you've used good markup.

Lastly, it could be a good idea to add a footer to your page. Make sure you have some kind of contact information here or somewhere else on your site, who knows what people will want to ask you? If you want to help me you could add a link to this site somewhere on your site too. If you do, thanks alot!

On the next (and last) page of this short beginners guide we will wrap everything up and add some sample CSS to the mix. All is free for you to copy and use on your page. Ready?

Full HTML template and sample CSS#

Let's start by putting the two pieces of HTML I showed you together and combine it with some sample CSS: Sample HTML + CSS. You can find all code that makes that page below. Feel free to copy the code below and experiment on your own.

<!doctype html>
<html lang="en">
  <body>
    <div id="header">
      <h1>The name of this page</h1>
    </div>
    <div id="navigation">
      <h2>Navigation</h2>
      <ul>
        <li><a href="first.html">First</a></li>
        <li><a href="second.html">Second</a></li>
        <li><a href="third.html">Third</a></li>
      </ul>
    </div>
    <div id="content">
      <h2>Content</h2>
      Some sample content, add your own here
    </div>
    <div id="footer">
      This page is written by [Your name] and builds on a <a href="http://friendlybit.com">Friendlybit template</a>.
    </div>
  </body>
</html>

You should be able to tell what each part of the HTML does by now. Let's instead have a look at some sample CSS for the structure we have above. If you want to experiment with this code you can copy it to a file named style.css (or any other filename you reference in the <link>-tag in the HTML) and place it in the same directory as the HTML document.

body {
	background-color: Green;
}
div {
	border: 3px solid Black;
	padding: 7px;
	width: 600px;
}
h1, h2, h3, h4, h5, h6 {
	margin: 0;
}
#navigation {
	float: left;
	width: 150px;
}
#content {
	float: left;
	width: 430px;
}
#footer {
	clear: both;
}

Let's go through the six rules above. First we set the background-color of body, and body is the background of everything, so this will do the same as bgcolor did in HTML.

Next we set some styles on all divisions on the page. We have four of them and with this single rule we affect them all. First we set a black border to be 3 pixels wide (note that there is no space between number and unit in CSS). We then set a padding (the space between the border and content) to be 7 pixels and lastly we set the width of all divs to 600 pixels (note that margins, borders and padding are not included in the width).

The third rule selects all headers on the page and removes the margins (the space between the border and other nearby elements) from them. The commas are used between the elements to apply the same CSS to all of them.

Next we have some specific rules for three of the divisions. We position the navigation to the left of the content. This is done by using floats, a way to put things side by side. If you have used the align-attribute on images in HTML you will know how floats work, they move the element as far to the left as possible and then let the next element follow right next to it. If you want to put something below a float you need to clear it. Clearing moves the element down until it's below any floats, exactly where we want the footer. So both navigation and content are floated and given a width to match the 600 pixels wide header, and the footer is cleared.

Update: I have added some simple layouts for you to look at, and a list of tools I use when developing. Hope they help all of you out there that learn by examples.

Now it's your turn, you will learn CSS by using it and trying out how things work. So go ahead and play with the sample above. Thanks for reading, and good luck!

Any ideas of how this guide could be improved? Just leave a comment to the right.

How this website was built

2005-12-20T00:00:36+01:00

Hi there early readers! Welcome to a newly started web development blog. I know that there are a lot of those around so I will work hard to make it different and hopefully earn your trust. This site will mainly consist of new stuff; very few of those “news about news” posts, there are better places for that. “Web development” I say, and by that I most often will mean client side techniques like HTML, CSS and Javascript. This is the idea and I hope it will work out.

This site has been worked on for over a year so it's about time I get it up and working. This article will talk mostly about how this site has been built. You will hopefully notice that to me it's important that you practice what you preach.

WordPress as backbone#

I'm running the blog software WordPress 2.0 as the base for all this. I've read a lot of good things about it and I know PHP so I thought why not give it a try? In just a week I had written my own theme and a few plug-ins to go with it. WordPress really is well built and easy to use. Any problems I've had have been answered in the IRC help-channel by nice people. Kudos to the WordPress team for doing a great job.

Fireworks for building the idea#

All my layouts start out in Macromedia Fireworks. Fireworks is a nice program to work in even though I'm not used to their other programs. I have tried Photoshop but it just didn't work out between us. Floating toolboxes? Startup time that makes me fall to sleep? No, I wanted something that’s easy to get started with, and if possible something that had special tools for web development. Fireworks is perfect for this, it’s like a combination of Illustrator and Photoshop and has a user interface that even a beginner learns quickly.

I played with a few different layouts until I found something I liked. The idea with this one is to put the content in focus. Everything except the content column is dark so the white will stick out. The text starts a bit above the text in the left column and has a big <h1> so you know where to start. The comments are placed in the sidebar, mostly because there probably will be very few in the beginning. Don't take that as an insult, I want to hear what you say, but this is not a forum or wiki :)

CSS elastic faux columns for implementing it#

This site does not use tables for layout (of course!). I'm an operator of a help channel for CSS so that would be unacceptable :) A lot of work has gone to make sure the layout works like it should.

The layout in Fireworks was complete and I had the hard part left, converting my mock-up to a web site. After many tries I finally decided to go with a zoomable layout. I know this is hard to work with, especially with complex sites like this one but I thought I’d give it a try. Worked out pretty well I think. The biggest bug I know of is that the header look strange in Opera and Safari, as far as I can understand it's because of a bug in both their rendering engines when calculating percentages. Anyhow, the site works well in both Internet Explorer 6 and Firefox so I hope most of you will see it like it's meant to.

The layout is made zoomable by using the em unit on the parent container. When text-zooming (Ctrl + Plus in Firefox and View -> Text Size in IE) the em unit adjusts to what you select so everything gets nice. There is one big problem with changing text-size though: images do not change size when you text-zoom. So certain parts of the site need to stay fixed and some need to move for the site not to collapse.

I wanted background-images in all my three columns so having all columns change their sizes started to look hard. Then I stumbled over an article about faux columns that used percentages to position a background-image so that it could grow in both directions. The faux columns technique uses a repeating background-image to fake columns. By using two of those images I could get it working on a 3 column layout with percentages.

The next step was making the site zoomable. If I set the container to a fixed em width and then use faux columns with percentages throughout the site I get what I want. Everything worked out and I could start working in the small parts. Want to see how much trouble IE gave me? Just have a look in my "decoration" stylesheet, I commented every browser problem I encountered in IE, Opera and FF and solved most of them :)

Miscellaneous#

All images used are from SXC.hu, the excellent stock image directory. Highly recommended.

That's it people, my site and the idea behind it. I hope you will come back and read my articles. Thanks for reading.

Friendly Bit - Web development blog

Rendering a web page – step by step

Position: fixed CSS templates

Position: fixed CSS templates#

Fixes for IE6#

SpriteMe – Combine images and get fewer HTTP requests

Techniques to use when IE6 dies

A couple of sites I’ve launched

Uttråkad.se#

Kundo.se#

Samhallsentreprenor.se#

Two more projects…#

Interface developers and security

OpenID, Nofollow removed, Comment counts, and IE7 fixes

IE7 hover bug: z-index ignored (and other properties)

Yellow fade with CSS and a simple image

The Open Web: Can it deliver?

Why adding variables to CSS is a good thing

Professional perspective#

So we need variables, but how?#

So what about beginners?#

Summary#

Don’t waste time writing HTML and CSS

1. Do you need HTML or CSS for this?#

2. Try to set properties once#

3. Learn your text editor#

4. Make sure your environment supports you#

Upside down text with CSS

Feed readers should show comments

Why not #1: Feeds are meant to be fast#

Why not #2: Comments are hard to detect#

Why not #3: Each post will be too long!#

Promote contributions more#

New theme up for friendlybit.com

Style tables with CSS

Add a gradient to your cells#

Remove the space between the cells with CSS#

Obey the set width#

Styling columns#

Documenting CSS

IE8 and Doctype switching

The real strangeness#

What it all comes down to#

Sharepoint 2007 from an interface developer’s view

"Customization"#

Specifics#

Development#

Accessibility#

Page size#

Javascript and Browser dependencies#

Changing the CSS#

Share point and Master pages#

Default .NET controls#

In summary#

IE8 renders the acid 2 test

Future of web standards (my take)

CSS3 Media queries instead of the media attribute

Media attribute – what have you done for me lately?

Problem number 1: Presentation and content are coupled#

Problem number 2: Load time#

Problem number 3: User agent support#

@media Ajax London, here I come

I’m an interface developer

Min-width and Max-width template

Reverse text with CSS (32 very special hex digits)

Transparent PNGs and IE6 standalone

Why an alpha transparent image?#

Alpha transparency on modern browsers#

IE6 and AlphaImageLoader#

Making links work in IE6#

Differences between IE6 standalone and IE6#

IE7 Zoom Bug: Text width incorrectly calculated

Separation in the blink of an eye

Dear Justin Timberlake…

IE6 bug: Ignored selector hover bug

The problem#

The solution#

How to structure large CSS files

Order your selectors like the HTML#

Always use the "full path" to elements#