Technical details


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.

The mechanics

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!

Return to top

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.

HTML5 Powered 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.

CSS3 Styled 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 still in development, but many of its newer features are already supported by current versions of major web browsers. So I’m using CSS3 to control the presentation of this site. Validation of CSS3 is a little trickier: at present, the validator still suffers from some bugs and anomalies, and sometimes reports things as errors that aren’t really errors. So I won’t provide you with a tempting link to validate my CSS!

Return to top

Progressive enhancement

One of the key philosophies I follow in building web sites, including this one, is that of progressive enhancement. Nowadays we use a huge variety of desktop computers, tablets, smartphones and other hardware to access the internet, and these devices are equipped with many different web browsers running on different operating systems. These combinations of hardware and software vary in their levels of support for HTML, CSS and JavaScript and so they may render the same web page differently.

The progressive enhancement concept embraces that fact by promoting a layered approach to web design and coding:

  1. 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.
  2. 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.
  3. Finally, I add functional or behavioural enhancements that will improve the usability or enjoyment of the pages for those visitors whose browsers support JavaScript.

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?

Enhanced presentation

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 surprising number of people and organisations. 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.

The Home page, as seen in Internet Explorer version 6
Figure 1. The simple presentation seen in Internet Explorer, version 6.

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.

The Home page, as seen in Chrome
Figure 2. The fully enhanced presentation seen in Google Chrome.

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.

The Home page, as seen in Internet Explorer version 8
Figure 3. The almost fully enhanced presentation seen in Internet Explorer, version 8.

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.

Enhanced behaviour

If your web browser has JavaScript enabled (most do, by default) then you may benefit from some tweaks I have made. JavaScript is a programming language developed for the web and which runs in web browsers. In other words, when your browser loads a page, if it contains JavaScript code, the browser will interpret and run it.

Here are a few of the enhancements:

Return to top

Responsive web design

Ethan Marcotte, unstoppable robot ninja that he is, triggered a seismic shift in the web development world when he coined the term responsive web design back in 2010. But let’s step back a bit.

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

So, yes… this site is responsive. If you’re viewing it on a typical desktop or laptop computer, or even one of the larger tablet devices, and it has a full-on, standards-compliant, JavaScript-enabled web browser, then what you see will look like Figure 2 above. Figure 4 below shows how the Home page will look on a small tablet, a smartphone and even a teeny-weeny feature phone (I’m nothing if not inclusive).

The Home page, as seen on a small tablet, a smartphone and a feature phone
Figure 4. The Home page, as it is displayed in “portrait” mode on a small tablet (background), a smartphone (middle) and a feature phone (foreground).

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.

Return to top