Friendly Bit - Web development blog

HTML5 is not an option

2010-11-03T20:20:42+01:00

HTML5 is HOT! Developers all over the world are adapting their sites, browsers are catching up, and new fallback solutions are released every day. But many developers misunderstand one thing:

You can't choose to use HTML5 or not, your site will be parsed as HTML5 no matter what.

The reason is simple, HTML5 is made to be backwards compatible with the current web, so browsers don't need to keep their current parsers. All of them have soon switched to HTML5 parsers. You want to continue using HTML4? Not possible.

Now. You can choose whether you want to use the new features or not: New semantic tags, Microdata attributes, new form field types, accessibility features, 10-15 new JavaScript API:s (depending on how you count). Lots of new interesting stuff to learn.

So, go read up on HTML5 if you haven't already, but don't think you can keep using HTML4. Your site is being switched over as we speak.

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

Tapestry 5, and how not to treat HTML

2009-07-23T21:39:10+02:00

I've previously written about how Microsoft Sharepoint mistreats HTML, and makes it look a whole other language. But truth to be told, Sharepoint (and .NET for that matter) isn't the only framework that can't handle HTML. I've recently worked with a Java framework called Tapestry 5, and it's really bad in some respects too (though not quite as bad as Sharepoint). Note that this is a review based on only how it handles HTML, not any other of its merits. Let's get started.

Many of Tapestry's problems comes from their design decision to parse the HTML you're trying to output. Yes, Tapestry parses your HTML, and adds stuff to it dynamically. This is nothing new, anyone that has played with ASP.NET knows how hidden form elements get stuffed in here and there. This is a nightmare for an interface developer, we need exact control over HTML to do our jobs well.

Tapestry does horrible things to HTML:

Several extra javascripts and CSS files are referenced in the head tag. There is no simple way to get rid of these.
A meta tag which states that the tapestry did generate this page, is added.
The two above are added to the head, and if a head tag doesn't exist, it gets added. Never mind that your current little HTML snippet was just a little part of a page, that was being fetched with AJAX, Tapestry will add a head tag for you.
More javascript, and a hidden div with a firebug-like console, is appended to the end of the body element.
Self-closing tags are expanded to a start tag and an end tag (<input /> gets transformed to <input></input>), which means you can't use XHTML together with Tapestry.
All whitespace is removed by default, and you have to disable the "feature" on a tag-by-tag basis ("Please don't strip whitespace inside this list, IE6 goes crazy then"). This is a mess for interface developers, who know that whitespace matters for rendering. It was even pointed out to Tapestry developers early on, but was ignored.
There are ways to do loops, if:s, reference variables and generate URL:s, but all of these are based on the HTML parsing. And as a good parser, it skips all comments. This means using tapestry template code inside a HTML comment will not work. When do you need that? Conditional comments! So what if you want an URL generated to your IE6 stylesheet? No go. You'll have to write a custom component that does that for you.
Changes the id of all your forms to "form" and adds name="form" (which is invalid HTML).
Adds a hidden "t:formdata" field to forms, much like the dreaded ASP.NET viewstate.
One of the javascript files added is prototype, a javascript framework which isn't compatible with jQuery. So you have to rewrite your javascript code to work in "No conflicts mode" if you want it to work with Tapestry.

No. Tapestry was clearly not built with an interface developer in mind. Why is it so hard for many web framework developers to just talk with people that work with HTML, CSS, and Javascript? Please ask us before implementing stuff like the above. We'll gladly give you our viewpoint.

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.

HTML includes

2008-11-29T15:18:49+01:00

One of the first questions beginners ask when starting to learn HTML is how to do includes. They seldom know that includes is what they are asking about, but instead feels bad when having to copy and paste that same menu HTML each time they want a new page. "Do I have to type the same thing over and over?".

After asking friends how to solve the problem they get the answer that they now have to learn PHP. Or ASP. Or JSP. Or some other strange language they don't need. And install this thing here, and that thing there. What does your server host support? Oh, no, you need to configure stuff better. No, that setting is insecure… You know the drill, I'm sure you've walked someone through it sometime.

So, a way to include a piece of HTML into a random page would clearly benefit beginners learning HTML. But that's not all:

Browsers would be able to cache components of a page, and therefor load new pages using common components faster.
Less work learning new template languages just to find that language X does not have a way to include things.
Possible to learn componentization by looking at existing sites and learn from them. This is an area we need to be better in.
Easy to make fallbacks by linking directly to the corresponding HTML snippet.

So, how would this be implemented? We need a tag that acts as a kind of include, so what about <object>? Just point to the HTML file you want and voilá, it gets included. Since this is HTML it would work exactly the same across all server-side languages.

Luckily, this is already in the HTML5 spec. At the bottom of the object specification. Interestingly, I found it after writing this article… Great minds think alike :)

In this example, an HTML page is embedded in another using the object element.

<figure>
    <object data="clock.html"></object>
    <figcaption>My HTML Clock</figcaption>
</figure>

Good! And it even seems to work in current browsers (Thanks Siegfried). I've tested it in Firefox, Opera, and Safari, and it works the same in all of them. Internet Explorer 6, 7, 8 (beta 2) just ignores it altogether.

The problem is, the current implementation is to handle them just like iframes. And there's of course lots of problems with that approach:

Currently, an object element without a height and width gets rendered as a 300 x 150 pixel block. There is no reason whatsoever to do this when including HTML. This must change for this to be usable.
The included HTML needs to be stylable with the CSS rules on the page it's included from. Currently, this does not work, included HTML is treated as an iframe. Must be changed if this is to be usable.
Are HTML components full HTML pages? Do they include a doctype and a <head>, and do those get included? I assume only HTML inside <body> gets included in the new page. No CSS. No JS linked to in <head>.
Clicking links inside included HTML should be handled as if the HTML was on the current page. This follows the same concept as if the HTML was included in the server side, and is needed if this is ever going to be used for a menu.

So, what do you think, is this a good idea? Personally, I'm hoping more concepts from template languages start to move into HTML.

Update: Thanks to the comments (thanks zcorpan) I now have found exactly the above in HTML5. It's called <iframe seamless>. It meets all the points in my list, and I'm now really looking forward to the first implementation.

Templated User Controls in ASP.NET

2008-11-18T01:28:43+01:00

Good design repeats itself. It works hard to convey a whole, a feeling of consistency. Once you understand a part of such a design, you know your way around all of it. This is often done by repetition, using the same elements, colors, styles, positioning, and so on. This is a good thing.

Good code never repeats itself. The number of techniques to avoid it are numerous, and all new languages compete in trying to remove as much repetition as possible (Especially the dynamic ones).

Good design repeats itself, good code does not.

With interface development, you face the conflict above over and over again. You get a design that (rightly) reuses the same concepts over and over, and you need to implement them in code that makes you write the same logic only once. This same time both when writing the code and later when fixing bugs in it, and deep inside, all programmers know that it's the correct way to do things.

I'm currently working in a .NET project (EPiServer CMS 5), and is faced with a design that uses the same kind of boxes all over the site. The boxes only differ by color and content, so things like shadows and rounded corners are clear repetition that I want to do only once. I'll do the shadows and corners with CSS, but for that I need a couple of wrapper divs. Divs that I only want to specify once, and then reuse.

The prequisites are:

I want a flexible solution, so I'm not tied to a specific HTML structure (number of divs, or even if I use the div tag or not).
No HTML in properties that get sent to user-controls
No HTML in code-behind (a common way in .NET to split logic (code-behind) and templates (ASP.NET and HTML))

What I came up with was templated user controls. They provide a way to write controls that wrap any other controls you may have, and add content around them. And it's easy to write and user. This is how the one I wrote is used:

<MyProject:Box runat="server">
    <Contents>
        <h2>Random header...</h2>
        <asp:Repeater runat="server">...</asp:Repeater>
        ...
    </Contents>
</MyProject:Box>

It simply wraps anything inside it (in this case a heading tag and a asp repeater), and lets me do whatever I want with them. In my case, I wanted to add some generic HTML around lots of different content, but you could do anything you wanted.

This is how the above was implemented. First the code-behind:

using System.Web.UI;
namespace MyProject.templates.units
{
    [ParseChildren(true)]
    public partial class Box : System.Web.UI.UserControl
    {
        private ITemplate contents = null;
        [TemplateContainer(typeof(TemplateControl))]
        [PersistenceMode(PersistenceMode.InnerProperty)]
        [TemplateInstance(TemplateInstance.Single)]
        public ITemplate Contents
        {
            get
            {
                return contents;
            }
            set
            {
                contents = value;
            }
        }
        void Page_Init()
        {
            if (contents != null)
                contents.InstantiateIn(PlaceHolder1);
        }
    }
}

… and then the "code-front":

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="Box.ascx.cs" Inherits="MyProject.templates.units.Box" %>
<div class="box">
    <div class="boxwrapper">
        <asp:Placeholder runat="server" ID="PlaceHolder1" />
    </div>
</div>

I think this is a really useful way to write user controls, especially for those of you that work as interface developers in a .NET world. Asking the people around me I found that quite a few didn't know how templated user controls worked, so I hope I will be of use to some of you out there. Happy coding!

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?

Sharepoint 2007 – insanely bad HTML

2008-06-07T01:42:51+02:00

Sharepoint 2007 continues to amaze me with its terrible interface code. This is code you stumble over all over the place, both in places where you can hack your way around them, and in places where you just have to live with them. Some things are very hard to live with, let me show you:

ASP.NET developers made a decision once to include some hidden form fields, called viewstate, on all aspx pages. When deciding how to include those fields they chose an input with the type set to hidden. When the Sharepoint developers wanted to do something similar they decided on another route:

<input type="text" name="__spDummyText1" style="display:none;" size=1/>
<input type="text" name="__spDummyText2" style="display:none;" size=1/>

So we have a visible textbox, hidden with CSS, that has a size of 1 character. No wait, we have two textboxes and they both have very descriptive names (NOT). What the heck were they thinking? Why not type="hidden", and remove size? Or, I know, don't add them at all, they are only dummy right? Note that they are empty.

Another strange interface decision is the one to include a skiplink in the page. Skip links are links that help screen readers (and others) to navigate to important areas quickly. There's many different ways to implement them, here's the Sharepoint way:

<A href="javascript:;" onclick="javascript:this.href='#mainContent';" class="ms-skip">

The .ms-skip class positions it far off screen to the left, and the javascript… wait, javascript on a skip link? Why on earth did they not add #mainContent to the href attribute directly? Only they know…

Next in this post is a more philosophical piece of HTML. Look at this:

<span dir="none"><table...>...</table>
</span>

I've heard about setting text direction to rtl (right to left), and ltr (left to right, for some eastern languages), but never to none. Where do text go that has no direction? Inwards? And what about having a table inside a span element?

ASP.NET also have user controls, a way to abstract out important pieces of code, to make reuse easy. Sharepoint of course uses this convenient tool regularly, and comes with a couple of useful ones:

<SharePoint:SPRememberScroll runat="server" id="TreeViewRememberScroll"
onscroll="javascript:_spRecordScrollPositions(this);" Style="overflow:
auto;height: 400px;width: 150px; "> ...

In the documentation for SPRememberScroll you can learn… absolutely nothing about it. It seems to strangely interact with a TreeView somehow, and even worse, it has a width and height! I guess it's good that it's separate from the TreeView itself, so we can remove it from there if we want to forget where we've scrolled to. What?

Sharepoint 2007, note the year there, also both have the classical spacer gif and a new one; the spacer span:

Spacer gif:
<td width="4px"><IMG SRC="/_layouts/images/blank.gif" width=4 height=1 alt=""></td>
Spacer span: <span style="width: 3px; height: 5px;"> </span>

Starting with the spacer gif: Luckily they have their width set twice, both on the image and the cell. Note the "4px" there, you can't use CSS units when you're writing HTML, HTML only knows about pixels. You're glad you wrote the width twice now, right? The spacer span is a fairly new thing I guess, the strange thing here is that you can't set a width and height on inline elements. It just doesn't work, sorry.

If you've built your user controls really bad, you might need a way to let people customize its HTML to make sense. Sharepoint has a couple of different ways to do this, one that they use themselves like this:

<SharePoint:DelegateControl runat="server" ControlId="PublishingConsole"
PrefixHtml="<tr><td colspan="4" id="mpdmconsole" class="ms-consolemptablerow">"
SuffixHtml="</td></tr>">

If you manage to read that, you can see that they are injecting a table row somewhere inside their control (which of course generates a table). Is it just me that feels the urge to add an ending table tag to SuffixHtml just to see what happens?

