Posted by Steve in the late evening on Friday the 2nd of November, 2007

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint Exupéry, ‘Terre des Hommes’ (1939)

This sentiment is just as true for markup, style, and behaviour on the web. The trick, though, is to find the optimal balance between the four.


When building a page, one should assume nothing: mark it up in the most minimal, sparse way possible whilst still maintaining a logical structure.

No classes. No ids. No divs or spans. Just pure, semantically rich HTML elements.

Next, divide the page into major logical divisions using divs with apt ids. Use classes to identify patterns used throughout the page (cf. Microformats). At this stage, one should be adding semantic context as minimally as possible.

Further, this context should be added at the highest level in the DOM that is appropriate, and no higher. For example, an ordered list of blog posts should not feature a class of post on each list item; rather, the list itself should have the class posts.

Remove redundancy in all aspects of the markup. Consider different choices of elements, even if they seem unfit for purpose.

If, at the end of this process, it seems like the document should be easy to style accordingly then there are probably too many styling hooks, in the form of non-semantic classes, ids and elements, in place already. Go back and think about everything once more. Make every element and attribute justify its existence.

By this point all functionality of the page, be it part of an application or straight prose, should be exposed and fully usable.

All of it.

If there’s a single piece of functionality that you feel you can’t provide in raw HTML, you’re doing it wrong.

This doesn’t mean the interaction has to be as rich as it might be, but it should be usable.


As with the markup, styling should be approached by using the most simple approaches possible to achieve the desired look.

The styling shouldn’t obfuscate any functionality: everything should still work as intended.

Avoid adding extra markup at all costs. If it seems that extra markup is necessary to aid styling, consider that the approach being used to acheive the style is the wrong one.


Finally, enhance the behaviour as necessary. As with styling, consider that the desire to add to the DOM (either before or during the life of a script) could be a sign that the solution is not the optimal one. Similarly, if styles must be added before any interaction occurs, separate them using some class high in the DOM tree.

If anything must be added, be they elements, ids, classes, or styles, add them at the latest possible instant and promptly remove them when unneeded. When applying behaviour use, as far as possible, already extant semantics for context.

Further, if the behaviour relies on styling to justify its existence, it may need rethinking.

Throughout all three, one should attempt to focus on the smallest area possible at a time. Break the document into its requisite parts, developing these in isolation from one another and the framework to bind them together.

Above all: if you’re not finding it hard, and agonising over it, you’re probably not doing it right.

Filed under

Search, and ye shall fail

Posted by Steve mid-morning on Friday the 11th of May, 2007

There’s an accepted solution for channelled searching: offer a textbox input and a submit button, supported by a series of links to each channel of the search. The links will typically have JavaScript layered onto them (in theory, at least) to rewrite the form’s target, so that the user may refine their search before submitting it. This behaviour can be seen on Yahoo! US, Yahoo! UK and Ireland, MSN, and yes, even Google.

It must be the best solution, mustn’t it, if all these sites use similar techniques?

The objective of my affection

If we step back for a moment, to examine the user’s needs, we can see two objectives for the average searcher: find something and [perhaps] make it of this type.

The ‘something’ for which the user is searching is, in their mind, the foremost concern. Everything else is secondary. When searching, a user’s first instinct will almost always be to enter their search terms (and why should it be otherwise?). Everything about a search interface is geared toward this: the keyword input has the most visual weight on the screen — on a typical search index page — and the most prominent position — either near dead-centre or in the head of the page, depending on the type of page.

The accepted solution, happily, cedes to this under all circumstances.

The second objective, then, is the type of results that will satisfy the search. The introduction of this second objective is where user behaviour will begin to deviate: depending on their priorities and personal inclinations, users’ execution of this may take place before, after, or even during the steps to meet the primary objective. Unlike the emphasis placed on the keyword input, the type of results to return should be — and, typically, are — de-emphasised where possible, but be present — and have their presence known — should the user require them (either to confirm their beliefs or to make a change).


But the accepted solution only pays lip-service to this more complex interaction: for any user without JavaScript, the only acknowledged paths for them to change the channel in which they are searching is to select it before they begin their search or, assuming that the search engine alters the links based on the latest query, directly after (and before they attempt to manipulate their search further).

By using JavaScript to bludgeon links into selecting from a choice of mutually exclusive channels, the user experience of what should be a simple search form is broken for many users when they attempt to interact with it in a way that seems natural to them. To compound this issue further, the use of links means that screen reader users may never be able to use this functionality, as links within the form will never be announced when they are entering their search terms.

