1. You type an URL into address bar in your preferred browser.
2. The browser parses the URL to find the protocol, host, port, and path.
3. It forms a HTTP request (that was most likely the protocol)
4. 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
5. Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)
6. When a connection is open, the HTTP request is sent to the host
7. The host forwards the request to the server software (most often Apache) configured to listen on the specified port
8. 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?)
9. The plugin gets access to the full request, and starts to prepare a HTTP response.
10. 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
11. Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).
12. The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.
13. The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response
14. A DOM tree is built out of the broken HTML
15. 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.
16. Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree
17. Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly
18. The browser renders the page on the screen according to the DOM tree and the style information for each node
19. You see the page on the screen
20. 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…)

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.

• Demo: Fixed top, fixed left, scrolling right
• Demo: Fixed top, scrolling bottom
• Demo: Fixed left, scrolling right

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!

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!

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:

• CSS Compatibility charts
• IE6 vs IE7 – New features in Internet Explorer 7

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 :)

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 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.

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.

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(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.

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?

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.

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?

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 :)

Why not to #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 to #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 to #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?

1. 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.
2. 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.
3. 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.
4. 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.
5. Fluid width (between 1000 and 1250 pixels).
6. Much nicer CSS, with a structure that you can actually follow.
7. 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!