Not satisfied with existing solutions for Png transparency support in Internet Explorer 6 and 5.5, I decided to have a crack at it myself.

Png-6 is a standalone (Java)script that converts inline png-24 images into ‘png-6’ elements. Features include:

• Full CSS box-model support ( padding, border, width/height and margin )
• Integration with third-party selector engines and/or standard dom methods for more precise image conversion
• Requires no placeholder images to work

In case you were wondering the ‘6’ part is a homage to the popular browser. You can download a copy of the script or hot-link it from its google code project page.

Often, when enhancing web pages with scripted behaviours, you find yourself creating anchor (link) tags as convenient event triggers. As these links usually have no meaningful href attribute, they provide little or confusing feedback to the user.

Take, for example, a typical web page with a scripted dynamic show/hide collapsing box. Adding a trigger link statically to the markup for this would be inappropriate, as it would exist solely for the purpose of a scripted event when JavaScript to handle the event may or may not be available.

The usual solution for this is to insert the link via JavaScript and give it some benign href attribute so that it looks and behaves like a normal link, perhaps empty, or with an empty statement using the JavaScript pseudo protocol:

<a href="#">Toggle Panel</a>
<a href="javascript:;">Expand List</a>

The problem with this is that the status bar now gives no meaningful feedback as to what will happen when the link is clicked.

Screen readers can also struggle with fudged href links; in some configurations the link text is read in combination with the href attribute. So having a random or absent href value in this scenario could make the links quite confusing (see YUI blog article on empty links).

Alternative solution: use a pseudo protocol

By using an intuitively named pseudo protocol in the link href, we can provide useful tailored information for the user.

Pseudo protocol names take the format of any word followed by a colon. However, be careful to not clash with any other existing native protocols (mailto:, data:, :javascript, http: etc.) or user defined protocols on your site. This would be rare but is possible in more recent Gecko browers.

For demonstration, I’ve created a generic pseudo protocol named ‘action’ for all scripted event triggers; the following examples illustrate how this would look:

<a href="action: Toggle panel">Would you like to see more?</a>

<a href="action: Show slide 2">2</a>

<a href="action: Click to process your request, 
   then we'll then redirect you to www.amazon.co.uk">Place order</a>

View demo page.

The status bar now displays helpful information when links are hovered or focused with the keyboard:

Drawbacks

Using pseudo protocols in this way means you’ll have to cancel the browsers’ default action when links are clicked, or the browser will get confused because you’re asking it to use a protocol it doesn’t understand. This shouldn’t be a problem in this case, though, as these pseudo protocol links should exist purely as scripted event triggers.

Here I’d like to outline (for myself as much as anything) why I think the web should be using HTML5 right now.

For the web standardista community XHTML has long been the benchmark for high quality front-end markup. But its promise – a future web of lean, semantic and multi-purpose XML – has not come to be.

I think XHTML is too pure in its ideals to fit with the sprawling ‘do it yourself’ nature of web authoring, let alone lack of support by major browsers. It still has its place in the world, but for now it looks to go down as a transitional phase in the history of mainstream HTML. Which is ironic as the most practical version of XHTML for use on the web has been the transitional variant (I should note that using any transitional doctype is a compromise; it is intended to support legacy code until conversion to a strict doctype is practical).

For good reasons it’s clear that XHTML has failed for 99% of what people are doing on the web right now.

Things that do not support XHTML 1 (of any variety):

• Microsoft Internet Explorer (cannot accept mime type application/xml)
• Most WYSIWYG editor generated markup
• Most mashup generated markup
• Most third party JavaScript widgets

Things that XHTML 1 (of any variety) does not support:

• A rich set of semantic elements to choose from
• Element.innerHTML (core to every JavaScript library)
• Inline JavaScript without ugly escaping
• The target attribute on hyperlinks (which is not as bad as some would say, hence its inclusion in HTML5)

It’s not all bad

