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

Google Chrome as an Internet Explorer plugin

2009-09-23T16:15:49+02:00

I just encountered a quite mindboggling piece of news on the Google Wave blog. It seems they have decided not to support Internet Explorer at all. Not IE6, IE7 or IE8. Surprised? I sure was. What's even better is that to still give these users the opportunity to use Google Wave, they've built a plugin for Internet Explorer, that loads the Chrome browser with Google Wave inside it.

What? Load a browser as a plugin inside another one? I guess this is a real war after all? Who will build the first browser to load Firefox into Chrome? Internet Explorer inside Firefox?

Why? Well, now they don't have to care about Internet Explorer support at all. Felt that heavy weight lift from your shoulders? Suddenly large parts of HTML5, CSS3, and modern javascript, is available to them, with no backporting and performance tuning needed. Must be fabulous.

Now. Combine that with the possibility for the developer to choose when to trigger the different browsers. We're up for a whole new ride. You're invited.

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:

Custom fonts using Cufón

2009-05-08T20:20:17+02:00

If you've worked with webdev professionally you know how it goes. "Why can't a company with a strong visual brand get to use their own font?", the designer asks. Then a long discussion about web fonts follow, where you decide to replace the font with a "web safe" font instead. Or do you?

You could think it's strange that in 2009, we can't use any fonts we want on the web, and I would fully agree. You could ask whose fault that is, and I would reply with a quote from a meeting between browser makers in august 2008:

"My understanding, from Chris, is that supporting direct linking of the fonts would be a great disservice to the independent font industry. A high-level decision within MS says we won't implement that in IE. So what is done other than EOT is [probably] not going to interop with IE. "

"MS" is of course Microsoft, and "Chris", is referring to Chris Wilson, Platform Architect of the Internet Explorer Platform team. The same Chris has also written a longer text about font linking on his blog. I first thought that this was something the font foundries had pushed through, but on the above post it seems that this is also a personal opinion. Browsers (but only IE) need to protect fonts from getting pirated.

And that's the whole reason why we don't have cross-browser fonts on the web today. (Although direct linking to fonts work in all the latest versions of Firefox, Opera, and Safari). Nice isn't it?

Embedding fonts anyway#

Of course, there's still a need to embed custom fonts on webpages. That means clever developers will develop techniques will work around a broken internet explorer. No matter what the font founderies and Internet Explorer team thinks.

My reasoning for why this is a good thing is because that's how everything else works in the browser. Even though anyone can copy an image, we have a big market for stock images. Even though anyone can copy the HTML, CSS, and Javascript of a whole site, we still have people building websites for money. Fonts are no different, and the exact same business model that works for stock images can work for fonts.

***

One popular technique is sIFR, a way to use javascript to replace regular html with flash. Inside the flash you embed the font you want, and voilá, you can use any font you want. sIFR misses one crucial point though: It's far too annoying to embed a font inside a flash movie. You need a commercial program, and you need to know what you're doing. And you're dependent on flash support. It's not that bad, but a bit annoying to work with.

So for a recent project I've been playing with Cufón, which uses javascript, but draws on canvas, or in VML for browsers that don't support canvas (IE). They have an extremely friendly website, which walks you through the process of getting things to work, and the font conversion needed is available directly on the website. I've only used it for simple cases, but it works really well.

All in all, Cufón is a great alternative until IE gets its shit together.

PS. Famous people that don't agree with me:

Richard Rutter, author of the clagnut blog suggests that font founderies server-side generate our fonts on demand, much like Google Maps only sends a part of the map, and not all of it.
Joe Clark: "Quite simply, there is no broad clamour among Web designers to use any font they want."
Jason Santa Maria: "embedding normal typefaces without any sort of precautions is putting it on a silver platter for anyone to take freely. That’s like saying people steal from stores anyway, so let’s just leave the doors unlocked at night :)"
And of course, the IE team…
…and all the typeface makers in the world.

When web development was easy…

2009-02-16T17:02:33+01:00

Do you remember the time when web development was easy? Right where it all started, when there was just one browser, and only one website existed?

Things changed. And now you can't trust anything any longer. Trust me, if you think you know how your site will be shown, you're wrong. Just consider the 10 major steps of "progress" we've made since then:

Browser widths stopped being predictable as soon as people stopped using maximized windows, and monitor sizes stopped being the same everywhere. People cling to their fixed 760px or 960px grids feverishly (yes, me too), dreaming that they are what people use.
Browser heights started giving us the same problems as widths, but toolbars also started showing up, making height prediction plain impossible to predict. "The fold" is now the top 10 pixels of a page, unless you got a browser warning, then "the fold" is pixels 10 to 20.
Aspect ratio, the relation between width and height, went strange when first wide-screen monitors, then TV-screens and mobile phones, entered the market. I wouldn't be surprised if I'm soon able to set my own ratio, or if someone launches a stretchable screen that I can drag to my own preference. I hope your site is well prepared for that one.
Colors differ not only depending on the lightning in the room (which was a problem as soon as there where two computers), but also depending on monitor (including brightness and contrast), gamma correction differences between operating systems, gamma correction bugs in PNG files and browser implementations, color profiles (now supported in Firefox 3.1!). Add to this accessibility tools that invert colors, increase or decrease saturation. Pantone color codes on the web anyone?
Font selection is another interesting mess. The browser has a default font, different (of course), depending on what operating system/device you're on. The website author can try to override that font, specifying one or more fonts, which the user might, or might not, have. Oh, and lets not forget the editors, copying and pasting text from Outlook or Word, getting font tags inserted into your throughly crafted site.
Font rendering complicates things even further by letting either the operating system or the browser render the fonts as they wish. Things like ClearType, subpixel font rendering, and font smoothing.
Character encoding is far beyond repair, and this is easily conveyed by looking at what steps a browser has to go through to render a single letter. To quote Mark Pilgrim: "It's a 7-step algorithm; step 4 has 2 sub-steps, the first of which has 7 branches, one of which has 8 sub-steps, one of which actually links to a separate algorithm that itself has 7 steps…".
Unstyled HTML looks different because of default stylesheets in some (but not all) browsers. Developers are left guessing what styles to set to override all defaults.
CSS styling is of course fully unpredicable, depending on not only browser, but on what underlying rendering engine, and version of that engine, and with what patches applied, and on what settings the user has made. On top of this we have piles of bugs, which tips most developers from scientists, trying to use logic to solve problems, to "empirates", trusting only trial-and-error as a tool to "just get it to work".
HTML versions can also be selected in several ways, not always according to reason. First you can specify no doctype, and watch everyone try to render your site like IE5 once did, long time ago when someone used that browser. Then you can pick a doctype, and watch how some browsers render your page differently, depending on whether your doctype is in their "white-list" or not. And then there's standards mode, quirks mode, and almost standards mode, there's XML prologues and MIME-types, and what-not.