Another truly interesting interface construct is the datepicker. It's one of these ordinary little calendar icons that opens in a little box and lets you pick a date. How did the Sharepoint guys (or girls) implement that?

<...A href="#" onclick='clickDatePicker(<long id here>, <long url here>, ""); return false;' >
<IMG src="/_layouts/images/calendar.gif" border="0" alt="Select a date from the calendar.">
</IMG></A></td>
<IFRAME SRC="/_layouts/images/blank.gif" FRAMEBORDER=0 SCROLLING=no
style="DISPLAY:none;POSITION:absolute; width:200px; Z-INDEX:101;"
title="Select a date from the calendar."></IFRAME>
<td>...

Ok, lots of code to analyse here, and I've still only cut out the middle of a couple of nested tables. A link with an onclick that opens the datepicker is fairly standard, all parameters needed are encoded into a long url sent to that method. There's an image to click, with a strange img ending tag, but that could have been a mistake. The strange thing here is the iframe that points to a blank image. It's inserted into a table right between two cells (yes, you read that right). That's just insane. If you for some sensational reason have to use an iframe to display some HTML, output it javascript instead of just setting the src with js. Seriously people. Nice accessibility feature though, to have the alt text both on the image and on the iframe. Twice as accessible!

Another not-so-fine interface implementation is the following: They want to show a heading and a list of links. Personally, I would have used a heading tag, and an ul with links in. Sharepoint does it like this:

<div style="margin-left: 4px;">
<div class="level-header"><span id="header" class="headertitle">Division</span></div>
<div class="level-item-pos level-item level-bullet"><span id="header">
    <a href="<url>">Information Technology</a></span></div>
<div class="level-item-pos level-item level-bullet"><span id="header">
    <a href="<url>">Research & Development</a></span></div>
...

They break their own scheme of prefixing all their classes with "ms-" (something that severely messed up my header), they repeat ids, they use only divs and spans, and inline styles.

Do I need to say more? Want to spread the word? Vote on reddit.

Web standards with ASP.NET

2008-05-17T11:46:33+02:00

Good interface code is a mix of CSS and HTML, and while most frameworks offer full control over the CSS, they rarely offer that for HTML. This article looks at how ASP.NET developers can help their interface developers gain that control. Disclaimer: I'm no .NET expert, but too few people write about this stuff, so I'll make a try.

Controls that keep the HTML customizable#

Splitting pages into "controls" is a common way to build sites in ASP.NET. There's lots of different kinds of controls available, and I can't list all of them or name their differences. But I know I don't want to compile a .cs file every time a change some HTML. That pretty much rules out anything but user controls (as far as I know, but any kind of control that fills the above requirements would do). User controls have two sides, one for C# code (code-behind), and one for tags (HTML and calls to other controls).

There's also the issue of built-in stuff. ASP ships with many pre-built controls that help developers push out things quickly, the problem is that almost all of them neglect the HTML (DataList, GridView, …). They only allow setting a few properties, sometimes a CSS class, and assume that's OK. It isn't. I need full control over both the CSS and the HTML to be productive. There's one tag in particular is built with my kind of mindset, and that's the Repeater. A repeater is used like a for loop, but outputs no HTML itself. Instead it allows you to specify some code to output before the loop, inside the loop, every other step, and afterwards. That goes a long way, and that's often enough. If the predefined templates are insufficient, like if you want the last item to be rendered differently, you're out of luck.

I think I agree with the MVC Framework guys in how to solve missing parameters of default controls and bad output: Use C# code inside your templates. Why is this different than the spaghetti code of old ASP? Because you only use layout related logic, nothing else. People tend to think mixing C# and HTML looks messy, but isn't it stranger to make two very different things look the same?

There's also tags like asp:hyperlink, asp:label, and so on; tags that essentially does exactly the same as the HTML they're hiding. Please don't use them, there's no abstraction layer needed for HTML.

Don't repeat yourself - not even in the interface code#

Often when developers move from writing C# code to writing interface code they throw their coding skill out the window. You never copy a C# method just to make it output a different number - you make that number a parameter to the method instead. In the same way, you should never copy a piece of HTML from one place to another - move that code to a common masterpage or usercontrol instead. I've seen this many times, even from experienced developers. Never copy code, it makes for nightmare maintainance.

Also, use nested masterpages. So if you have three pages you need to build, and they have some code in common, you break that common code our into a masterpage. If two of the pages have even more in common you break that out into another masterpage, and let that one use the first one you made. Each Aspx page should only contain what makes it different from the other pages! Repeated HTML can also come in the form of small snippets of code, maybe 10 lines. You might not be able to break that out into a masterpage because it shows up all over the place. For those cases, break the snippet out into a usercontrol instead, and call that. Simple, and DRY.

Disable viewstate#

HTTP is by default stateless. That means that each HTTP request to the server knows nothing about all the other requests made. For scalability and performance, that's a great thing. By default, ASP.NET makes web development stateful. Every form field you fill out gets saved into a hidden form field, called viewstate, and sent with every request. But I'm not talking about performance here, I'm talking about interface development:

To be able to save state across requests there's a hidden form field, and to be able to send that with every request there needs to be a form covering all your form fields. I can't help to think that handling statefulness in the HTML (the view) is the wrong place to do it. Aside from taking away some of my control over the HTML, it also has accessibility issues. JAWS, a popular screen reader, switch to a different reading mode when inside of forms, and while it's possible to get to all content inside a form, it's harder.

So, start by disabling viewstate by default. If you must have it for a certain control, only enable it for that control.

Summary#

There's lots of stuff you can do to make the HTML look better with ASP.NET, and that's a good thing. The bad thing is that it isn't that way by default. Now get out of here and go build some good HTML :)

Use formats instead of microformats

2008-05-17T12:29:26+02:00

The Semantic Web continues to break new ground, and Web 3.0 seems to be a term that people associate with it. In the backwaters of semantics, microformats aims to develop standards to embed semantic information into XHTML. I can't help to think that's strange.

One of the principles of microformats is to "design for humans first, machines second". Still, almost all formats are about adding span tags and class or rel attributes to existing XHTML. Humans will never see those, or benefit from them, unless there's some kind of machine parsing done on top. Microformats were first built by people working with the blog search engine technorati, one of the reasons being to make it easier for technorati to aggregate data from those blogs. So machines it is.

Thing is, if you're going to give information to machines, why not use vCard instead of the equivalent microformat hCard? hCard is just a translation of vCard into XHTML. vCards open in your e-mail program, allowing you to save the contact information there, hCards don't open anywhere. vCards are also just as easy (probably easier) to crawl and parse as microformats.

So what I'm saying is, could we please use real formats instead of microformats?

Update: This article was too fuzzy, so let me clarify: This discussion is about embedded formats vs. formats. The "vs." come from the fact that lots of sites that implement microformats choose not to implement the corresponding format, which in some cases lead to people not being able to use the extra information.

Why the class name "wrapper" is so common

2008-04-30T15:06:27+02:00

We've all heard about how bad it is to use "left" and "yellow" as class names and ids. If you name an element "left", and then decide to move that element to the right, you have to go through all your pages and change that name. Too much work.

If you instead had called it "licenseAgreement", you would have been better off. Right? Perhaps not. Because we're forgetting about CMS:es. Those often have some kind of templates, where you as an interface developer define how the HTML should look. But as a interface developer, you have no idea of what kind of content editors will put into your templates. A couple of clicks later your "semantic id" is wrong.

I think this is one of the reasons semantics hasn't gotten a hold of the CMS world. CMS:es have no idea of what kind of content people will store in them. Their main business goal is to make something generic, that doesn't assume semantics.

This is why "wrapper" is such a common class name.

IE8 is back on the standards track

2008-03-04T07:55:45+01:00

Yesterday the Internet Explorer Team showed a big change in attitude. Listening to developer feedback about IE8, they changed their mind, and now IE8 will render standards mode pages using the latest and greatest it can offer.

This is not only a sane way to approach standards, but it's also a way to say "We're listening and are open to change based on your feedback" (Although saying the reason is the new Interoperability standards and not user feedback is rather weak).

This move is great for both for the web in general and for the Internet Explorer Team. Let there be celebration!

Default HTML in Sharepoint 2007

2008-02-26T00:27:33+01:00

As I've said before, I've been spending time with Sharepoint 2007 recently. The HTML it produces is really bad, and today I thought I show you just how bad.

Sharepoint 2007 has been "updated" to support masterpages, a concept from .NET 2.0. Sharepoint's implementation of masterpages has several problems, but none of them even come close to the biggest problem of them all: default.master.

Default.master is the page that ships with Sharepoint and is used everywhere by default. A quick glimpse at it would make any seasoned web developer feel sick, and I quickly replaced it with something homemade. If you keep reading you will see why. Let's get going with the first line:

<HTML xmlns:o="urn:schemas-microsoft-com:office:office" dir="ltr" __expr-val-dir="ltr">

Things start out really bad, without a doctype on the first line. This mean that all default pages will render in quirks mode, making rendering unreliable across browsers. Next they set an XML namespace, which after some googling points to very thorough documentation (pun intended).aspx). So they mean that it's an XHTML document? No, because XHTML has lowercase tags, and here they use uppercase. The attribute __expr-val-dir just doesn't exist.

A hardcoded link to the 4000 line "core.css" (filled with classnames you have to override by hand), and five external hardcoded javascripts then follow. Then 30 lines of inline CSS and javascript. Then comes the next real beauty, the body tag:

<BODY scroll="yes" onload="javascript:
   if (typeof(_spBodyOnLoadWrapper) != 'undefined')
   _spBodyOnLoadWrapper();">

The funniest thing here is the scroll attribute. Let me paraphrase html.com (found through quick googling):

SCROLL, which is only recognized by MSIE, indicates if there be scroll bars on the page. The default value is YES, so the only reason to use SCROLL is to set it to NO. SCROLL serves little purpose except to confuse and annoy readers by removing scroll bars which are there for a good reason.

I couldn't have said it better myself. There's no reason, whatsoever, to use the scroll attribute. Ever. Especially with "yes" set. Pause for deep breaths. Then we have the inline javascript. Did you know that you could put javascript: inside of onload? Despite all odds, it seems to work. _spBodyOnLoadWrapper() is by the way Sharepoint's way of letting you add javascript to pages. You first do a _spBodyOnLoadFunctionNames.push("YourFunctionName");, and then that code will get run. Insane.