One of the reasons XHTML has been so enthusiastically adopted in the past is that it enforces a clean consistent markup style. Tag soup and font tags were awful, so the reaction in wanting to make the web strict XML was actually very beneficial; it has created an online community of designers and developers who appreciate and can author clean, maintainable and high quality markup.

And now... HTML5

HTML5 for me represents a complete rethinking of the HTML specification based on the way the web has evolved. While I won’t try to cover all the detail here (as it has been done very well elsewhere), I would like to pick a few details that capture how HTML5 has taken the web forward without breaking anything.

First look at the HTML5 doctype:

<!DOCTYPE html>

Nice and simple isn’t it. The good part is that it’s not just a pretty face; it invokes full standards rendering mode in all browsers. This is more than be said for transitional doctypes that invoke the maddeningly named ‘almost standards’ rendering mode in some browsers and ‘standards’ mode in others. Like we need more cross-browser incompatibility.

With HTML5 you can even type it from memory, and know you’re running your code in strict mode in all browsers.

Have you ever wondered why the type attribute is necessary in your style and script tags when there is only one styling language and one scripting language used with HTML? In HTML5 type attributes for these elements are now optional. An elegant move forward whilst remaining fully backwards compatible.

Forms get a substantial overhaul in HTML5. Form validation that is now handled by JavaScript on the client becomes native to the browser in HTML5. Form inputs now have a fairly extensive set of type options; and because the default input type is text, browsers that don’t recognise the new input types can degrade gracefully.

The new semantic HTML5 elements, such as nav, section, time etc. can all be used now, with the caveat that IE does not style elements that it does not recognise. This can be easily fixed with a little JavaScript bootstrapping.

But for me a JavaScript dependency on this level does make the use of these new elements somewhat hard to justify, at least until the most recent version of IE can support the styling of these elements for users without JavaScript. It has been suggested that you could serve two versions of your markup with a little regular expression hackery – one for IE, one for everyone else – but that seems like overkill to me.

Keeping it clean

The only drawback I can think of with using the backwards compatible HTML5 features, over an XML type markup language, is the syntax rules. Because in HTML5 there is no requirement for lowercase tags and attributes or closing tags for all elements, it does lead to the probability of inconsistent and less readable markup. All these examples are valid HTML5:

<DIV TITLE=shout></DIV>
<div title=”talk”></div>

<p>Paragraph with no closing tag
<p>Paragraph with a closing tag</p>

<img src=”myimg.jpg” alt=”Where’s my close”>
<img src=”myimg.jpg” alt=”Here” /> 

<br>
<br />

I personally don’t think mixing the open/closed tag styles is doing anyone any favours. It just looks wrong if the author is making arbitrary decisions about when to close tags. The problem is the inconsistency; readable markup is consistent. Because HTML requires some tags to be closed it is better if they all open and close as they do in the XHTML standard.

It’s also often derided for its omissions. I mean, why is there no insertBefore method, when an insertAfter method exists in the spec? Thankfully some changes are coming through; features like getElementsByClassName and querySelectorAll have quickly become standardised.

While much of the rather clunky DOM interface persists, library authors have been quite successful in creating abstractions for dealing with the DOM in a more intuitive way. Although even with library abstractions, one area that still causes me pain is the creation of nested DOM fragments.

In some situations you can use innerHTML. However, it’s usually a hack for when you can’t be bothered to do things the DOM way. Which, besides being a pain, is actually a lot more versatile and elegant from a code point of view.

So, in efforts to find a better solution, I’ve created a few functions as part of my library that make creating elements and fragments using the DOM interface a lot more convenient. One utility for creating elements, named createElement (logically enough), and a related utility, named createBranch, for merging nodes into nested DOM fragments.

For a simple example, say you want to create some simple wrapper HTML like below, and retain a reference to the inner element:

<div id="widget-foo">
  <div class="content">
  </div>
</div>

Using the default DOM interface you might do this:

var wrapper = document.createElement( 'div' );
wrapper.setAttribute( 'id', 'widget-foo' );