The problem is that whomever has implemented these solutions (or their forebears) had the mindset of ‘HTML is static, JavaScript is dynamic’ — or simply didn’t care enough to question the accepted norm — and so overlooked what was staring them right in the face: HTML already has a perfectly good input device for selecting one and only one item from a collection:

The humble radio-button.

Given a little semantic markup and CSS (with a smattering of JavaScript to add extra styling hooks), it’s entirely possible to style a group of radio-buttons in a more visually apt way to indicate that it is filtering the search input, whilst offering a far more interactive experience to all users of the site, not just those with JavaScript.

So I did.

That’s what you can see in action on the new Yahoo! UK and Ireland TV (along with France, Germany, Italy, and Spain).

Implementation notes

As noted above, the main components of the form are a list of radio-buttons, a textbox, and a submit button. Of particular note is the way the radio-buttons are scripted and styled, and the structure of the radio-button labels relative to the form’s <legend>. Further, implementing the search this way requires that the server-side script be able to handle the new field being passed its way appropriately.

Scripted style

For all users, the core functionality of the radio-buttons is available, with these styled as an inline list for users with CSS enabled. The JavaScript, when enabled, will simply add a class to the root of the list, along with an extra <span> to allow styling of the labels in accordance with the design. When the radio-buttons receive focus the ‘selected’ class is moved to the new selection. This activity takes place on focus, mark you, and not click: click events fire on the originating control which, when navigating with the keyboard, will mean the previously selected radio-button.

A <legend> in its own life-time

It was brought to my attention that a form’s <legend> will, by default, be announced before each and every form field by screen readers. To make this as unobtrusive as possible, each radio-button’s <label> is worded such that it makes the most possible sense when preceded by the legend text. In English, for example, the radio-buttons will be announced as ‘Search… the web’, ‘Search… for images’, and so forth (where ‘Search’ is the form’s <legend>).

The radio-buttons’ full text, though, would not make sense in a visual context: they should be presented as tabs titled ‘Web’, ‘Images’, and so on. To achieve this, the visually inappropriate portions of the <label> are wrapped in <span>s and positioned outside the browser’s viewport — along with the form’s legend and the radio-buttons themselves — such that they may still be accessed by screen readers and the like.

Furthermore, because the radio-buttons are still present in the content of the page, keyboard users may navigate the form fully through the keyboard (using arrow keys to move between items radio-buttons in a collection).