Then we have the typical ASP.NET form, encapsulating the whole page, followed by 18 hidden HTML fields (including the infamous viewstate). Directly afterwards, we have a 60 line mix of inline and external javascript, contained in 7 different code blocks (two that's missing the type and language attribute).

The next discovery can be found three nested tables later:

<span id="TurnOnAccessibility" style="display: none">
   <a onclick="SetIsAccessibilityFeatureEnabled(true);
   UpdateAccessibilityUI();return false;" href="#"
   class="ms-skip">Turn on more accessible mode</a>
</span>
<a onclick="javascript:this.href='#mainContent';" href="javascript:;">
class="ms-skip" AccessKey="J">Skip to main content</a>

I'll wait until you regain consciousness. Hi, welcome back. Yes, they are using display: none and javascript calls to enable "accessibility mode". I mean seriously, screen readers ignore things with display: none set, and we can certainly not always trust that javascript is enabled. I also love the skiplink, and how it sets its own href attibute to an internal link. Note how this code is (mostly) lowercase.

And this is where it starts to get ugly. Every Sharepoint page has a Personal menu and a Site menu on it, containing things you want to do with your account or the current site. Fair enough. This is the (rather lengthy) code for the Personal menu:

<span style="display:none">
<menu type='ServerMenu' id="zz3_ID_PersonalActionMenu"
   largeIconMode="true">
      <ie:menuitem id="zz4_ID_PersonalInformation"
      type="option" iconSrc="/_layouts/images/menuprofile.gif"
      onMenuClick="javascript:GoToPage([url]);return false;"
      text="My Settings" description="Update your user information, regional settings, and alerts."
      menuGroupId="100"></ie:menuitem>
      ... [three more "ie:menuitem"] ...
   </menu>
</span>
<span title="Open Menu">
<div  id="zz8_Menu_t" class="ms-SPLink ms-SpLinkButtonInActive"
   onmouseover="MMU_PopMenuIfShowing(this);MMU_EcbTableMouseOverOut(this, true)"
   hoverActive="ms-SPLink ms-SpLinkButtonActive"
   hoverInactive="ms-SPLink ms-SpLinkButtonInActive"
   onclick=" MMU_Open(byid('zz3_ID_PersonalActionMenu'), MMU_GetMenuFromClientId('zz8_Menu'),event,false, null, 0);"
   foa="MMU_GetMenuFromClientId('zz8_Menu')"
   oncontextmenu="this.click(); return false;" nowrap="nowrap">
      <a id="zz8_Menu" accesskey="L" href="#" onclick="javascript:return false;"
      style="cursor:pointer;white-space:nowrap;"
      ... [five more eventhandlers] ...
      menuTokenValues="MENUCLIENTID=zz8_Menu,TEMPLATECLIENTID=zz3_ID_PersonalActionMenu"
      serverclientid="zz8_Menu">
         Welcome Emil Stenström<img src="/_layouts/images/blank.gif" border="0" alt="Use SHIFT+ENTER to open the menu (new window)."/>
      </a>
      <img align="absbottom" src="/_layouts/images/menudark.gif" alt="" />
   </div>
</span>

There's several things worth a note here (in a bad way). The menu tag Sharepoint uses is in fact a real HTML tag, deprecated in HTML 4.01. Inside of that we have a tag called ie:menuitem that I really can't understand. What on earth is ie:menuitem? Did they intentionally not make it work in other browsers? Everything is wrapped inside a display: none; As you see, tags are also cluttered with event handlers, both real and made up ones. The contextmenu is blocked twice, and a spacer gif is used to add alternate text to the link. The menu icon is hardcoded into everything.

It goes on in the same manner, with tables with the "TOPLEVEL" attribute (and no value), divs with a WebPartId set, PlaceHolder tags rendered directly out in the HTML (instead of parsed by ASP.NET), to end with 200 lines of mixed inline javascript and css. Everything embedded in several layers of nested tables.

In conclusion#

Default.master contains the worst code I've ever seen, and it's really disappointing to see that from a product with "2007" in it. Microsoft have failed in every possible way when it comes to the interface code, and I believe the only way out is to rebuild Sharepoint from scratch (not likely to happen). Having to work with Sharepoint is a real pain, and I honestly don't recommend it to anyone. Put your curiosity to use into something more interesting, like the ASP.NET MVC Framework instead. Thanks for listening.

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.

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.

What italic means

2007-07-05T07:25:09+02:00

Finally an image that dispells all myths about the <i> element. As you can see it's all about presentation. Disappear you foul demon!

(You have more HTML humor? Show me in the comments)

Don’t attach HTML-files in Outlook

2007-05-28T21:42:01+02:00

Just a short word of warning. I thought I'd mail the min-/max-width template to a colleague at work. So I fired up Outlook, attached the file and sent it. I thought that was it, Outlook couldn't get something simple like that wrong, could it? Yes it could! Opening the file I found some pretty nasty changes…

A meta-tag with encoding gets added as the first line of the file (before the doctype). This naturally sends browsers into quirks-mode, effectively destroying most layouts.
Comments are removed from the file, including Internet Explorers own conditional comments. This makes sure any fixes you have applied gets removed, additionally destroying the layout in IE.
External stylsheets are instantly removed. You didn't think you could get away with that, did you?
Links get onClick="return (false);" added, making them not work.

Have a look at the mangled Outlook file (and the original file).

I'm sure there's more Outlook does, but those are the things that I noticed on this file. I've tried sending files and opening it with Thunderbird, and that seems to work, so the problem appears when you open the file from within Outlook, both when run as a native application and from the webmail version.

When sending off examples to your clients, do you know what e-mail client they use? Didn't think so. We better start zipping the files first…

Accessibility as a platform to build upon

2007-02-03T14:00:23+01:00

Two things triggered this post. First a brave participant at the last Geek Meet stood up and asked the question: "Why isn't it ok to require users have javascript enabled?". A few days afterwards I got a lot of good replies to my article about AJAX vs. Flash, claiming that users want multimedia, not plain HTML. To me, those are two different ways of asking one fundamental question: "Is it time we start requiring more from our users?".

HTML: Our history#

HTML has existed for (at least) 10 years now. The first browser, Mosaic, supported HTML and the same documents that where viewable then is still possible to look at in today's browsers. You know those polls that are still made to figure out the percentage of users that support javascript or flash? You don't need those for HTML, everyone supports it. Browsers, Mobile phones, Screen readers, Search engines… Everywhere you turn you have HTML support.

Now. HTML does not have everything you need to make a fully working website. So what you do is add another layer that figures out what the users what and generate HTML for them. It's an easy process and the point is that it does not put any pressure on the user at all, even today you can browse most sites with Mosaic. To me, that's fantastic! We truly have an global format for documents that works everywhere.

Semantic code and web standards did not change the basics, we still use the same header elements that where there from the beginning. What was added was a meaning to each element that had gotten lost in the table-era. Suddenly screen readers could just present a list of headers and know that they presented a balanced view of the site.

But we want more than that!#

In parallell to semantic HTML, Flash and AJAX apps have evolved. They do a good job when it comes to interacting with the user, and interfaces instantly feel more alive. Some developers love them for that.

My thesis is that even though we do want more multimedia there's good and bad ways of getting it. Throwing away 10 years of accessibility can't be the best way? What I want is a way to have both a structured and readable site that is accessible from anywhere, and a site that can give users more interactivity if their browsers support it. Some say it isn't possible, but as a programmer I know that's not true. Based on previous comments I know it is possible to add a flash layer on top of a HTML site; you simply parse the HTML from flash.

You have probably figured this out already but this is what many AJAX apps are doing. They are adding a more interactive layer, on top of HTML. Done right that has incredible consequences for how applications can be accessed by all sorts of devices.

Don't believe those who say accessibility rules out everything else. Use accessibility as a platform to build other apps on top of. Only require more for extras, not the basics.

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?

Forgotten HTML elements?

2006-12-04T19:59:26+01:00

HTML has existed for a long time now with five released versions ([1], [2], [3.0], [3.2], [4.01]). Some very interesting elements have existed in previous versions and I went on a little journey back in time to find and document them. Off we go.

Robert Nyman had a little contest a couple of weeks ago where he gave away an iPod to the person that best motivated why he/she liked a certain HTML element. People gave a lot of good explanations and pretty much the whole HTML 4 specification was covered (even blink!). Knowing that all of HTML 4 was taken, and that he didn't specify what version of HTML to choose, I started searching through the older specs. I was soon stuck in HTML 3.0, and continued reading long after I had found my favorite…

<note> was (and is) my favorite. Specified in HTML 3.0 as an element that's there for all kinds of little notes; a sidetrack to something you are currently speaking about, or perhaps some "operation failed" message. They even go as far as to recommend a few default class names: warning, notice, and error. Nice! Wouldn't this be nice in the current AJAX/Web 2.0 world where everything acts like an application? Why not use note for all those little messages? I could certainly see the use for something like that. Unlike me, the HTML 4 spec writers didn't see any use of such an element, and note was not included in HTML 4.

<fn>, also from HTML 3.0, is up next. Most of the "new" HTML 3.0 elements are aimed at different things that fit into the document metaphor, like research papers and books. So is the next one: fn is short for footnote, a name that clearly defines its purpose. It’s similar to the note element but meant for smaller notes. If you are trying to mimic a book, with references to somewhat disconnected information about something, this one is perfect. But why not use it for things like fancy tooltips while we're at it? Sadly, this element got kicked out of HTML 4.

<isindex> is a bit different from the previous elements. It's defined as far back as in HTML 1, and was included all the way to HTML 3.2. It was meant to represent that a certain page could be searched, but gave the user agent the option of how to get the query from the user. If put in the head of the document the user agent should prompt the user on load. If put in the body it should behave like one of those "search this page" form fields we are used to from Google.com. Needless to say, the exact same thing can be accomplished with a snippet of javascript or a HTML form. No need to let this one clutter the spec. Good removal.

<banner> is another half-breed, specified in HTML 3.0. It's meant for elements which should be set at a fixed position on the page, much like how position: fixed works in modern browsers. From the name you could think that this is an element you would want to block to get rid of ads, but the HTML 3.0 spec mentions that navigation inside the banner element is OK too. I believe the problem with this element is twofold: first, if it was meant for banners only, why should you want to put you advertisement inside it? That would just mean that it would be easier to block, and I'm sure most advertisers would dislike that. Second, if it's meant for "information that shouldn't be scrolled", then what's it doing in the HTML? That's certainly style, and should be in the CSS as well. Another good removal.

<figure> actually has some uses (Also from HTML 3.0). It's meant for all types of media, and has built-in support for alternative content. It has ways to add image maps by using ordinary links and it has support for figure captions. Yes, this is a catch-all for any data that's not in text-format. Have a look at the figure examples in the specification, looks pretty nice doesn't it? Why was this removed? My guess is that the <object> element took its place (see object in HTML 4.01). Object lets you specify more information about the "figures" its meant for, but does not limit itself to images. Yeah, there were reasons to remove figure from the spec too.

Well, that's all from friendly bit. Feel free to read through the specs in search for other elements that I've missed and post your findings in the comments. Perhaps HTML 5 will even revive some of the old elements?

Web development blogs you should read

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

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

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

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

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

Web Standards Hero, episode 2

2006-11-07T22:18:47+01:00

Read episode 1 first

The blistering cold hit him straight in the face as he left the warmth inside. Was it already this cold? He regretted not taking the thick coat he had seen in the closet. The thin jacket he had right now had to do, there was no time turning back. It got a little better as he started jogging.

The table army had gotten quite a head start on him, but even at this distance he could hear their metallic legs marching forward, only interrupted by an occasional crash as they hit something in their way. No screams. Yet.

The town was rather empty on the winter season of the year, and the few permanent occupants had probably gotten to bed by now. A few years ago people would have gotten up from the terrible sound, but hardly any longer. Nightly fights between street gangs had made people afraid, and few would risk being seen.

Our hero increased his speed somewhat. He had an idea of how to get to the town hall before his opponents. The tables would probably keep to the main streets; if they took the smaller ones they might have to split up. They wouldn't risk that, few had any problems breaking a single table. So they would stick together on the bigger streets and he would stay on the smaller ones. He had the exact way plotted in his mind, and felt his speed increasing.

An elderly woman with her dog walked down a dark alley. She heard quick footsteps approaching from behind and quickly hid in the dark, covering the dog's mouth with her hand. From her hiding place she saw a young man with big yellow headphones approaching, he certainly looked to be in a rush; with determined steps and eyes fixed straight forward. He continued past her and she got ready to continue her walk. She threw one last look over the shoulder as to make sure she was safe. Like in slow motion she saw the young man being hit by something and flying through the air towards a brick wall. A screeching roar from a nearby alley convinced her not to linger. She quickly disappeared around the corner.

Our hero woke with his head against something hard. Touching his head he felt that the big headphones had taken the worst hit. The music continued from the other ear and for a while he just laid there listening to the deep base. When he thought about it, the base reminded him about something heavy moving its legs step by step: *Thump*, *thump*. *Thump*, *thump*. That's wasn't the base! He jumped out of the way as another spacer gif hit the ground where he had laid. In front of him was a gigantic black shape. A sign, swinging around its neck as it moved forward, clearly stated: "Made in Dreamweaver".

It really was huge, patched with layer over layer with machine-made material. Our hero doubted that his text-indent gun would be of any use. He knew he had to be smarter to outnumber this foe, but how?! As he nearly got hit by another gif attack as an idea struck him. He looked at the sewer drain, maybe 20 meters away, and started running towards it. He felt the creature behind him, too busy keeping up with him to be able to shoot anything. With a great leap, worthy of an athlete, he jumped over the drain and continued forward. After a few seconds he heard metal break as the creature stepped through the drain and disappeared down into the black water.

Yes! He stood still and tried to catch his breath for a while, and listened to the music flowing from only one side of his headphones. There was no doubt now, he was up against professor Font, the maniac who had killed his parents all those years ago. No one else could have created a monster like that. He felt an anger building up inside him and with eyes shining of feverish determination he continued towards the town hall.

Oh jolly gosh! What an adventure. Will our hero make it to the town hall in time? And where are those cookies you promised last episode?! Stay tuned for another episode of… Web Standards Hero!

Web Standards Hero, episode 1

2006-10-24T19:10:00+02:00

With a long sigh he throws himself into the big leather sofa he invested in last summer. After a long day of angry customers bitching at him he really needs some rest. That idea to get a job at the local grocery store was not his best ever.

On the nearby foot rest a cup of warm chocolate spreads a little cloud of warm smoke. It's all nicely quiet, and he has had too few hours of sleep lately. Another big sigh and he feels his eyes slowly closing. The world turns blurry…

Out of nowhere a screeching sound breaks the silence! He's on his feet instantaneously and sees his warm chocolate make patterns in the air from his accidental kick. Damn it! The sound grows into something unbearably high-pitched and his hands unconsciously cover his ears. Where's that sound coming from? He pushes his body to move towards the sound, towards the big window against the street.

Stunned he looks at the procession before him: thousands of metallic tables march the street, drawing their wicked legs against the ground and crashing into everything around them. The sound is unbearable! With hands pushing harder against his ears he ponders: Do they marsh on their own? Highly unlikely, he quickly concludes: tables normally stay in the shadows and stick together to protect each other. The answer to his question is sitting at the top of one of the bigger ones: an old school webmaster swings his whip above him, pushing them forward.

This is serious. He takes a few steps backwards. The webmaster he saw was armed with at least 50 deadly spacer gifs, all ready to be thrown at anything that passes their way. Visualizing the town map he sees where they are heading, towards the town center. The public offices there are an easy target for them. He needs to act.

Temporarily letting the terrible sound reach his ears he quickly searches through a wardrobe for his old headphones. And there they are, huge like those ear defenders used by construction workers and bright yellow in color. He puts them on and welcomes the silence and the disguise. No one will recognize him with these on. He picks down a large wooden box from the top shelf. It has been several years since he last used it, but this calls for the heavy cavalry. He opens the lid and lifts up the big text-indent gun. A screw on the side adjusts it to 10000px, and attaches it to his belt after spinning it over his finger. This will get ugly.

Before leaving he stops at the door and picks up his mp3-player, plugging in the headphones and raising the volume. The electric beat steadily increases as he leaves he apartment with a clear goal in sight: to kick some serious table ass…

What will happen in the next episode of Web Standards Hero? Will our hero be able to stop the tables from reaching the town center? Will there be cookies? And what does professor Font have to do with all this? Stay tuned!

Update: Episode 2 available

How web standards feels

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

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

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

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

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

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

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

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

(Inspiration from Motivating others)

Encyclopedia of HTML elements

2006-09-20T23:53:36+02:00

HTML is a much richer language than what it's used for. There are 77 elements and each one has a certain purpose. It is possible to find that reason by reading the specification, but who does that? I wrote this list as a way to tell you what I think each of the HTML tags should be used for, common problems you might encounter, and general advise about each one.

I've included all the elements from HTML 4.01 Strict. It's a long one, but I'm sure you have more "tips and tricks" to add to it. Leave a comment and I'll add yours to the list too. Let's start off with a list of all the elements:

A, ABBR, ACRONYM, ADDRESS, AREA, B, BASE, BDO, BIG, BLOCKQUOTE, BODY, BR, BUTTON, CAPTION, CITE, CODE, COL, COLGROUP, DD, DEL, DFN, DIV, DL, DT, EM, FIELDSET, FORM, H1, H2, H3, H4, H5, H6, HEAD, HR, HTML, I , IMG, INPUT, INS, KBD, LABEL, LEGEND, LI, LINK, MAP, META, NOSCRIPT, OBJECT, OL, OPTGROUP, OPTION, P, PARAM, PRE, Q, SAMP, SCRIPT, SELECT, SMALL, SPAN, STRONG, STYLE, SUB, SUP, TABLE, TBODY, TD, TEXTAREA, TFOOT, TH, THEAD, TITLE, TR, TT, UL, VAR

For people that view this site in a visual browser I added colored bars on all the elements. They represent if an element is recommended to use or not. Green bar means "Use this!", Yellow means "Consider if you really need it", and Red means "Don't use this unless you have a really good reason".

A - Links, the very foundation of the web#

Should have the href attribute, but be sure to not include & in it. Write that as & instead.

Don't put blocks (divisions, paragraphs) inside of links or you will get a validation error.

If you set display: block on a link, you can set its width and height with CSS.

ABBR - Explain what your abbreviations mean#

Abbreviations are words which are short forms of a longer word or phrase. Examples include HTML, int, and Amex

Should have a title attribute with the explaination of your term.

Make sure this explanation is humanly readable (unlike how it's used in microformats). It's here to help people not machines.

ACRONYM - Special case of the above where the word is formed from beginning parts of the words in a phrase#

No need to use this one, abbr is enough. Do we really need to differ between acronyms and abbreviations? What about initialisms and the other types of words?

ADDRESS - Contact information of some kind#

Can be used for more than just street addresses, be creative! E-mail address and other contact info?

AREA - Define links in any shape#

Useful if you need clickable links in odd shapes. A possible example of this is a map with clickable regions.

CSS sprites is another way of doing something similar using CSS.

Don't forget to specify alt text for your area links.

Isn't the shape of links really design? Should be specified in the CSS then, not in the HTML.

B - Make text look bold#

Don't use. Boldness is design and should be specified in the CSS using font-weight: bold;

If you intended to show that something was very important you can use <strong></strong> instead. It describes the meaning better and has the same default styling.

BASE - Change your links to be relative to this address#

If you have to use this one, you're probably doing something wrong. I've seen terrible sites using this one.

There's a very strange Internet Explorer bug with the base element

BDO - For foreign languages (ie. Hebrew), mark text direction#

This is a tricky one. I wouldn't say text direction is structure (and belong to the HTML), but it isn't design either (and belong in the CSS). Perhaps it's content?

Text direction can be set in the CSS with the dir attribute

BIG - set larger text relative to surrounding text#

Don't use. This is design and should be in the CSS. Use font-size instead.

BLOCKQUOTE - Longer quotes#

Include one or many paragraph(s) inside of this one.

Takes a cite attribute but this isn't rendered in browsers so use the cite element instead.

Don't ever use this one for indenting text, there's margin and padding in CSS for that.

BODY - All your real content goes inside this one#

Always use (even though a page without it for strange reasons still validate).

Never use bgcolor, background or the a-/v-/link attributes on body. Those can be set by using CSS instead.

Set a class or id to the body on each of your different pages if you want to style them differently. By using body#contact div, you can easily style all the divs on only the contact page.

BR - Line break#

Instead of marking the line-breaks between your items, mark the items! For ordinary text use paragraphs around each text block instead of breaks between them. Use a lists and add a line item around each of the items instead of separating them with line breaks.

A valid use-case is poems, where line breaks are part of poems themselves.

BUTTON - Alternative to inputs with types submit and reset#

A much more general way to add buttons to your form elements (Thanks Rowan Lewis for correcting my misstake.)

Allows you to add more than just text as the label, wrap the content you want inside of the button element.

CAPTION - Description of a table#

As many other table elements, caption is sometimes hard to style with CSS in some browsers. If you start to get into trouble, use a header instead.

CITE - Source where quoted text originated#

Use together with blockquote to connect the quotation and source.

Can be used to mark something as reference by wrapping cite around it. This could be useful if you are talking about a book but don't have a link to it.

CODE - Computer code example#

Perfect for authors writing about computer code.

Don't fall into the trap of using the lang attribute on code to specify what computer language your code is written in. The specification clearly states that's not allowed (I need to fix one of my plug-ins that does that on this blog). Thanks trovster.

COL - Used to specify that some table cells belong together in columns#

A very nice way of setting attributes of columns of cells in a table. Why not use this to set a class on that last column of cells you want to give that grey background?

Keep using table headers, this is not a replacement for them

COLGROUP - Shorter way of specifying table columns#

Use colgroup instead of several col elements by setting the span attribute to the number of columns you want to affect.

DD - Description of a term in a definition list #

Several dd:s after each other means that there's many meanings to a certain term.

DEL - Mark deleted text in documents#

Good for marking up document revisions, where one author makes changes and what to clearly mark where.

An interesting idea is to use this for version management (together with ins). Probably rare but an interesting idea. An example is how this is used at Wikipedia when comparing historical versions of an article (thanks Fredrico).

I have never seen an example where this element would be appropriate. Very rare.

Some screen readers are uncertain of what to do with the text inside of a del element. Should it be included in the page content or not? Be careful (Thanks Peter Krantz)

DFN - Term that's being explained by you#

Useful when you explain a term in the middle of a sentence. Add dfn around the word you explain.

A definition list is more appropriate if you want to explain many terms at the same time.

DIV - Divider into logical parts#

Divide the page into logical parts. Typical examples are "header", "content", "sidebar" and "footer".

Divisions should only be used when there's no other better fitted element available. Keep the number of divs down as much as you can.

A similar element for inline stuff is the span element

DL - List of definitions#

Very useful for glossaries where you provide a term and it's explanation.

I use it much wider than just the above, more like a structure for matching key and value. Say you have a list of people and their preferred colors. I would use a definition for that.

Use dt for the key and dd for the value

DT - What you define in a definition list#

If you put two dt elements after each other that means that the two terms means the same. The explaination that follows applies to them both.

EM - Important phrase#

Use this to mark some part of your text a bit more important. Try not the think of the default styling, think importance.

If you want something stronger, use strong.

It's not always possible to just change a italic element to a em element, are you really using it to mark up importance?

FIELDSET - Groups form elements that belong together#

Perfect if you have a first and last name in two different text fields and want to show that they belong together.

A legend element should be put inside of the fieldset to label it.

Fieldset borders are tricky with different browsers, I generally disable them with border: none.

Don't fall into the trap of using fieldsets for non-form elements. They are meant for grouping form elements, nothing else.

FORM - Wrapper for all kinds of form fields#

Use the form element just like you would use a div, like a wrapper.

If possible make sure your forms work without javascript enabled. I'm not asking that your sliding-fadeout-gradients are working, just make sure the basic stuff gets through.

H1, H2, H3, H4, H5, H6 - Headings for your sections#

One of the most important elements in HTML. If you don't have any headers on a certain page you're most certainly doing something wrong. Think about your structure!

Always start with the h1 element. If you don't like the size, change it with font-size.

Don't skip levels of headings. If you have a h5 on the page, all four previous levels should be there too.

Different browsers have different default sizes for headings. Make sure you set the size for every one of them to get rid of that problem.

HEAD - Container for meta data in the document#

For validation, you only need a title inside this element, but typical documents have a link element for the stylesheet, a script element for the javascript, and some meta data inside meta elements.

HR - Horizontal line#

Don't use. This is design, the same effect can be accomplished through border-bottom in CSS.

Some people claim that hr is a section divider, but isn't that what we have divisions for?

HTML - Wrapper for everything except the doctype#

The HTML element can be used as a wrapper (an outer div around all content). Use this to get rid of one unnessesary wrapper.

Also takes the lang attribute that tells browsers what lanugage the site is written in (thanks Ben Millard). This is extra useful for screen readers that needs to change their pronunciations. Language codes are available through the US Library of congress. Use the two letter variants.

I - Italic text#

Don't use. Purely presentational way of adding italic styling. Use the em element instead.

IMG - Embedded image#

Used incorrectly very frequently. IMG should only be used for images that can be considered content on the page. An example of this is a thumbnail gallery or a helpful image somehow connected to the text. Things that shouldn't be img elements are decorations: rounded corners, bullet points in lists, and page dividers. Use background-image in CSS for that instead.

If the image contains information that you want to convey, use the alt attribute to give that information to user-agents that doesn't load images.

INPUT - Radio button, check box, text field, button, or hidden data#

Element used as a building block for form fields. The type is determined by the setting the type attribute to either radio, checkbox, text, image, submit, reset, or hidden.

Other elements normally used together with this one is select and textarea.

Make sure you add an id to each input field and tie an label element to it. No input should be without it.

Wrap your inputs and labels in a fieldset, paragraph or div to stop the validator from complaining that elements are not allowed where they are.

INS - Inserted text#

Similar to del, this element can be used to mark deleted text.

Might be useful for tracking changes in your document but again, I have never seen a site where this element was needed.

KBD - Text that should be entered on the keyboard#

One of the numerous elements that can be used to mark up documents about computers. Rarely used.

How do you know your user will use the keyboard?

LABEL - Text that describes a corresponding form field#

The for attribute associates this element with a form field id. Important out of an accessibility standpoint, both because it gives screen readers better info and because it makes form fields clickable (in most browsers, but not Safari, thanks Roger).

LEGEND - Heading for a fieldset element#

Wrap this element inside each of your fieldsets to provide a reason why you think the following fields belong together. Typical examples include "Credit card", "Full address", and "Shipment details".

Somewhat tricky to style since browsers handle them very differently. I tend to keep them pretty plain.

LI - Items in ordered or unordered lists #

Gets different styling by default depending on browser: padding-left or margin-left. If you want to change the indention, make sure you first reset the other one.

LINK - A way to define links to other elements#

Most often used to define external stylesheets for the document (use rel="stylesheet")…

.. but can be used to define other types of relations too. Some browsers show custom rel types to users like a list of bookmarks.

MAP - Wrapper for image map areas#

Used together with the area element for image maps.

META - Information about the document#

Can be used to for custom information about the document.

Search engines use some predefined names that you should know about.

NOSCRIPT - Content to show if the browser doesn't support javascript#

The default should be to show content that does not require javascript, we don't need a certain element for that.

OBJECT - Embedding other types of information in to document#

The new way of adding flash, quicktime and other multimedia content to your site.

OL - Ordered list of items#

Ordering means that the content only makes sense in that order. This means that a step-by-step recipe is an ordered list, but a basic navigation menu is not (see unordered list).

OPTGROUP - Group your option elements#

One of the least known elements in HTML. Impress your friends!

Similar to fieldset but for option elements. Wraps around them and uses the label attribute to name the group.

Nesting of optgroups is not allowed.

OPTION - One of the choices in a select#

If you set the value attribute, that value is sent instead of the text inside the element.

P - Wrapper around each of your paragraphs#

Replacement for line breaks (the br element).

By wrapping all your paragraphs in a p element you can easily change the space between them with margin or padding.

PARAM - Set properties on embedded objects#

The exact param names used depends on what you embed, check the documentation for the document you are dealing with.

PRE - Preformatted text#

Used to define that a certain piece of text is formatted (designed) in the HTML. While this is most often a bad idea there's applications in e.g. ASCII art, text-only e-mails, and Python code (thanks zcorpan).

Use white-space: pre; and font-family: monospace; to get the "pre design" with CSS.

Q - Add quotations in a language independent way#

Instead of setting what kind of quotes you use (there are several you know), you simply define that you're dealing with a quote and work out the details in a separate file.

Good idea, but no support by IE6 makes it a lot less useful.

SAMP - Sample text or characters#

Seriously, don't we have enough of the computer related elements already? If you need sample text that isn't code or keyboard type-in then fine, use this one.

SCRIPT - Run javascript on your site#

Remember to set the type attribute to text/javascript if that's what you use. Language is no longer needed.

SELECT - Let the user select among a number of fixed options#

Don't forget to use a label for this element too.

It's easy to make selects work without javascript, just add a submit button. Also check so that all options can be reached with the keyboard.

Selects take the size attribute which makes you able to show more than one option at the time. If you set size to something larger than one, you can use CSS to set a height.

SMALL - Presentational way of setting font-size#

Don't use. A presentational way of saying that some text is smaller than the rest. Use font-size in CSS instead!

I've seen some interesting ideas of using this tag for "fine print", those copyright messages that always are tiny. The idea is that the size really is tied to the content, and that small therefore is a good semantic way of representing it. I'm not sure, for now I won't recommend people using it.

SPAN - Similar to div but for inline elements#

Can be used when you don't find a better representation. Make sure the class you set describes what you mark up instead.

STRONG - Mark something as very important#

Stronger than emphasis with the em element.

STYLE - Add style info to your page#

Needs to be in the head section of the page, inside body isn't valid.

Don't forget to set the type attribute to "text/css".

In my opinion, using link separates the design better than using the style element. It also makes the browser able to cache the CSS.

SUB, SUP - Raised and lowered characters#

Don't use for lowering and raising letters with no semantic meaning.

Use in math or chemical formulas (see comments).

TABLE - Row and column based data#

Misused in the "tables for layout" days. Tables. Are. Not. For. Layout.

Proper use is for scientific, statistical, or other cell-based data.

Frequently forgotten elements include the thead, tbody, and th elements.

If you nest tables you are doing something wrong.

You can set border-collapse: collapse; to get rid of the annoying default cellpadding. No attributes need to be set in the HTML.

Combining border-collapse and a border on td elements makes it possible to get nice 1 pixel borders between all cells.

TBODY - Container meant to separate the body of your table from your headers#

Simply use this as a way to style your body different from your headers. Have th elements both in the tbody and thead? Then use tbody th to style only the ones in the header.

You can use several tbody elements, something that can be a nice way to divide one big table into several logical parts.

TD - Represent one cell of data#

Use padding, margin and border on td and th to change the spacing inside your table.

TEXTAREA - Let users send big chunks of text#

The size can be specified with height and width in CSS.

Don't forget a corresponding label element.

TFOOT - Extra information in the bottom of a table#

I rarely use this one, most often a caption is what I want below.

A possible use case for tfoot is for adding column sums at the bottom of the table.

TH - Specify that a certain cell is not part of the data, it just describes the other cells.#

Very convenient way of specifying a different style for the headers of the table.

Takes the scope attribute if you want to specify what cells a certain table header describes.

THEAD - Container for (some of) the metadata for a table#

Some browsers repeat this element on all pages when printing long tables, very useful!

TITLE - Topic of the page summarised in a few words#

Single most important part of your site, think a while before setting it.

Meant for a single page, not the whole site.

Required for validation, and gives strange validation errors about "head not closed" if not included.

TR - Way of specifying rows of table cells#

Very few browsers support styling the tr element, so set your styles on the containing table cells instead. Example: If you want alternating row colors you can set a class on the tr element but style the table cells with tr.odd td.

TT - Text formatted like if it was written on a typewriter#

Don't use. Presentational way of adding text that looks like it was written on a typewriter. Use font-family: monospace; to get the same effect with CSS.

UL - List where the order doesn't matter#

Perfect for navigation menus, don't use br for that.

See tip on cross browser use with the ol element.

VAR - Variable of some kind#

Another element from the computer science area. Some people claim this can be used for other variables too, but that's a really rare use case. No need to remember.

What did I miss? Please leave a comment!

Why XHTML is a bad idea

2006-08-27T15:11:26+02:00

XHTML is often mentioned when you talk about web standards of different kinds, and many believe that it's the future of the web. I'm of a different opinion and this article explains my reasoning.

Some HTML history#

A long time ago, in 1990, the first pieces of HTML came to use. It was built specifically for scientific documents and contained nothing by structural elements. The idea was that the user should be the one deciding what a certain document looked like; after all, you read reports for their content, not for their looks. The target audience for HTML was pretty clear, scientists and other computer literate people: programmers in some sense.

The web soon became mainstream. Everyone has now surfed the web and lots of people have their own websites. But far from everyone care for code quality and most websites contain serious code errors. Despite the errors it's worth to remember than most sites "work", that is, they display like the authors want. All thanks to the error-handling of the current browsers.

An angry community of programmers/webmasters has complained about bad code since the beginning and demanded that we force people to only produce valid code. I've been a part of this group in the past…

XML enters the scene#

Around 1998 the specification for the XML language was released. XML is a language that makes it easy to construct your own languages. Think of it like HTML, but where you make up your own tag names, and where errors are not allowed. The programmers took it in as their new favourite and it spread quickly.

XML has very precisely defined error-handling (unlike HTML): when the parser finds something unexpected it just stops and displays an error. This means two things: it makes editing XML documents closer to "real programming" (if you make a small error it doesn't compile), and since you don't need code for error-handling the parsers become both faster and easier to write. As you can imagine the programmers felt at home.

"Let's make HTML work like XML"#

W3C was founded and the programmers from the angry HTML community had made an impression on them. They decided to do something about the lousy code people wrote and standardized a new language for the web. XHTML takes the tags from HTML but adapts the language so that it becomes compatible with XML. The result is a language that can (and should) be parsed with an XML parser.

So all is well then? No. As you poke around you'll soon notice that it's pretty damn hard to get XHTML parsed with an XML parser in current browsers. Let me explain: to decide what parser to use you need to send the correct MIME-type from your server. If you're using PHP you can do it like this:

<?php
if ( stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml") ) {
   header("Content-type: application/xhtml+xml");
}
else {
   header("Content-type: text/html");
}
?>

That pretty much asks the browser if it can handle XML and if it can sends the XML MIME-type "application/xhtml+xml". If it can't handle it (Internet Explorer 6 and 7 can't) it gets fed the old MIME “text/html” (and errors are tolerated and corrected).

But that’s not the only change you need. In the late 2004, Ian Hixie wrote Sending XHTML as text/html Considered Harmful (quite technical). As you read through it you see that you have to change a lot more than the MIME if you want your XHTML to work as intended. Summary: doing it the right way is hard.

Problems with using XML on the web#

So XHTML is hard to get parsed the intended way in current browsers. Instead most people using it decide (or don't know otherwise) to parse it like if it was HTML. But doesn't that defeat the biggest reason to user XHTML in the first place? The only big difference between HTML 4.01 and XHTML is that XHTML can be parsed as XML! As long as you parse your code as HTML there's no reason to use XHTML.

If we have a look at the specification of XHTML there's a little table displaying what versions of XHTML that should be sent with what MIME type. You'll see that it's ok to send XHTML 1.0 as text/html (may). But looking forward to later versions you see that they "should not" be sent as XHTML. So pretty soon, parsing XHTML as HTML will not be allowed if you want to follow the standards. That leaves parsing it as XML.

Imagine some kind of dynamic site that allows readers to add content to it. The comments of this site are a good examples. If I used XHTML (and parsed it properly) and someone used invalid code in the comments the page would break. New users to the site would get a big and ugly error message with a line number and some code. Totally unacceptable. So I would have to find a way to parse the HTML in my comments and fix errors that could break the page. Ok.

Next I copy-paste some text from a site I want to quote to you. When I publish the article I get a big ugly error message because the site I pasted used another character encoding and that breaks my XHTML. I research the problem and find that this could be fixed by parsing all text in my admin console and making sure it's valid UTF-8 before storing it in the database. Ok.

Next I download a bit of javascript and try using it on the site. Again people get an ugly error message in their face when they enter. It seems javascript is handled a lot stricter in XHTML and inline javascript needs some strange CDATA characters at the beginning and end of the script element. Ok, so I fix that too.

And like that it continues, tiny differences in code makes the page break over and over again, and bugs in the parsers I write makes people able to break my site by posting content. I have a computer science education behind me, so I could probably fix the errors and keep patching the site until everything works. But do I want to? What's wrong with the current way of fixing errors when I notice them when validating? And what about all the non-programmers?

We can't expect beginners to use XHTML#

As you've read above it's damn hard to get XHTML right. Still the W3C pushes for XHTML as the new standard for the web. Despite how hard it will be for beginners to get things right. Despite that you will move error handling to the parsers of each website instead of the browsers. Despite that XHTML has almost no backwards compatibility so pretty much all sites on the entire web will have to update their code.

No, I won't parse things as XML on the sites I build. XHTML was a bad idea from the start and I'd rather go with the new version of HTML developed under the name Web Applications 1.0 (also known as HTML 5).

I hope this article explains why a lot of web development blogs (including Friendly Bit) use HTML. What language do you use?

Update: More reasons why you should use HTML

KTH goes web standards

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

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

About KTH#

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

Polopoly and the HTML#

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

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

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

CSS and the techniques used#

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

Fixed width layout#

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

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

Zoomable layout#

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

Source ordering and skip links#

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

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

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

3 column equal height#

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

Front page grid#

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

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

Conclusion#

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

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

Tricks to make your site easier to use

2006-08-01T19:17:40+02:00

There are lots of little tricks you can use to make your sites easy to use. Problem is that they are so obvious, you don’t think of them. This article is an attempt to share some of the ideas that I did think of. I'm sure I missed some; feel free to add your own tricks in the comments.

You rarely think of sites as "easy to use"; they just work. You enter them, click here and there, and don't think much about how the navigation works or what to do. That's the feeling we should go for.

Separate the interaction layer#

A very simple way of making it easier for your users is clearly marking what can be interacted with. Are users expected to click on those small arrows of yours? Are the only links to your content through your headers? Then you better make sure those arrows or headers come across as clickable.

The fastest way to convey that something is clickable is using blue underlined text. Why? Because that's what most sites use (see Google, Amazon, eBay). It's what we have grown up with and it just works. Designers tend to dislike blue underlined links and have started to use other colors and skip the underlines. Jakob Nielsen, the notorious usability expert, writes about what you should think of in his article about the visual style of links. It's a good reminder.

You don't have to stop with just the links though. Are your images clickable? Then make sure they connect with your links somehow. If you pick orange as your link color, make something around or in the images use that color too. Make your form fields use the same color. When someone enters your site it should be possible to quickly get an idea of what to do: "I can either click a link in the menu, search for a phrase, or click this thumbnail". Don't make people confused by mixing in orange on the static parts of your site.

With some cleverness I'm sure this idea can be expanded to work even without being dependent on color. A small figure? A border? Use your imagination, and be sure to tell me about it.

Split up your content#

You know those portal sites? There's one big reason they don't work. There's too much content cramped into a too small area. A portal is rarely about something specific, it's about everything that they can possibly fit in. Whatever content you are looking for you will have to search hard for it. Do you use the portal parts of Yahoo or MSN? Didn't think so.

There has been a long discussion recently about how badly designed pages work better. Like Andy Rutledge I mostly disagree but I can understand how bad design works for ad-driven sites. Is the point of your pages to make people click ads? Then make them confused, make them think your navigation is the ads, I'm sure it drives your revenue up. If the point of your site is the content on it, stay away from being a portal.

The simplest way of avoiding the portal-look is splitting up your content. Do you have info on both crocodiles and stock numbers? Don't put them on the same page. Make sure only the people interested in stocks get the stock info. Anyone else will just see them as "something I am not looking for". If you have lots of info from diverse fields, perhaps a directory is a better bet?

Use `<label>` for form elements#

Bad form elements are one of the most annoying things on the web. Worst are those tiny little checkboxes you need to check to specify if you like to get spammed or not. They are simply too small. There is an easy solution though, that everyone should be aware of: the label element. What it does is associate some text with the checkbox. The browsers use this information by making a click on the text check the box. Note: this also works for radio buttons. Here's the markup you need:

<form action="">
<input checked="checked" id="send_spam" type="checkbox"><br>
<label for="send_spam">Send me all your "newsletters"</label><br>
</form>

label { cursor: pointer; }

There's a lot more to learn about how to make your forms usable and accessible. Just head over to the Web standards project's Accessible forms tutorial (don't miss the intermediate one either).

Make it interesting#

You have a few seconds to get you visitor hooked to your site. In that time the user needs to understand he's on the right track. "Ah, this site seems to be about web development" is what I want my users to feel when they enter Friendly Bit. Therefore almost all my pages have a little info box that tells the visitors just that. To just put this info on your front page isn't enough, search engines or other external links can make them enter deeper into your site. Please put this little info-box somewhere on all of your sites. It's one of the best ways for me to see I'm where I want to be.

To actually get your content interesting you need to work on your writing. My best tip is to follow the points Liz Strauss summed up nicely in her post about what a reader wants.

Read through your text over and over again, out loud if you need to. Pay attention to typography, don't make your paragraphs too long and use headers extensively.

Conclusion#

These are just some of the tricks I find myself using on my sites. I'm sure this site does not follow all of them perfectly but that doesn't stop me from telling you about them, does it? Pick and choose as you like, but try to reach make you visitors feel that "it just works"-feeling.

Do you have any tricks you can share?

Correcting the 20 pro tips (.NET magazine)

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

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

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

Stylesheets: importing vs linking (point 3)#

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

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

Smarter gradient backgrounds (point 4)#

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

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

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

IE Box Model Hack (point 8)#

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

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

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

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

Space saver (point 9)#

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

Format fundamentals (point 11)#

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

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

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

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

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

Wrapping text around images (point 17)#

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

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

Challenge: Marking up the world cup

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

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

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

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

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

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

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

Current issues with Microformats

2006-07-01T17:52:06+02:00

A couple of weeks ago I attended Geek Meet in Stockholm. It's a small group of people gathering to talk about semantics and share their knowledge of front-end webdev. It was the second meet and, just like on the last one, I had a great time. It's something special meeting up with people that share your interest for the small niche front-end web development is.

On that meeting Peter Krantz held a presentation about microformats, a way to standardize small snippets of HTML you use often. What was different with the presentation is that it wasn't just praise like many new techniques get. The presentation showed both the good and bad sides, and didn’t close with a final conclusion of whether it should be used or not. This article is my view of microformats (and includes some of the issues from Peter’s presentation).

What are microformats?#

Microformats are small standardized snippets of HTML. They are standardized to make it easier for crawlers/robots to find certain types of information. One idea could be to make contact information easier to find for a robot and letting anyone build a directory out of this information. Browsers could support this and display information in some special way. Sounds like a pretty good idea to start with, doesn't it?

Microformats are not restricted to contact information, hCards. There's also hCalendar for description of events, hReview for reviews of things and so on. You'll find the full list on the microformats wiki.

An example of a hCard:

<div class="vcard">
   <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
<div class="org">Technorati</div>
</div>

Serious problems with the format#

Microformats are not perfect. The first problem is that they don't use namespaces. Namespaces are some way of describing what you mean with a word and in this case it applies to the class name of the formats. Check the example above. If you wrote a robot, how would you recognise an hCard? The only information available is the class name of the above. This means you would need to search each page for that class name. This is quite inefficient from a parser’s point of view.

What's worse, this means no one can use the class name "vcard" on their pages, that would make the robots get faulty information. Even this post probably breaks a few parsers because the code example above looks pretty much like an hCard. I hear the counter argument, "but no one uses vcard as a class name if they don't use it for that", I can only tell you I just did.

Multiplying the damage of not using namespaces is versioning. Compare with HTML, where in early versions of HTML a Doctype was not needed. Then the authors decided that the format needed an update, and with the update new elements were added. Without a doctype the browsers couldn't tell the difference between the formats and the doctype was added in. This is exactly what will happen with hCard (or any other microformat that doesn't use namespaces) if needs to get updated.

Is versioning a problem? Not if the format is perfect from the start, without any kinds of problems that need to be fixed in future releases. You see where this is going right?

Except for the issue with namespaces and parsing of class names we also have dates. Dates with time included are in the hCalendar format marked up with the abbr element. It looks something like this:

<abbr class="dtstart" title="20060621T1030-0700">21 june 10:30</abbr>

Is the title attribute used correctly here? I think not. The abbr element is meant to give users that do not know what a certain term/expression stands for a short explaination. In the example above it's not easy guessing that "T" stands for time and that the number afterwards is a notation of time zone (GMT-7 or PDT-7?). All of this is of course possible to read from the ISO specification, but people hovering your link will not do that. The title attribute on abbr elements should be humanly readable!

If you still don't agree with that you can check out ISOs own text about ISO 8601. Under "Advantages of ISO 8601" you can see:

Easily readable and writeable by systems
Easily comparable and sortable
Language independent
Larger units are written in front of smaller units
For most representations the notation is short and of constant length

While all of those are good points, none of them have anything to do with being easy to read for a human. This is the very point of the title attribute of the abbr element. For the sake of discussion Tantek wrote about the choice of ISO 8601 when the use of title was included.

Improving the format#

The idea of making it easier for robots to parse pages is a good idea, but I'm not sure embedding content for robots into the human content is the best solution. What about putting this information into your web feed instead? Feeds are made to be readable by robots and since they are xml they can easily be expanded with new types of data.

If I were to consider microformats I would like the two main issues above to be fixed first. Add some kind of namespaces to the formats and make them required. One idea would be to use a meta element for each format you want to use inside the document. The name is the format you use, the content is what version you are using, and the scheme is a link to the microformat profile that corresponds to that format. Note that the use of this element should be required, not optional.

It would look something like this (you can of course use several formats by repeating the meta element):

<meta name="hCard" content="1.0" scheme="http://www.w3.org/2006/03/hcard">

The second improvement would be to use something else than the title attribute for the dates. Titles should be used for human readable content, not machine readable so that needs to change. Switching to another format for dates seems like a bad idea since ISO 8601 is so widely spread. So, what to do? I'm not sure. My best bet would be to use the class attribute like most of the microformats are built up on. The dates do not have a space in them so they can be parsed just like other class names.

Conclusion#

Even though microformats are basically trying to make it easier to parse the web (an idea I like) I'm not sure this is the right way of doing it. Human and robot content are most often different things and mixing those in the same document could mean you end up with a mess. I have not touched upon all the extra divs and spans microformats add to the code but that's also a sign that we're moving the wrong way.

If the authors of microformats want their formats to spread they need to fix the two issues above. The two suggestions of improvement I made above would make me consider using them. Right now I don't feel it’s worth it.

Beyond the web with CSS: PrinceXML and S5

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

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

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

Printing like it once was: Word and LaTeX#

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

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

Example of some LaTeX code:

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

Printing with web standards: PrinceXML#

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

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

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

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

Slide shows like they once were: PowerPoint#

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

Slide shows with web standards: S5#

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

Summary#

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

Isn't this standards stuff quite fantastic?

Concept: Four layers of web development

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

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

Data layer#

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

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

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

Structural layer#

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

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

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

Design layer#

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

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

Behavioral layer#

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

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

Putting it all together: four tier web development#

Putting all these four parts together we get the following:

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

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

Inline CSS should not be allowed in strict doctypes

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

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

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

Just to show an example, transitional allows the following:

<body bgcolor="blue">
<center>

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

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

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

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

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

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

Improving the web; Blogging, Google and Web standards

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

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

We need more information#

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

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

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

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

We need relevant information#

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

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

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

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

Making information accessible#

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

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

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

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

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

In summary#

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

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

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

Emulating tables: Automatic width

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

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

The problem#

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

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

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

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

The solution#

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

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

This final CSS looks like this:

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

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

And the following HTML:

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

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

Datatypes of HTML; why HTML is great for structure

2006-05-01T15:42:26+02:00

HTML is often bashed by people for being a bad language. People, often used to XML, talk about the lack of good elements for marking up things like authors and dates. While I agree that HTML would need a few more tags that help with marking the meaning of things I do think HTML is good at structure. This article is a attempt to show HTML's power by mapping how different datatypes in the common programming languages map to elements in HTML.

Arrays, Lists, Vectors#

All programming languages have some way of storing a list of elements. While they are called different names in different languages and support different ways of adding elements they are very similar. HTML supports two kinds of single element lists, the ordered and the unordered list. When selecting which one of them you should use you just have to ask yourself: "Does this list make sense in another order?”. If it does it's an unordered list, if not it's an ordered one.

Unordered list:
<ul>
    <li>Blue item</li>
    <li>Gray item</li>
    <li>Pink item</li>
    ...
</ul>
Ordered list:
<ol>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
    ...
</ol>

2D-Arrays, Datasets#

Most languages also support some way of arranging your data in a two dimensional grid. The ordinary way is just letting people nest lists inside each other and get several dimensions like that. HTML has recognized the need for a simple way of marking up two-dimensional data in an easy way and therefore added the table element. Since two dimensions make the data a bit more complex to understand the HTML authors decided to add a few elements that describe what columns and rows mean. Below is a table with the essential elements for metadata added.

<table summary="Prices for apples in Sweden">
    <caption>Table 1: Prices for various apples in Swedish stores</caption>
    <thead>
        <tr>
            <th>Kind of apple</th>
            <th>Color</th>
            <th>Price</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Granny Smith</td>
            <td>Light Green</td>
            <td>3 SEK</td>
        </tr>
        <tr>
            <td>Golden Delicious</td>
            <td>Yellow</td>
            <td>6 SEK</td>
        </tr>
        <tr>
            <td>McIntosh</td>
            <td>Golden</td>
            <td>30 SEK</td>
        </tr>
    </tbody>
</table>

Trees#

Sometimes you want to have a tree of data; it might be to display a nice view of your historical ancestors or simply the probabilities of something happening. Many programming languages have decided not to include a certain type for this and instead let programmers build their own type with the help of nodes and pointers. HTML instead relies on nested lists for this purpose. The example below shows a nested navigation menu in two levels:

<ul>
    <li>Home</li>
    <li>About this site</li>
    <li>Sections
        <ul>
            <li>Blue Fishes
                <ul>
                    <li>Light blue Fishes</li>
                    <li>Dark blue Fishes</li>
                </ul>
            </li>
            <li>Black Fishes</li>
            <li>Red Fishes</li>
        </ul>
    </li>
    <li>Contact us</li>
</ul>

Worth a note is that lists only can contain list items, not other lists. This means that all sublist needs to be wrapped inside a list item like I have done above (the fishes are inside of Sections list item).

Hashtables, Dictionaries#

Moving on we find the more advanced types of data. Quite often in programming we want to map a string to another string. This can be the case if we are building a dictionary or even if we want to store the price of different products. To me both of the above examples are cases where I would use a HTML definition list. Definition lists also has a way to mark that certain items might map to several other. By setting two dts after each other you make them both apply to the following dd.

I've made an example below of how to markup a list of properties.

<dl>
    <dt>Weight:</dt>
    <dd>45 kg</dd>

    <dt>Length:</dt>
    <dd>12 m</dd>

    <dt>Colors:</dt>
    <dd>Blue</dd>

    <dd>Red</dd>
    <dd>White</dd>

    <dt>Cost:</dt>
    <dd>500 SEK</dd>
</dl>

Definition lists where originally made to just store definitions (as the name suggests) but it's my opinion that they can be used for more than that. HTML lacks a lot of semantics and this is a way to extend it a bit. Feel free to leave a comment if you disagree.

It's my opinion that HTML is good at marking up structure. Sure there are some types of data that can't be represented with HTML but the most common types are easy to do. Do you have more types to add to the list? Leave a comment!

Web Development Pack

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

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

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

Browsers you need#

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

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

Firefox extensions#

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

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

Other programs you might need#

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

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

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

What beginners ask for (and what I tell them)

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

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

Separation of content and design#

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

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

Clearing floats#

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

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

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

img#id_of_image { float: right; }

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

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

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

Validation is a timesaver#

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

Accessibility is not about blind users#

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

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

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

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

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

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

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

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

Equal height columns#

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

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

Challenge: What’s the worst you can do?

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

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

The challenge#

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

Inspiration for a truly hideous design#

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

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

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

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

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

How to accept the challenge#

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

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

Frames or Iframes with CSS

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

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

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

Why are traditional frames such a bad thing?#

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

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

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

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

Getting a scrollbar on any element using CSS#

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

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

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

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

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

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

Mimicking traditional frames#

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

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

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

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

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

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

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

Google statistics over HTML usage

2006-01-25T20:56:18+01:00

Google Code has done extensive research over the use of HTML today. Since this is Google doing the job they had access to an enormous amount of data, over a billion documents where analysed. What does the report conclude? Pretty much what we already know: people don't use HTML for structure like its intended.

Here are some examples of strange usage in the report:

<head> is used more often than <html>. No comment.
<table> is the ninth most used element. I have serious doubts that this is due to the amount of tabular data on the web.
The third most used classname is "title" and the fourth "small". The first could probably be replaced by a header tag, the other one should certainly be set by CSS since it's style.
Half of all <body> elements contains the "bgcolor" attribute. If this isn't style, what is?

The report tells a lot about the shape of the web. If I only could get more people to read my beginners guide…

Building a poker template

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

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

About the niche#

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

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

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

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

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

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

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

Plan what features you want#

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

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

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

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

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

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

Play poker button#

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

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

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

Advertisement#

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

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

Beginners guide#

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

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

News#

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

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

Forum#

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

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

Search#

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

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

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

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

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

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

About us#

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

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

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

What a structured document looks like#

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

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

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

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

Apply some fancy CSS#

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

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

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

Positioning the header#

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

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

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

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

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

Positioning the advertisements#

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

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

Positioning the content#

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

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

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

Putting it all together#

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

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

Final version of the site

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

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

Summary#

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

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

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

Building niche sites with standards

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

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

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

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

Line Breaking With Javascript

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

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

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

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

How it works#

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

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

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

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

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

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

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

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

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

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

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

Make a tooltip out of some columns in a table

2006-01-06T01:16:59+01:00

A worried user joins the #CSS channel on EFNet. He has a big problem with the site he's currently working on and wonders if there might be a problem with his markup. Let's see what he wants.

The site sells some kind of houses and each house has a few "options" (let's pretend a bigger door is one option) that the user should be able to select among. Each of these options has a name and costs a certain amount of money. When you move your mouse over one of the options, he wants more info to pop up in a small box. In the box there should be an image, a store name and strange number. What HTML should he use to mark that up?

We talked for a while and thought about definition lists containing a div with the extra info in, perhaps a two-column table with a div in the second column? After looking again it became pretty clear, if we just look at his data and not think about the design, all that was left was one big table. Everything that he wants in the tooltip are things that could as well be shown in a big table. So why not use exactly that markup and then use javascript to make some cells only pop up when the row was hovered?

This is the markup I propose:

<table summary="Options for your house">
  <thead>
    <tr>
      <th>Option</th>
      <th>Price</th>
      <th class="tooltip">Image</th>
      <th class="tooltip">Store</th>
      <th class="tooltip">SKU#</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Bush</td>
      <td>$3</td>
      <td class="tooltip a1"><img src="/files/post-media/bush.jpg" alt="An alabama bush"></td>
      <td class="tooltip a2">Alabama</td>
      <td class="tooltip a3">#23535151</td>
    </tr>
    <tr>
      <td>Bush</td>
      <td>$3</td>
      <td class="tooltip a1"><img src="/files/post-media/bush.jpg" alt="An alabama bush"></td>
      <td class="tooltip a2">Alabama</td>
      <td class="tooltip a3">#23535151</td>
    </tr>
  </tbody>
</table>

What you see there is a plain five column table with some classes spread out to make it easier to fetch what we want with the javascript later on. The whole table is given the id "info", this makes us able to separate it from other tables on the same page. Each cell that are going to be in the tooltip get the class "tooltip" and an aditional a1-a3 class that simply is used to position the specific cell later on.

Next we need to do two of things:

Loop over the table and hide everything with the class "tooltip"
Loop over all table rows and add a mouseover function to each of them that makes them show all hidden cells in that particular row

To fetch all elements that has a certain className we will use Jonathan Snook's fabulous getElementsByClassName. It takes two arguments, the element whose children it should loop through and the className it should look for. The function looks like this:

function getElementsByClassName(node, classname) {
   var a = [];
   var re = new RegExp('\\b' + classname + '\\b');
   var els = node.getElementsByTagName("*");
   for(var i=0,j=els.length; ij; i++)
      if(re.test(els[i].className))a.push(els[i]);
   return a;
}

Next we need to write the code that fulfils the list we wrote previously:

// Hide all classes with the className "tooltip"
var tooltips = getElementsByClassName(
   document.getElementsByTagName("body")[0], "tooltip");
for (var i = 0; i  tooltips.length; i++) {
   tooltips[i].className += " hide";
}

var tbodies = document.getElementsByTagName("tbody");
for (var i = 0; i < tbodies.length; i++) {
   var trows = tbodies[i].getElementsByTagName("tr");
   // Add a function to each tr that makes it show it's cells on mouseover
   for (var j = 0; j < trows.length; j++) {
      trows[j].onmouseover=function() {
         var childtooltips = getElementsByClassName(this, "tooltip");
         for (var k = 0; k < childtooltips.length; k++) {
            childtooltips[k].className+=" hooover";
         }
      }
      // And hides all child cells on mouseout
      trows[j].onmouseout=function() {
         var childtooltips = getElementsByClassName(this, "tooltip");
         for (var k = 0; k < childtooltips.length; k++) {
            childtooltips[k].className =
               childtooltips[k].className.replace(new RegExp(" hooover\\b"), "");
         }
      }
   }
}

A note here is that we don't loop over the first table row. That one contains the table headers and shouldn't react to us hovering it.

Last but not least we need a few lines of CSS to make the page behave like we want it to. Without either Javascript or CSS enabled a plain table should be shown with all cells visible. If you have both enabled you don't want the cells that contain the tooltip to take up space in the table. Here's the code:

.hide {
   left: -10000px;
   position: absolute;
}
.hooover { left: 80px; }
tr { position: relative; }
.a1 {
   border: 1px solid Black;
   width: 300px;
}
.a2 { padding: 20px 0 0 120px; }
.a3 { padding: 20px 0 0 200px; }

The "hide" class is added to any element with the class "tooltip". Why not make the tooltip class hide the cells right away you ask? The answer is that then a non js user would not see those cells at all. This way we get the best of both worlds. To remove the hidden cells from taking up space we remove them from the flow with position: absolute; and to hide them we use left: -10000px.

The "hooover" class get enabled when we mouseover one of the table rows. It just sets the left value to a far more visible 100px. Lastly we set some styles on the a1-a3 classes that makes the tooltip look a little better. We use a1 as a background and place the other two classes on top of it to make it look like they are in the same box.

And that's it, a table turned into a tooltip, another user is a little bit happier and all would be fine... Unless of course the user had left the channel before I could show him my solution. Damn.

Beginner’s guide to CSS

2006-01-05T18:11:00+01:00

In the chat channel I'm in, I get to talk to people on a daily basis that have never used CSS before, or are at the very beginning of learning it.. This article teaches all the basics you need to make your first CSS powered website. It is aimed at people that know a little HTML, and maybe have made a few websites themselves. Let's get started.

What is CSS?#

CSS is a language that adds style (colors, images, borders, margins…) to your site. It's really that simple. CSS is not used to put any content on your site, it's just there to take the content you have and make it pretty. First thing you do is link a CSS-file to your HTML document. Do this by adding this line:

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

The line should be placed in between your <head> tags. If you have several pages you could add the exact same line to all of them and they will all use the same stylesheet, but more about that later. Let's look inside the file "style.css" we just linked to.

h1 {
   font-size: 40px;
   height: 200px;
}
.warning {
   color: red;
   font-weight: bold;
}
#footer {
   background-color: gray;
}

You have three selectors up there, h1, .warning and #footer. A selector simply points to somewhere in your HTML document. It can be built in many ways and can be a combination of the following building blocks:

Element
Class
Id

I'm going to go through all three of them and explain what they do.

An element points at a HTML-tag somewhere on your page. In the example above we want to style the <h1>-tag. Note that using an element like that affects all tags with that name, so using p gives all p-tags a left-margin.

Using a class is just as simple. When writing .your_class you style all tags with a class with the name "your_class". In the example above we have .warning which will style e.g. <div class="warning"> and <em class="warning">, that is, any element with the class warning. Classes are used when you want to style just a few of your tags in a way, perhaps you want some of your links red? Add a class to all those links.

You need one more building block: the id. This time you style an element with the attribute "id" set to the id you have chosen. Ids work exactly like classes except for one thing; you can only have one id with a certain name in each of your HTML documents. In the example above we style <div id="footer">. If you look at the example it does make sense: a HTML document may contain several warnings but only one footer. Ids should be used when you want to style just one specific tag.

Using those three building blocks will take you far but when you get to more advanced layouts you might want to combine the building blocks into more advanced selectors. Just to give you two examples of what you can do: em.warning to style only those <em>-tags with the class .warning set. You can also use #footer a to style only the links that are nested inside the tag with id "footer". Pretty nice, isn't it?

I could go on forever about the advanced uses of selectors but this is a beginner tutorial so I won't. If you want all the finer details, go have a look at the excellent Maxdesigns Selectutorial.

Let's go on explaining the code above. Each of the selectors has a set of declarations tied to them. Each declaration has a property, describing what we want to change and a value, what we should change it to. Too many terms there? Are you still with me? Let me explain with an example: a. You have the selector a there, so all links in your document will be styled. We have two declarations: color: Blue and font-size: 3em;. Lastly each declaration consists of two parts: the property color and the value Blue. Phew! Well done for making it this far. The terms above are good to know since it gives you a way to talk about your CSS. If you join a CSS-channel asking for help with your code and they tell you "You have an error in your a-selector in the second declaration" you know exactly where! Right? :)

Now you will probably ask what properties there are. You have seen font-size and color but what else is there? The answer is that there are a LOT of things you can style and play with. Additionally (close to) all tags are equal in CSS, so you can set e.g. borders and colors of any element just like you could with a table if you used only HTML. Starting to see the possibilities?

I won't go through all the properties here, it would just bore you to death. Instead I'll point you to another great resource: w3schools section about CSS. Just select one of the menu options to the left to start exploring what CSS can do.

But don't you leave me all alone here, there is more to learn! Next we will talk about good and bad coding and there will be a lot of colorful examples for you. Sounds good?

CSS is all about separation#

One of the least followed parts of CSS is the very idea behind it, the idea of separation of content and design. The idea here is that all sites contain two major parts, the content: all your articles, text and photos and the design: rounded corners, colors and effects. Usually those two are made in different parts of a webpage's lifetime. The design is determined at the beginning and then you start filling it with content and keep the design fixed. So if you just want to add content to your site you don't want to be forced to mess around with the design, do you? The same thing is true the other way around, if you decide on a redesign, why should you have to mess around with the content, making sure it fits in the new layout?

In CSS you just add the nifty <link>-tag I've told you about to the head of your HTML document and you have created a link to your design. In the HTML document you put content only, and that link of yours makes sure it looks right. You can also use the exact same link on many of your pages, giving them all of them the same design. You want to add content? Just write a plain HTML document and think about marking things up like "header" instead of "big blue header" and use CSS to make all headers look the way you want!

This is a different way of thinking about webpages, and it's something that took a while for me to understand. To help you I have written some examples of good and bad coding. What's wrong with this?

<font size="3">Welcome to my page</font>

Comment: The font-tag is design and design shouldn't be in the HTML document. All design should be in the CSS-file! Instead do this:

In the HTML:

<h1>Welcome to my page</h1>

In the CSS:

h1 { font-size: 2em; }

One more example:

<b>An error occurred</b>

Comment: This looks right doesn't it? But if you look up what <b> stands for you quickly find bold. But bold is certainly design, so it still doesn't belong in the HTML document. A better choice is <em> that stands for emphasis or simply "this piece of text is important". So instead of saying "this text looks like this" you are saying "this text is important" and you let the looks be decided by the CSS. Seems like a minor change, but it illustrates how to select your tags. Use this instead:

In the HTML:

<em>An error occured</em>

In the CSS:

em {
   font-weight: bold;
   color: Red;
}

One last example:

<table>
  <tr>
    <td><a href="">first link</a></td>
  </tr>
  <tr>
    <td><a href="">second link</a></td>
  </tr>
  ...
</table>

Comment: Lots of people format their navigation menu like the above example. But is a navigation menu really a table? If you look up the definition of a table you see that it's made for tabular data, the same kind of data you would put in an Excel sheet. The example has only one column of data, and no headers… Some people state that they use tables because that means that they can get borders and a background color on their navigation, but that's exactly what your CSS file is for (not the HTML document). So what should we do? Look deep in the list of HTML elements at w3schools and you'll find something called an unordered list, <ul>. Have a look at this:

In the HTML:

<ul>
  <li><a href="">first link</a></li>
  <li><a href="">second link</a></li>
  ...
</ul>

In the CSS:

li {
   border: 1px solid;
}

This is probably a different way of thinking about HTML than you're used to but trust me, when you've worked with it for a while you'll see the power of it. Not only does this way of coding give you a more logical structure, there is also proof that this improves your ranking in search engines and makes it easier for accessibility devices to read your site. This way of designing is great.

Next we will build a simple HTML template to use as a start when building a new page. Like to see it?

Building a standards based HTML template#

We have talked a lot about the theory behind CSS and HTML working together to form a site with good structure that is separated from the design. But the first parts of building pages are always the same, you type

<!doctype html>
<html>
  <body>
    <div id="header">
       <!-- Header here! -->
    </div>
    <div id="navigation">
      <!-- Navigaiton here! -->
    </div>
    <div id="content">
      <!-- Content here -->
    </div>
  </body>
</html>

Ok, there might be some new stuff there so let's go through the lines one by one. First we state this document's doctype: what language we use. You might have heard of XHTML, another similar web language, but for a first page we don't need the features that gives us access to, keep it simple, just go with HTML. Also, the <!doctype html> above sets the document to use Strict HTML. To understand that you need to know that there are two kinds of rendering in a browser. One that follows the standards set up by the W3C, "standards mode", and one for older pages, called "quirks mode". Standards mode is what we want to use. It makes the pages render (almost) the same in modern browsers and it frees us from being dependent on a specific browser, we'll just follow the standard. Quirks mode is something of a bug mode. It's there to keep old pages looking the same as they did before browsers started trying to follow the standards and is therefore intentionally filled with strange bugs. A browser determines which rendering mode to use based on what doctype we use, so make sure you use the right one!

Ok. That's a lot of explaining for a single line of code, I'll be swifter now, next line. You have probably written <html> before in the beginning of your documents. My line is almost like that except that I have added lang="en" there. That line tells the browser which language we will use. Why does it matter what language we use? you ask… Well, there is assistive technology that read webpages to people out loud called screen readers. Those have to know what language it is to be able to pronounce the words. It's so easy for you to add those few characters so why not do it? If you don't plan on making an English page you can find your own language code by visiting WAIs Language Codes and check out the two-letter names there (Note: language codes are in lowercase).

Next we have the head of the document. The head contains a some of meta-information about the page, like character encoding, title and what stylesheet (CSS file) to use. The charset there is the trickiest one so let's take that first. There are a lot of different letters in a language. When computers where first constructed the engineers only thought about the American/English language, they didn't even think about the swedish letters å, ä, ö or the deutsch umlaut ü or what about the &-sign? There are a lot of characters and at first there was no general consensus on how to handle them. Then someone came up with the smart idea of grouping them into sets, groups of characters that are used in certain parts of the world. So, what the meta-tag does is simply to state: "This person wants to input western characters (latin-1 characters)", and this tells the browser what character set to use. A more genaral approach is to use the utf-8 character set but that quickly gets tricky. Finally we have a text/html there that simply tells the server to send the document as a HTML, not like an image or something like that. The <title> and <link> you should be familiar with, if not, google it :)

That was a lot of info on just a few lines of code, I hope I didn't give the impression that this stuff is hard, because it's not. To use the stuff above you just copy and paste it and start filling it with content.

The body of the document consists of a bunch of divisions, let's add some content to them:

...
<div id="header">
  <h1>The name of this page</h1>
</div>
<div id="navigation">
  <h2>Navigation</h2>
  <ul>
  <li><a href="first.html">First</a></li>
  <li><a href="second.html">Second</a></li>
  <li><a href="third.html">Third</a></li>
  </ul>
</div>
<div id="content">
  <h2>Content</h2>
  Some sample content, add your own here
</div>
<div id="footer">
  This page is written by [Your name] and builds on a <a href="http://friendlybit.com">Friendlybit template</a>.
</div>
...

What have we done here? First you should note that a quick overview of the document tells you quite much about the content. You can easily see that some stuff are headers (h1, h2) and some are just a list of links (ul, li, a). Let's go through the code quickly:

First we have a header. A header is something that's most often a big image and some text. Some pages don't have the header in the HTML at all, they just link to an image and have the text in that image. Problem with that is that neither search engines nor screen readers can get the title text. With the title text being the most important piece of description a visitor has to what page they have come to, you do have a problem. So trust me, keep that text there.

Next up we have the navigation. Navigation should almost always be marked up as an unordered list of links. I've seen the strangest variants of this with tables, nested tables, ``-tags after each line and so on but the only content there is a list of links, why make it something it isn't? Using a list doesn't mean it will have to look a certain way, remember that all design is handled in the CSS later on, this is just HTML we are dealing with here. Note: you can easily remove the bullet marks with list-style: none;, that's not a reason to use some other HTML.

The most important part of your HTML document is the content. This is the reason people will visit your page and this is where you should put most of your effort. Mark your headers with appropriate header-tags and make sure they look different from the ordinary text, this makes it easier quickly get a grip of what you're are trying to say. Use paragraph tags around your paragraphs to make is easier to style your text. The CSS text-indent: 2em; adds some space before only the first word in each paragraph, just to name one simple thing you can do with CSS when you've used good markup.

Lastly, it could be a good idea to add a footer to your page. Make sure you have some kind of contact information here or somewhere else on your site, who knows what people will want to ask you? If you want to help me you could add a link to this site somewhere on your site too. If you do, thanks alot!

On the next (and last) page of this short beginners guide we will wrap everything up and add some sample CSS to the mix. All is free for you to copy and use on your page. Ready?

Full HTML template and sample CSS#

Let's start by putting the two pieces of HTML I showed you together and combine it with some sample CSS: Sample HTML + CSS. You can find all code that makes that page below. Feel free to copy the code below and experiment on your own.

<!doctype html>
<html lang="en">
  <body>
    <div id="header">
      <h1>The name of this page</h1>
    </div>
    <div id="navigation">
      <h2>Navigation</h2>
      <ul>
        <li><a href="first.html">First</a></li>
        <li><a href="second.html">Second</a></li>
        <li><a href="third.html">Third</a></li>
      </ul>
    </div>
    <div id="content">
      <h2>Content</h2>
      Some sample content, add your own here
    </div>
    <div id="footer">
      This page is written by [Your name] and builds on a <a href="http://friendlybit.com">Friendlybit template</a>.
    </div>
  </body>
</html>

You should be able to tell what each part of the HTML does by now. Let's instead have a look at some sample CSS for the structure we have above. If you want to experiment with this code you can copy it to a file named style.css (or any other filename you reference in the <link>-tag in the HTML) and place it in the same directory as the HTML document.

body {
	background-color: Green;
}
div {
	border: 3px solid Black;
	padding: 7px;
	width: 600px;
}
h1, h2, h3, h4, h5, h6 {
	margin: 0;
}
#navigation {
	float: left;
	width: 150px;
}
#content {
	float: left;
	width: 430px;
}
#footer {
	clear: both;
}

