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

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#