But that's not all, enter IE8#

The newest entry in the "making web development hard" toplist, is (soon to be released) IE8. They have recently decided that your page will be rendered based on popular vote. So better not make your designs "arty" in any way. People might think it's broken and vote you to IE7 rendering (very broken). Don't laugh, it's not a joke, the proof is on IEblog, linked in the paragraph above. I dare you.

"Are you fully out of your fucking mind?", you might be tempted to ask the IE8 developers. The reply is simply, no no, don't worry, just settings this HTTP header you can opt-out of the rendering that popular vote has selected for you, even though you already opted-in by setting a doctype once.

And so we slowly stop caring, and give up. Dreaming ourselves back to the time when there where one computer, and one website…

Who are you disappointing with IE6 support?

2009-02-13T15:29:37+01:00

Internet Explorer 6 (IE6) is not getting any younger. With a initial release date of 27:th of August, 2001, it's one of the oldest things touching the internet with its slimy fingers. Since then, surfing has taken great leaps forward. In all areas: Web standards, Security, Usability, Rendering speed, Debugging, and more. By working hard to maintain backwards compatibility all of us are missing all of that progress.

Now. You as a web developer have a responsibility here.

Responsibility towards IE6 users#

Over the years, IE6 has had 142 security issues uncovered. Still 22 of those are not patched. Most IE6 users have no idea of this, but you do. You don't want these people do to their online banking with that kind of browser backing them. You should help these users by educating them, and making it easy for them to upgrade!

Responsibility towards your employer#

If people are paying you do build websites for them it's even worse. By not pushing for upgrade, you're holding their website back. You're downgrading features since "they won't work in IE6", you're over optimizing your javascript because "the site gets slow in IE6", you're hack around CSS issues with extra stylesheets because "IE6 just don't get your styling right". Each hour you work with IE6 backwards compatibility, is one hour less work on new features. Many developers agree that about half their time goes to planning, testing, and patching IE6 issues. That means you could be twice as productive to your employer it you did things differently.

Responsibility towards Microsoft#

Some people will call me and Microsoft-hater because of this article. You're right, I don't like most things Microsoft do. But that doesn't have anything to do with IE6. I'm fine with people upgrading to IE7. In fact, I prefer people upgrading to IE7 over them switching to Firefox. Why? Because IE7 replaces IE6, making it impossible (or too hard for beginners) to switch back to the IE6 junk.

So this has nothing to do with my Microsoft dislike. In fact the Microsoft developers would be delighted if IE6 just stopped working today. Just consider, how much of the code you wrote 8 years ago are you still proud of? I mean, they just released IE8 RC1 for gods sake! Give them a break.

Responsibility towards yourself#

By subscribing to friendlybit I assume you care about web standards. You have lengthy arguments with table developers over why their way is outdated, you have already talked about Firefox with your friends, and your parents have switched long time ago. But what looks good when you open your mouth, you throw away as soon as you start doing real work. You hack, hack, hack, and patch for IE6. Despite you knowing that this is the wrong way of doing things, despite the pain you feel doing it, despite everything you've read.

What I'm asking of you are two simple things:

Stop saying: "Well, you need to support IE6 at least, that's what everyone else is doing". Instead think like this: "Can I find any reasons that warrants disappointing IE6 users, my employer, Microsoft, and myself". Well, do you? (I'm sure comments will fill up reasons…)
Encourage IE6 users on your website to upgrade. This is really a no-brainer. If IE6 development is so much of a pain, why don't we do more to stop it? Even if you disagree with everything else I've written, you must agree that promoting upgrade is a good thing. Right? This is the code you need:

<!--[if lte IE 6]>

<div id="upgrade">Your browser is 8 years old! Please upgrade to the latest version by going to
<a href="http://windows.microsoft.com/en-us/internet-explorer/products/ie/home">Microsoft.com</a></div>

<![endif]-->

And then style the #upgrade div appropriately. It's easy, doesn't rely on javascript, and points users directly do the download page instead of the three intermediary pages on microsoft.com. Add this to your own site, to your employer's sites, to your sisters site. Or maybe buy one of the numerous IE t-shirts out there. Hell, print it out and stick it on your dog! Do something!

Now. Before you get upset and tell me why your specific case is so different from everyone else. Don't. Remember point 1 above. I've just done point 2 above on this site. Now it's your turn!

(Thanks to Robert for pushing me to write this)