Let's go through the six rules above. First we set the background-color of body, and body is the background of everything, so this will do the same as bgcolor did in HTML.

Next we set some styles on all divisions on the page. We have four of them and with this single rule we affect them all. First we set a black border to be 3 pixels wide (note that there is no space between number and unit in CSS). We then set a padding (the space between the border and content) to be 7 pixels and lastly we set the width of all divs to 600 pixels (note that margins, borders and padding are not included in the width).

The third rule selects all headers on the page and removes the margins (the space between the border and other nearby elements) from them. The commas are used between the elements to apply the same CSS to all of them.

Next we have some specific rules for three of the divisions. We position the navigation to the left of the content. This is done by using floats, a way to put things side by side. If you have used the align-attribute on images in HTML you will know how floats work, they move the element as far to the left as possible and then let the next element follow right next to it. If you want to put something below a float you need to clear it. Clearing moves the element down until it's below any floats, exactly where we want the footer. So both navigation and content are floated and given a width to match the 600 pixels wide header, and the footer is cleared.

Update: I have added some simple layouts for you to look at, and a list of tools I use when developing. Hope they help all of you out there that learn by examples.

Now it's your turn, you will learn CSS by using it and trying out how things work. So go ahead and play with the sample above. Thanks for reading, and good luck!

Any ideas of how this guide could be improved? Just leave a comment to the right.

