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?