Once again, this can all be seen in action on the new Yahoo! UK and Ireland TV (along with France, Germany, Italy, and Spain). [Links added at Mike's suggestion]


I can by no means take full responsibility for the successful implementation of this concept, though: I’d particularly like to thank Norm!, Mike Davies, Alex Lee (our designer), Tim Huegdon, and Ann McMeekin (of the RNIB) for all their help, advice, and patience (particularly when I got things working and made lots of excited noises at them), and this wouldn’t have ever been a reality on Yahoo! TV for Europe if it hadn’t been for the receptive, responsive attitude of the engineers working on Yahoo! Search for Europe.

Filed under


Posted by Steve mid-evening on Wednesday the 4th of April, 2007

Graceful degradation.

Innocuous little phrase, isn’t it?

If one takes a moment to consider it, however, the idea can be taken to it’s logical conclusion: ‘You (or your browser) are incapable of handling the full experience we want to present, so here’s a cut-down version.’

At its core, the mere concept of ‘graceful degradation’ belies a lack of respect for one’s users and, more critically, a fundamental misunderstanding of the medium in which we work.

The fundamental building block of the web is not JavaScript. Nor is it CSS. If your user experience relies on either of these, rather than features native to HTML, then that user experience is fundamentally flawed for use on the web.

The key is to design user interactions with naught but HTML‘s base features in mind, later using CSS and JavaScript to enhance that experience (most likely streamlining it or making it more efficient). Done right, this enhancement can even be done in progressive levels, based on the availability of given features in the browser.

As a community, we coin phrases with nary a thought to deeper connotations these might have. Under scrutiny, the idea of ‘graceful degradation’ simply doesn’t align with user-centric design and development.

Progressive enhancement it is, then.

Filed under

Happy New

Posted by Steve in the wee hours on Tuesday the 2nd of January, 2007

Since the day it was launched, nascentguruism was forsaken. When I started designing it, I had a limited understanding of design and so faced a massive learning curve. Because of this, most of my efforts went into working out how to translate the concepts and feelings I wanted to convey into a working site, along with understanding how to achieve what I wanted in the tools I was using (Photoshop).

In hindsight, it’s entirely logical that the first version of nascentguruism’s design would turn out to be everything I made it and nothing I wanted it to be: I was learning about design by observing and experimenting, and so would quickly lose focus on the overall design, becoming preoccupied with whatever details I wanted to introduce at that moment in time.

After ten months’ toil, the site launched with a whimper and, because of the shoehorning that had taken place to include all the extra details, I quickly became jaded: the format of the site didn’t appeal to me, and so I was unwilling to write. As time passed, my interest waned.

Lather, Rinse, Repeat

Shortly after SxSW in March–around June, if memory serves–I was inspired to play with some ideas for a redesign of nascentguruism.

Rather than pressuring myself to continue working solidly until it was ready to launch–as I had with the initial ten-month design–I decided simply to get all my ideas down on paper into a PSD before taking time to mull over what I’d come up with. After a while, I’d start anew, creating a design from scratch, building upon–or, in some cases, replacing–what I’d done in the last iteration.

This process continued until mid-October, when I finally felt that the design could go no further without transitioning to markup. Throughout, I refused to do any work–design or markup– unless I was compelled to do so.

I think this relaxed approach to the design and implementation has served me twofold: the design and implementation was less forced, and so the final site has a more relaxed, open feel to it, and this design is something I positively want to work with, to the point that I’m practically itching to post new content to it (and have been for the last month). Further, the iterative, throwaway-prototype approach to designing allowed me to incorporate new ideas effectively, without compromising the design as much as I might before.


One of my primary focuses in this new design was to experiment with typography, using some of the ideas gleaned from reading Robert Bringhurst’s ‘The Elements of Typographic Style’ and working with Rich on Web Typography. I’ve tried to blend more widely used ideas (like working with vertical rhythm using baselines) and more playful ones (like ornamented indentation), and will continue to experiment and integrate ideas put forth in Web Typography.

Some of these experiments are very reliant on using modern CSS techniques, such as generated content and pseudo-elements and, as such, may not display as expected on all browsers (Internet Explorer, I’m looking at you). Further, most of the font-size-related typography has been optimised for WebKit-based browsers on Mac OS X and, as such, there may be sizing issues with other platforms or browsers. Or maybe not. Everything should be usable, at the very least.


As it stands, the CSS is very clearly showing signs of the hap-hazard approach I took to developing it; in the very near future, I plan to rework it–possibly using YUI reset and fonts.


I couldn’t have achieved everything I have in this redesign if it weren’t for the help of a two notable individuals:

These two deserve more gratitude than I can express here–or in beer form–thank-you both.

There are, however, others that have supported me throughout the process, who also deserve thanks:


nascentguruism is far from complete–during this redesign, I’ve come up with many, many ideas for future work on the design and implementation. Most importantly, however, I have a renewed excitement for blogging and a few ideas for future posts in mind.

Only time will tell if it lasts, I suppose.

Filed under

Just my type

Posted by Steve mid-afternoon on Friday the 29th of September, 2006

Last December, Rich Rutter announced The Elements of Typographic Style Applied to the Web (Web Typography, for short), a site that, for me, couldn’t have been more timely: I was just finishing reading the last chapters of Robert Bringhurst’s master-work, The Elements of Typographic Style, the site’s inspiration.

Just as the book itself was beautifully set (as one would expect), well written, entertaining, and generally a joy to behold, the same can be said of Web Typography. From the subtle use of Flash for the logotype to the carefully set table of contents, everything about the site reeks of typographic quality, its own distinct style echoing that of the original Elements.

The purpose of Web Typography, of course, was not to supplant Elements as the definitive resource for typography – the Typographers’ Bible, in the words of Herman Zapf – but rather to supplement it: to act as an unofficial companion for those working with type on the web.

It is with much excitement, then, that I’m announcing what will, hopefully, mark the start of a trend: my first contributions to Web Typography, §2.3.1: Set opening paragraphs flush left and §2.3.2: In continuous text, mark all paragraphs after the first with an indent of at least one en, have been published.

I’d like to thank Rich for the opportunity to be involved: he’s been incredibly supportive of my contributions. Like Rich, I’m not a professional typographer (or, in fact, anything more than ‘a guy who has an interest in typography’) but I’d like to hope that, with my contributions, I can help someone out there fall in love with typography and, more specifically, its applications online. If just one person learns to love typography a little more thanks to something I contribute, I’ll be happy.

So, I hope you enjoy what I hope will be the first of many contributions I make to Web Typography!

Filed under