Friendly Bit - Web development blog

HTML5 is not an option

Rendering a web page – step by step

Tapestry 5, and how not to treat HTML

Interface developers and security

HTML includes

Templated User Controls in ASP.NET

Don’t waste time writing HTML and CSS

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

2. Try to set properties once#

3. Learn your text editor#

4. Make sure your environment supports you#

Sharepoint 2007 – insanely bad HTML

Web standards with ASP.NET

Controls that keep the HTML customizable#

Don't repeat yourself - not even in the interface code#

Disable viewstate#

Summary#

Use formats instead of microformats

Why the class name "wrapper" is so common

IE8 is back on the standards track

Default HTML in Sharepoint 2007

In conclusion#

IE8 and Doctype switching

The real strangeness#

What it all comes down to#

Sharepoint 2007 from an interface developer’s view

"Customization"#

Specifics#

Development#

Accessibility#

Page size#

Javascript and Browser dependencies#

Changing the CSS#

Share point and Master pages#

Default .NET controls#

In summary#

I’m an interface developer

What italic means

Don’t attach HTML-files in Outlook

Accessibility as a platform to build upon

HTML: Our history#

But we want more than that!#

Separation in the blink of an eye

Forgotten HTML elements?

Web development blogs you should read

Web Standards Hero, episode 2

