Scaleable HTML and CSS Guide, Part 1 - Introduction
This post is part of a six part series (with possible satellites) on HTML that can increase in size infinitely in unison, allowing any content to be displayed perfectly when the font size is increased. To see an example of scalable HTML, pull the 'Pull Me' bar above or at SEM Labs. You can also increase the font size of a site (in Firefox, Safari and IE7) by pressing CTRL and +.
There are a number of people making vague references to scalable HTML in dark corners of the internet. Most often in reference to a very sloppy form of scalable HTML that you will often find on UK government sites that consists of increase and decrease font size buttons. Clicking these buttons will increase the size of the font on the site, but leave the HTML structure rigidly in place; transforming the website into some kind of MS Frontpage nightmare. Scalable HTML comes in the following flavours:
Sites That Scale Vertically - These sites' HTML structure will expand vertically to accommodate variable font sizes. They will not distort vertically or horizontally when the font size is increased, but eventually text will spill horizontally out of the HTML structure. This type of scalability is becoming increasingly popular with web 2.0 developers. You can see an example of this type of HTML at: FiftyFourEleven.
Sites That Scale Horizontally - I've never actually seen a site that scales in this manner due to the fact that most sites are designed in portrait, not landscape. They would function similar to vertical scalable sites, with the difference of scaling horizontally and the text spilling out vertically.
Scaleable Width - This type of HTML could be branded as fake scalability and are very rare. Scalable width sites allow the width of the content to expand without changing the font size.
Fully Scalable - I use the word 'fully' with some reserve, since in many cases 100% scalability is not possible due to browser constraints. Full scalability is when HTML can scale infinitely both vertically and horizontally to accommodate any font size. Other than sites I have made, the closest site I have seen to being fully scaleable is Yahoo.
Don Those Pixels
There are eight units of measurement that can be used when constructing sites with CSS; the most common being pixels (px). If you are going to make the switch from creating fixed HTML to scaleable HTML, you need to say goodbye to your beloved pixels and say hello to em, ex and %. Depending on which route you want to go down will determine which unit you will plump for. The em unit will probably be your best choice. 1em is simply equal to whatever the font size of the element in question is. So if you have a span element that has a font-size of 12px, 1em is equal to 12 pixels and 2em is equal to 24 pixels. The ex measurement unit is similar to em in that 1ex is equal to half of an element's font size. So if you have an address element with a font-size of 16px, 1ex is equal to 8px. The percentage unit is best used to compliment the use of the em element, since different resolutions will display the same percentage differently. Personally, I use em and % as a content splitter.
Don't worry if you are fond of your pixels, there still are still uses for the px unit in scalable HTML.
Browser Wars
All the major browsers have implemented support for scalability. Which browser has the best support for scalable HTML is debateable. In my opinion, Firefox, Safari and Konqueror are equally head and shoulders above the rest. However, none of them have perfect handling, which is down to the fact the W3C haven't quite finalised the blueprints for scalability. Support for scalability will be greatly enhanced by CSS 3.0.
Let's look at the major browsers and see how they handle scalability:
Internet Explorer
The most commonly used browser, Internet Explorer 6 - the bane of all good web developers - has support for scalability, although it can generally only be achieved though the use of JavaScript. It doesn't support floating pixels, which causes font incrementation to be jerky rather than smooth.
Microsoft, being a bunch of nice guys had to go and ignore web standards again with the release of Internet Explorer 7 by totally disregarding the purpose of the different units of measurement in CSS. When you increase font size in Internet Explorer 7, regardless of the unit of measurements being used, IE will courteously increase all elements in an attempt to create a coherent web page. To be fair to the IE team, most web sites will scale better in IE 7 than in browsers that have good web standards support. But most web sites don't make any attempt to offer coherent scalability. So, when I actually want to use pixels in a layout I might as well not bother for the hordes using IE, because it won't work. The native scalability of IE7 is hindered by the fact that IE just resizes everything, including the body. This will cause your site to shift out of sight when increasing the font size, but can be combated with a CSS fix or ignored using JavaScript (more on this later). Another problem with IE resizing everything as it wishes, regardless of what CSS rules you have set is that background images are also scaled.
Firefox, Safari and Konqueror
Rather than covering these browsers individually, I will cover them together as their scalability support is virtually identical. All of these browsers follow web standards and scale elements according to their unit of measurement. So an element using the em unit will scale accordingly and an element with a fixed measurement will stay exactly how you want it. All browsers also support floating measurements (e.g. 12.1px), which means you can increase the size of your HTML in a smooth transition.
Opera
Like Internet Explorer, Opera takes things into their own hands and ignores the purpose of the different units of measurement. It doesn't support floating measurements and resizes background images.
Getting to know how each browser scales HTML is essential if you are to create cross-browser compatible scaleable HTML. However, Firefox, Safari and Konqueror are almost identical and IE and Opera are likewise, so it isn't too difficult.
How Long Does It Take?
An important question to ask in all aspects of web development is 'How long does it take?' For any seasoned CSS coder - whose sites almost work in IE6 first time - constructing scalable HTML should not take any more time that constructing fixed HTML. Once you have tried your hand a few times, you may even find that you can produce scalable HTML quicker than fixed HTML. Recently I constructed a scalable HTML site that had sixteen individual sub-pages designs that was compatible in IE6, IE7, Firefox, Opera and Safari in just over fifteen hours. To have constructed the same site in fixed HTML would have undoubtedly taken more time and resulted in bulkier CSS. If you are using XSLT to construct your site, scaleable HTML may very well speed up your markup turn around due to the fact that scaleable HTML is highly recyclable and uses the same HTML structure repeatedly.
So Why Should I Bother?
A lot of web developers don't see the point in creating scaleable HTML, but there are a number of advantages:
- So long as you use best practices, your HTML will become much more flexible. If your client insists on making the site 100px wider or the left column needs to be a little bigger you should be able to make amends by editing one CSS property. You can use the same or similar elements over and over again in different spatial constraints without modifying your HTML or CSS.
- People with disabilities have reduced avenues of social interaction. For this reason there are large communities of people with disabilities on the web. Are you going to ignore this potentially lucrative and under-catered for audience by making a site that can only be read by people with 20-20 vision and full facilities of their body? It is actually illegal not to adhere to web accessibility standards in the UK and I believe there is similar legislation in the US. Hopefully valiant PM Gordon Brown will put an end to cutting-edge Dreamweaver developers and we will never see the MM_preloadImages function again.
- The ability to resize websites infinitely has proved very popular with clients, web geeks and general web users. We have won web development contracts solely based on scaleable HTML.
- Scalable HTML can improve your markup turnaround, particularly on large websites or if you are using XSLT. This is due to the fact that scalable HTML uses repetitive HTML structures.
- Constructing scalable HTML will improve your knowledge of both HTML and CSS.
The Disadvantage
From my experience I would say the only disadvantage of scalable HTML is Internet Explorer, particularly IE6. If you start constructing scaleable HTML, you will run into a few new IE bugs and I bet you wouldn't be able to guess they all relate to floated elements, margin and white space. However, any able-handed CSS guru should be able to overcome these problems.
That's it for part one. Part two of this series will deal with creating the backbone of a scaleable website.