Although this is a tiny little web site — just one main page, really, and some ancillary stuff like this page — there’s quite a lot going on behind it, and it serves to demonstrate some of the techniques and best practices in modern web site design and development.
Despite the small size of the site, I didn’t build it with static pages written directly in HTML. Instead, I store the text content of the site in a series of simple files, one for each page. A little template system, which I wrote in the PHP language, processes these files together with some templates to produce HTML web pages dynamically when your browser requests them.
In truth, it would have been quicker just to code up a bunch of static pages, but that would have been too easy and no fun… and my alternative approach shows I can do stuff with PHP. PHP is the most widely used server-side programming language on the web. It integrates well with HTML and with MySQL, the popular database management system powering countless large and not so large web sites. Using MySQL to drive this site, however, really would have been using a sledgehammer to crack a walnut!
Standards, compliance and compatibility
HTML is the core language of the web. It is understood by web browsers and other applications such as screen readers and search engines. To make sure that web pages are interpreted and rendered as intended by their authors on the vast array of browsers, applications and devices used to access them, the HTML must be written correctly, using the proper vocabulary, grammar and syntax. These elements of the language are formally defined in web standards published by the W3C, or World Wide Web Consortium.
The latest version of the HTML specification is HTML5. HTML5 builds on the previous version 4.01, and has many new and useful native features that enjoy wide support amongst recent versions of all major web browsers. A thoughtful web developer can build sites with HTML5 without putting any visitors at a disadvantage — so I chose to code this site using HTML5. And to make sure I got it right, I checked every page using the W3C HTML Validator, a tool that tests the HTML of a web page for compliance with the relevant standard. That way, I can be confident that the code will be compatible with the range of web browsers and other software that visitors might use to access my site. For example, you can validate the HTML for this page.
HTML when applied properly gives structure and semantic clarity to text on web pages, so that browsers, screen readers, refreshable Braille displays or whatever a visitor is using to read a page will deliver that page to the visitor in such a way that the text makes sense. But the presentation of the page is the job of another language: CSS, or Cascading Style Sheets. CSS defines the page layout, fonts used, colours, backgrounds and more.
CSS is also defined formally in W3C standards. The latest version is CSS3, which is really a collection of modules rather than a single, all-embracing specification like its predecessor versions. CSS3 is in ongoing development, but many of the features it introduces are already supported by current versions of major web browsers. So I’m using CSS3 to control the presentation of this site. Just as with HTML, I use the W3C CSS Validator to check my CSS. For example, you can validate the main style sheet for the site.
The progressive enhancement concept embraces that fact by promoting a layered approach to web design and coding:
- I start out with basic documents marked up with HTML, that can be understood and rendered by even the simplest, least capable web browsing software. That way, and most importantly, the full content and essential functions of a web site are available to everyone.
- Next, I add styling and layout using CSS, which provides an enhanced experience of the pages to those visitors whose browsing software supports the CSS properties used.
So older, less capable browsers may render pages with a simpler presentation, while newer browsers with more advanced features render the pages with some or all of the enhancements, according to their level of support. Yes, they may look different. But if everyone has access to all of the content and functions, do web sites need to look exactly the same in every browser?
So much for the theory — what does it mean in practice? Let’s begin with an extreme example of progressive enhancement of styling and presentation of the page in desktop browsers. IE6 (Internet Explorer version 6) is a very old browser, and yet it is still in use by a small number of people. It has poor support for modern CSS features, so I set up my stylesheets so that IE6 is served with only basic styling, as shown in Figure 1 below.
By contrast, as shown in Figure 2, the Chrome browser has excellent support for modern CSS. It renders the pages on this site taking full advantage of all of the CSS features built into my code.
That’s quite a difference. Some browsers produce a rendering that is somewhere in between. In Internet Explorer versions 7 and 8, the same page looks pretty much like the Chrome rendering, save for a few subtle differences. For example, in Chrome and other browsers that support the opacity property, the blue background to the text area is slightly transparent, allowing the underlying photograph to be visible through it. Internet Explorer version 8 and lower don’t support opacity, so users of those browsers see a simple, solid blue background instead — as shown in Figure 3.
There are other, smaller CSS features in place, too. For example, I’ve applied CSS3 Transitions to links, both in the navigation menu and the body text. Transitions allow an element to change from one style to another, smoothly and gradually. You’ll become aware of these if your browser understands transitions; but if not, you won’t miss them. And that’s the essential thrust of progressive enhancement: enriching the experience for those people whose browsing environment supports particular features, without harming the experience for others.
Here are a few of the enhancements:
- Smooth scrolling. If you select a link that leads to another part of the same page, rather than jumping abruptly to the destination, the page will scroll smoothly to it — making it obvious that you are travelling to another point on the page, and in which direction.
- Lazy loading. Where a page contains a number of images, such as this page and the photos page, the images are inserted into the page using a technique called “lazy loading”. Images outside of the visible part of the page are not loaded until you scroll to them. This makes the page load faster, and does not download images that may not be needed. Both of these factors are particularly useful for users of mobile devices, which may have slower connections and restricted data allowances.
- Menu show/hide. On wide screens, a “Menu” tab appears, allowing you to show or hide the main navigation menu.
- Stretchy background photo. On wide screens, you will see a large background photograph that fades in when the page loads, and stretches or shrinks if you resize your browser window. On smaller screen devices, the large photograph is not even downloaded — thus saving data charges for mobile users.
Responsive web design
By the mid-2000s, hardware had advanced to the point where we were mostly browsing the web on desktop or laptop computers with honking big wide screens. And in the developed world at least, we were mostly doing it on broadband connections.
And then along came the iPhone.
Now, the iPhone was by no means the first internet-enabled smartphone. But it was the first with a large touchscreen and a really good, standards-compliant web browser. A browser that rendered web pages the way they were designed to be rendered. The iPhone set the standard, and arguably created the market, for the plethora of devices that followed in its wake. As the use of these devices spread, some web developers woke up to the fact that the “fixed width” pages they had designed to be experienced on wide displays didn’t work so well on those smaller smartphone screens. Sure, mobile users could swipe and double-tap and pinch-and-zoom their way around, but that’s hardly convenient. The situation got worse as the “tablet” market woke up, stimulated mainly by another Apple device, the iPad. Web developers found themselves reminded of something they should never have forgotten: that you can never know what kind of device, operating system or browsing software people will be using to access that swanky web site you just built. And in particular, you can never know how big their screens will be.
“Responsive web design” is so called because web pages built using the right techniques adjust their layout in response to the size of screen they are being viewed on, in order to provide a better user experience.
(Another term, “adaptive web design”, muddies the waters a little. Some people think that what is adaptive web design is actually responsive web design; some think they are the other way around. Some think adaptive is a sub-set of responsive, or vice versa. Some argue pointlessly about the distinction between the two. I’m with Jeffrey Zeldman on this one: if web sites adjust to deliver “elegant visual experiences regardless of the size of the user’s display and the limitations or capabilities of the device”, then they are simply responsive.)
Note that the “small tablet” version lacks the big background image served to larger screens, though it does retain the expansive banner heading. It also has a fixed navigation menu across the top. On smaller screens, it’s more important to get to the content as soon as possible. So I shifted navigation to the bottom of the page, and made the heading smaller — incorporating a monogram, to lend a tiny bit of flair. I kept some of the key styling cues like colours and typography for the “smartphone” version, as support for CSS amongst smartphones released in the last couple of years is broadly very good. Not so for old-style feature phones, so I’ve given that version the same basic but tasteful presentation as for desktop users of IE6.
I haz mad skillz!
Congratulations on reading all the way to the bottom of this page — you must be really fascinated by this stuff! If you’ve formed the opinion that I know what I’m doing, and you are interested in having me build a web site for you, don’t hesitate to contact me.