Web Standards Hero, episode 1

How web standards feels

Encyclopedia of HTML elements

A - Links, the very foundation of the web#

ABBR - Explain what your abbreviations mean#

ACRONYM - Special case of the above where the word is formed from beginning parts of the words in a phrase#

ADDRESS - Contact information of some kind#

AREA - Define links in any shape#

B - Make text look bold#

BASE - Change your links to be relative to this address#

BDO - For foreign languages (ie. Hebrew), mark text direction#

BIG - set larger text relative to surrounding text#

BLOCKQUOTE - Longer quotes#

BODY - All your real content goes inside this one#

BR - Line break#

BUTTON - Alternative to inputs with types submit and reset#

CAPTION - Description of a table#

CITE - Source where quoted text originated#

CODE - Computer code example#

COL - Used to specify that some table cells belong together in columns#

COLGROUP - Shorter way of specifying table columns#

DD - Description of a term in a definition list#

DEL - Mark deleted text in documents#

DFN - Term that's being explained by you#

DIV - Divider into logical parts#

DL - List of definitions#

DT - What you define in a definition list#

EM - Important phrase#

FIELDSET - Groups form elements that belong together#

FORM - Wrapper for all kinds of form fields#

H1, H2, H3, H4, H5, H6 - Headings for your sections#

HEAD - Container for meta data in the document#

HR - Horizontal line#

DD - Description of a term in a definition list #

LI - Items in ordered or unordered lists #

Use `<label>` for form elements#