Rare Pleasures

Designer Ryan Singer kicked off an lively debate when he posted on the 37 Signals blog that he was abandoning CSS layouts for tables and quoting iamelgringo’s blog post Tables vs CSS: CSS Trolls begone.

Ryan and Gringo along with many who commented exemplify the old adage that ‘a little knowledges is a dangerous thing’. Many in fact showed a marked ignorance of accessibility issues and instead chosen to adopt a patronising tone towards the disabled and those that are trying to help them.

Accessibility is about trying to provide and improve webs access to a variety of people and devices. Just in terms of disability that can mean more than just ‘taking care of blind people’. There are a range of assistive devices that disabled people rely on to access the internet and by adopting a web standards approach you provide a solid ‘api’ that allows manufacturers improvement the functionality of these devices. This can also true of the other major field of accessibility research – that of mobile devices and their kin. We cannot be 100% sure what the nature of these products will be, but by adopting a standards we can be pre-emptive it our ability to support them.

If you build it, they will come
- Field of Dreams 2

Over on the BBC Radio Labs blog BBC Audio and Music Interactive Information Architect Michael Smethurst has written up a post entitled ‘How We Make Websites‘. The article covers the methodologies employed on building two of the departments flagship projects /programmes and /music.

IMG elements do not belong in heading tags. Unfortunately looking through source code placing images in the code H1 tag is one of the commonest html anti-patterns I encounter.

Often its deployment arises out of the misconception that a blog or company’s logo belongs in the H1.
It doesn’t. No more that the mission statement or strapline does. These features belong in that mainstay of the publishing industry ‘The Masthead’.
Instead the H1 should present to the user agent the overall subject title of the document. In many cases the H1 will duplicate the first token in the code TITLE element, and here you will need to think about good declarative document design.

Where there’s a need to supplant the contents of a code H1 with a logo then its recommended to use one of image replacement techniques such as the Gilder/Levin Method.

Alright. Alright! You will know when I point to you!
- Fozzie Bear, The Muppet Show

While its wonderful that almost everyone these days has seen the light and dropped table-based layouts in favor of CSS-based layouts. The adoption the HTML element attributes id and class as reference points for CSS selectors has not been with consequence.

You see, one of the other main purposes of the id attribute is as a target anchor for hypertext links. Now since the document should be comprised of structured fragments, perhaps even transcluded resources, and an author may well not be the only person wanting to link to sections within that document, they must carefully consider where they can apply additional id’s to in order better expose the document’s structure/semantics to the rest of the web.

They should certainly consider which elements in their document which elements should have ids and what they should be named. If we care about URLs (and I pray that you do) then you should care about ids and id naming since they at least potentially form part of the same schema.

Writing descriptive class or id attributes means tackling word separation. Here a web developer has three options: CamelCase, hyphenation or underscore separators. I tend to favor the underscore.

To begin with the use of underscores feels be quicker and easier to decipher than both the hyphenation and CamelCase models:

• .a_suitably_description_class_name_value
• .a-suitably-description-class-name-value
• .aSuitablyDescriptionClassNameValue

They’re also non ambiguous, unlike hyphenation where the separator could represent a space, a subtraction operator or a lexical hyphen:

• #a_buffoonery_of_orang-utans
• #a-buffoonery-of-orang-utans
• #aBuffooneryOfOrangUtans

It also makes easier to distinguish between regular class name values and Pseudo class names:

• #the_last_child:last-child
• #the-last-child:last-child
• #theLastChild:last-child

Finally improved readability has the benefit of revealing to the designer where there might be suitable points for spitting up class selectors into two or more separate values:

• .a_box_for_introduction_text =>  .a_box .introduction_text

• .a_box_for_pull-quotes       =>  .a_box .pull-quote

The :first-child, :last-child pair of CCS2 pseudo-classes are useful when working with design patterns such as the ‘Horizontal Menu’ that utilize a HTML list. Unfortunately like much of CCS2 they’re not fully supported by all modern web browsers. One work around is the addition of the class attributes values .first-child and .last-child to the corresponding first child and last child list items. By adopting these ‘pseudo pseudo-classes’ you can prepare your CSS for the day browsers join the 21st Century and implement .first-child and .last-child properly at which point you can remove the class declarations from your HTML and FaR all declarations of li.last-child with li:last-child.