var inner = document.createElement( 'div' );
inner.className = 'content';

wrapper.appendChild( inner );

Fairly long-winded compared to an innerHTML approach. But using the createElement utility (which I should note does not conflict with the document namesake) you can cut out some of the fat, while retaining the advantage of keeping the DOM references accessible.

var wrapper = createElement( '#widget-foo' );
var inner = createElement( '.content' );

wrapper.appendChild( inner );

You’ll notice the argument passed in is a simple CSS selector. The default element type if not specified is a div otherwise you could write ‘div.content’ explicitly, or ‘p.content’ for a different element.

Taking things a step further, the createBranch utility merges elements defined with same syntax that are passed in as arguments.

var branch = createBranch( 
    '#widget-foo',  
        '.content @:content' 
   );

This creates the HTML structure, but instead of returning an element reference you get an object of references:

{
  root   : #widget-foo,
  div    : [ #widget-foo, .content ],
  content: [ .content ]
}

The function collects references to all the created elements in a way similar to getElementsByTagName. The '@:content’ declaration simply creates a direct named reference so we don’t have to go digging when we need it later. Using the created branch is now as simple as this:

branch.content.innerHTML = 'Hello world'
document.body.appendChild( branch.root )

More complicated structures can be achieved by passing in arrays as sibling groups:

var branch = createBranch( 
    '#widget-foo',  
        '.content', [ 
            'h1 setText: "Introduction"', 
            'p setText: "DOM stands for Document Object Model."'    
        ]);

Which would create the following DOM fragment:

<div id="widget-foo">
  <div class="content">
    <h1>Introduction</h1>
    <p>DOM stands for Document Object Model.</p>
  </div>
</div>

Branches can also be nested, so creating something like an HTML table is manageable:

var thead = createBranch( 'thead', 'tr', 
   [ 
     'th setText: "Pros"', 
     'th setText: "Cons"' 
   ]);
   
var tbody = createBranch( 'tbody @:tbody', 
   [
   createBranch( 'tr',
      [ 
        'td setText: "Fast"', 
        'td setText: "Expensive"' 
      ]),
   createBranch( 'tr',
      [ 
        'td setText: "Looks good"', 
        'td setText: "High Maintenence"' 
      ])
   ]);

var table = createBranch( 'table.results', [ thead, tbody ] );

I have been using these utilities for a while now, and though they may not be perfect, they are definitely more practical to use than bare-bones DOM construction. I also find myself more inclined to use real DOM fragments rather than hacking away with innerHTML, which can only be a good thing.

The source for these utilities is freely available, under the conditions of an MIT license, over on the Jelly JavaScript project site.

If you’ve ever tried, you’ll know that styling an html file upload control is like flogging a dead horse.

Due to the security issues of enabling any user to upload files directly to a server, html file upload controls have evolved to be pretty robust. You cannot write the value attribute of them with JS; you can imagine what a malicious script could do with that! You cannot change the button text which is defined and locked down by the browser.

Because of the efforts of browsers to minimize the attack surface, most of the CSS properties we usually use to style form controls don’t have any effect. This leads us, inevitably, to hybrid frontend workarounds if we want to manipulate the way these controls look on our page.

As you can see from this image, there is a fair amount of variation in the way browsers deal with the file upload control. Webkit differs the most by not showing the path to the file name you select, and since we can only reliably read the the actual file name with JS, we’ll follow this pattern (I think the Webkit approach is the most elegant anyway).

The spec

What we’re aiming for is a nice fat button where we can have full control over the button style and text. We want a solution that will behave nicely and consistently in all the browsers, and be versatile enough to cope with modifications and variations.

The demo

Check out the working demo here.

The details

The html markup is pretty simple, we just want to create a button-like unit which can be placed anywhere in a form:

<div class="file-upload-btn">
	<label for="file-upload-1">Upload file</label>
	<input id="file-upload-1" type="file" name="uploaded" />
</div>

The main trick is in the CSS. What we’ve done is place the upload field in an element with display set to inline-block and overflow set to hidden. We position the label over the field to create the button text. By making the upload field font-size very large we essentially create a large hit area that will give us the basic button functionality.

To customise the appearance, first we set the upload field opacity to 0 (a different property is needed for Internet Explorer as you can see in the source). Now we can add background images and border effects to create the look and feel. View the commented CSS for the full treatment.

Using JS we have lazy-loaded the CSS file. One advantage of this is that we maintain a clean separation between our general site CSS and the UI element specific CSS; just tagging chunks of CSS onto a main file for every UI widget is an approach that will not scale for websites that have a growing number of JS dependant widgets. Another advantage is that the styles will only be applied if JS is available, so we can have graceful degredation with minimal effort.

I should note that the Jelly Javascript library is being used for this demo. However, you should be able to port the code to a library of your choice if you know your JS and chosen library well.

To create the uploaded file label, we bind a handler to the file upload onchange event which dynamically inserts (or removes) an element after the file upload element. Some other display issues are also addressed; view the commented JS for the full details.

To start with, some kind of guillotining bug on long content – more characteristic of a certain popular browser – was spoiling the display of long pages, truncating them by up to 50%.

An important fix to this spawned another problem, with the introduction of an unsightly flash of page background colour, making the page rendering somewhat less than slick.

A workaround, although less than ideal, seems to fix the worst of the problem.

To my surprise I had something to do with it. What’s more, Mr Zeldman kindly offered a copy of his excellent designing with web standards (third edition) as a gift!

I love a happy ending.

It’s never been a favourite tune of mine – actually I’m not much of a Michael Jackson fan – but this stripped down cover version by Gary Mitchell is a lot more soulful to me than the full on production of Jackson’s version.

The sound quality isn’t that good (and unfortunately it cuts a little short) but musically it hits the sweet spot.

This could be of special interest if you, or anyone you know, has a passion for mountaineering. Regardless, it’s worth checking out as it shows how much more there is to this country than the headlines would have us believe.

Static embedding has several advantages over the JavaScript injection technique:

• Works when JavaScript is unavailable
• Is more robust; unreliance on JavaScript means if an earlier script error halts the interpreter, the SWFObject doesn’t die as well
• Search engines can access statically embedded Flash content (text and links) more effectively
• Static embedding makes Flash possible in RSS feeds

I also like the way this method avoids the mess of printing out client script variables, when feeding in from a server-side data source for example.

As you can see it’s fairly simple, but gives you a lot of control over what parameters and attributes are applied. It generates the same ‘flash satay’ as the SWFObject 2.0 static publishing method.

class FlashObject {
   
   public $attributes = array();
   public $params = array();
   public $variables = array();
   public $path;
   public $width;
   public $height;
   public $id;
   public static $default_alt_content = '<a href="http://www.adobe.com/go/getflashplayer"><img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Get Adobe Flash player" /></a>';
     
   function __construct ($path = '#', $width = 100, $height = 100, $alt_content = '', $id = '') {
      $this->path = $path;
      $this->width = $width;
      $this->height = $height; 
      $this->alt_content = !empty($alt_content) ? $alt_content : $this->default_alt_content; 
      $this->id = !empty($id) ? ' id="' . $id . '"' : '';
   }
   
   function setAltContent ($str) {   
      $this->alt_content = $str;
   }   
   function setVariables ($arr) {
      $this->variables = $arr;
   }
   function setParams ($arr) {
      $this->params = $arr;
   }
   function setAttributes ($arr) {
      $this->attributes = $arr;
   }
   function setId ($id) {
      $this->id = $id;
   }
   
   function get () {
      $attributes = '';
      $params = '';
      $variables = array();
      foreach ($this->attributes as $key=>$val) {
         if ($key !== 'id') { $attributes .= ' ' . $key . '=' . '"' . $val . '"'; }
      }
      foreach ($this->params as $key=>$val) {
         $params .= "<param name=\"{$key}\" value=\"{$val}\" />";   
      }
      foreach ($this->variables as $key=>$val) {
         $variables[] = $key . '=' . urlencode($val);
      }
      if ( count($variables) ) {
         $params .= "<param name=\"flashvars\" value=\"" . implode('&', $variables) . "\" />";
      }
      $str = "<object classid=\"clsid:D27CDB6E-AE6D-11cf-96B8-444553540000\" width=\"{$this->width}\" height=\"{$this->height}\"{$this->id}{$attributes}>";
      $str .= "<param name=\"movie\" value=\"{$this->path}\" />";
      $str .= $params;
      $str .= '<!--[if !IE]>-->';
      $str .= "<object type=\"application/x-shockwave-flash\" data=\"{$this->path}\" width=\"{$this->width}\" height=\"{$this->height}\"{$attributes}>";
      $str .= $params;
      $str .= '<!--<![endif]-->';
      $str .= $this->alt_content;
      $str .= '<!--[if !IE]>-->';
      $str .= '</object>';
      $str .= '<!--<![endif]-->';      
      $str .= '</object>';            
      return $str;
   }
   
   function render () {
      echo $this->get();
   }
}

Example use:

$swiff = new FlashObject('path/to/file.swf', 200, 300, 'Alternative Content here', 'Myid'); 

$swiff->setVariables(array( 
    'hello' => 'world', 
    'myVar' => '200'  
   )); 


$swiff->setParams(array( 
    'wmode' => 'transparent'  
   )); 

// Print out directly
$swiff->render();  

// Or assign for later use
$mySwiff = $swiff->get();

If a link tooltip merely repeats the link text it will actually hurt usability by creating more information ‘noise’ for the user to deal with.

Tooltips, when used correctly, can be an excellent and necessary augmentation to text links or icons; providing further description on demand, and removing any potential ambiguity. In some situations they are a necessity, such as in desktop software or web applications that rely heavily on icons to streamline the user interface. When writing content for the web, though, they should be used sparingly and only in certain contexts.

Acronyms and abbreviations should be marked up with acronym and abbr tags respectively, and have tooltips displaying what they stand for in expanded form. In my opinion, this should be done at the first occurrence on every page and not repeated for every occurrence on every page, as it looks messy and cluttered if there are multiple instances on a page.

Text links should be written in an intuitive way as possible so users know where they are going if they click through. Sometimes, however, it may not be possible to do this elegantly, or the link may require some supplementary information relating to browser behaviour (e.g. link opens in a new window). In this case tooltips can help if they are well written, and actually contribute useful information rather than merely repeating the link text.

Images can benefit from tooltips as a way of providing caption text (well demonstrated by Google with their search page masthead). However, it is usually preferable, for ease of use, to have caption text visible on the page rather than hidden in a tooltip.

Internet Explorer plays some havoc with tooltip behaviour by turning image alternative text into tooltips; to circumnavigate this add an empty title attribute to your image tags.

The power of using an already familiar CSS syntax to gather elements is very satisfying, especially if previously you have been used to using bare-bones DOM methods. Their obvious appeal has made them central to most of the major frameworks in use today, and although they have been around for some time, a battle still continues within the developer community over which implementation is the fastest and most complete.

The days for this ongoing contest are numbered now though – with the advent of the Selectors API, querySelector and querySelectorAll will soon be available in all major browsers. But, alas, the older browsers linger well beyond their welcome, so the non-native selector engines will endure, for a while at least.

Since I’ve been working on a library for my projects, and had been lacking a descent selector engine, I decided to have a shot at building one to suit my needs, and fit within the existing library code.

Introducing Q

Ideally I wanted the engine to follow as closely as possible the behaviour of querySelector(All) so its functionality would be consistent whether the native API is supported or not. This meant cutting out a few features that are fairly common in other selector engines, such as the non-standard [attribute!=value] (instead you can write :not([attribute=value])) and the :contains pseudo class which has since been removed from the specification. Otherwise the selector support is as complete as is possible, or sensible, using JavaScript:

Some example usage:

// Function returns a static array of nodes
var collection = Q('#myid div.myclass');  

// Get first element in the list
var first = collection[0];  

// Loop using array methods
collection.each(function (el) {   
   // processing...
});

// Specify an initial context node (document is used by default)
var node = document.getElementById('myid');
var collection = Q(node, 'a'); 

// Complicated selector
var collection = Q('div+div+div>li:not(:last-child)');

How does it perform?

Q is pretty fast when run through the Slickspeed test. It also has good accuracy in returned result sets (more on this below).

From my tests, base2 and DOMAssistant usually come out top in terms of speed across a large range of selectors, but if you run the same test through your machine you will probably get different results depending on what computer, browser and platform combination you are using.

Lessons learned

Using the slickspeed test suite and testing engines in different browsers and machines has revealed some surprising results. Engines faster in one combination perform slower and/or turn up different results in other combinations. This makes the question of which one is ‘best’ a little slippery, even if basing judgement on speed alone.

The most crucial aspect, apart from speed, when judging an engine’s performance should be the accuracy with which it can return results across different browsers. You could argue that incomplete support for a selector that will rarely get used is not significant, but personally, I think it is. Technology should do what it promises; p:nth-last-of-type(-2n+3) may never get used, but knowing it’s avaliable makes a difference to how confidently I can use the API. At least there is then the opportunity to discover, through experience, where the real-world uses are for the more esoteric selectors.

Download

If you want to try the Q selector engine in your own projects, you can download it in standalone form on Google Code, licensing is MIT style.

Some of the recent arguments against CSS are:

• You always have to add excessive markup ‘cruft’ to get the job done
• Selectors can’t target ancestors or previous siblings (as you can in JavaScript)
• It’s an ineffective tool for laying out pages

You always have to add excessive markup ‘cruft’ to get the job done

The problem at the root of this complaint is more to do with bad browser CSS implementations than with CSS itself; basically, web authors have been using a crippled subset of CSS for so long that most have forgotten, or never learned how to use a more complete implementation. IE6, dominating the browser market for such a long time, has meant developers have had no choice but to avoid using child selectors, adjacent sibling selectors, attribute selectors and class chaining. But the potential in these ‘missing parts’ is enormous when you take advantage of them.

Child selectors alone greatly decrease the need for markup cruft, and make stylesheet declarations more compact, precise and expressive.

Attribute selectors can be used to target attribute prefixes e.g div[class^="column-"] would target div elements that have a class-name beginning with ‘column-’.You could apply styles to all your column-n classed elements without having to add extra styling hooks. Other uses include regular attribute targeting, which saves us having to add more markup e.g. input[type="text"].

Class chaining enables us to create more sophisticated inheritance patterns in our code, again saving us time and markup while making our stylesheets more intelligent.

That’s just the simple stuff, currently supported in all non-IE6 browsers. CSS still has much more:

• Generated content
• CSS3 selectors nth-child etc.
• :not(.foo)
• :first-child / :last-child

This makes a pretty powerful toolset; all we need is browsers that support these standards.

Selectors can’t target ancestors or previous siblings

Given the power of CSS selectors, if you need to select nodes in all directions, you’re probably doing something wrong. CSS works pretty hard to display the page in response to every mouse event and actions that cause page re-flow, so I expect the limitation is largely due to performance, which is pretty reasonable.

It’s an ineffective tool for laying out pages

For me, this argument is the only one that holds some weight. But again, with browsers that implement the standards correctly, CSS layout isn’t that hard, just a little awkward sometimes.

To wrap up

I still think CSS is ok, it’s outdated browsers that are the problem. What I’d like to know is how to get users and IT departments to upgrade more often :)

It’s a little sparse around here, but it will grow.