Accessibility is a hot topic on the web, and there are many emerging standards to help move in an accessible direction. We have CSS media types, alternative web pages with simpler navigation and high-contrast styling, alt and title tags, and the general move away from mixing style with substance.

Along with all of this, we have the relatively old standard of using the accesskey attribute on invokeable elements such as hyperlinks and form inputs. This allows us to attach a keyboard shortcut to elements in our webpage.

Unfortunately, this isn’t a widely used, or easily implemented standard. Although the accesskey attribute is widely supported, only one commonly-used browser (Opera) at the time of writing provides an easy way for users to see what accesskeys are enabled on a given site, and there is no widely-accepted standard for choosing which accesskeys perform which function.

However, with a little jiggery-pokery we can implement a simple way to show accesskeys on demand:

The code for the above is pretty simple. First, the button:

<input type="button" value="Show access keys" 
       onclick="showKeys()" style="float: right;" />

The hyperlink itself (abbreviated):

<a href="http://jeremysmyth.com/...." 
       title="Link to this post" 
       accesskey="9">This link</a> 
will bring you...

Finally, the javascript:

function showKeys() {
        if (document.styleSheets) {
                var sheet = document.styleSheets[0];
                var len = sheet.cssRules.length;
                // reformatted to fit
                sheet.insertRule("[accesskey]:after {" +
                        "font-weight: 700; " +
                        "border-bottom: 1px blue dotted; " +
                        "content: '[' attr(accesskey) ']';}" , len);
        } 
}

Clicking on the button calls the “showKeys()” function in the Javascript script block, which adds a style to the current stylesheet. The style automatically styles elements with the “accesskey” attribute, adding the value of that attribute after the element itself.

Put simply, it adds a styled [9] after the hyperlink, because (1) it has the “accesskey” attribute, and secondly, the “9″ is the value of that attribute, as calculated by the attr() function.

Note: The above Javascript won’t currently work in Internet Explorer; for that, you’d need Microsoft’s addRule function rather than the standards-compliant insertRule I’ve used.

We have thousands of open idea requests (the codebase is nearing 20 years old), and close only a sizeable fraction of those opened regularly.

From our perspective, the idea requests are welcome, but not all of them are actionable; some are brilliant, and are implemented immediately because they work well with our vision; some are entirely incompatible and are closed/denied.

The majority fit in between; they’re ideas that would work with a bit of tweaking, or a bit of thought, but aren’t necessarily on the primary development roadmap, so don’t get our attention immediately. Nor do they warrant closing, because they are relevant, merely not timely or important.

Because our developers have their own ideas, their own neverending todo lists, we treat the open idea pile more as inspiration than as a roadmap. There’s very much a feeling of “we’ll get to it when we’ve run out of other things to do”, but this never happens in practice.

I know it’s a cop-out not to choose one or the other, but I think it’s a normal thing to have to choose between two equally bad things in a public forum like this: either responding to most feature requests with a “denied”, and so risk upsetting the folk who love the community enough to contribute with their own ideas; or leave some of them dangling because they’re not immediately and obviously wrong, but to do something worthwhile with them takes more time and effort than the idea deserves right now.

It’s pretty well known that most browsers will display a tooltip of sorts when you hover over an image. The alt attribute of the img tag gives rise to that, in pretty much all places.

Lesser known is the title attribute, which is supposed to give the tooltip; the alt attribute might do that as a side-effect if title isn’t there, but it’s just that: a side-effect. The alt attribute is really there to give browsers that aren’t displaying images (or screenreaders that can’t see them anyway) some idea of what the image is.

This separation of concerns is somewhat of a problem when it comes to image maps: in image maps, the alt text for the area elements is there for similar reasons, to show what options are there when the image isn’t there. The title attribute is there for the tooltip, as ever.

However, if both alt and title are there, Internet Explorer shows the alt text as a tooltip, where Firefox will show the title text. Although they serve very different functions, a conscientious web developer is forced to keep them identical, or risk causing problems for the non-standards-compliant behaviour of Internet Explorer.

Of course, title will still work in other places, for example on images or even links:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

What’s the relationship between that and the actual code in the web page?

Well, a DOCTYPE tag declares what document type this webpage is, by formally specifying a Document Type Descriptor (that’s what the “dtd” in the filename and in the declaration means). This is the formal specification, written in its own computer language, used to define legal dialects of languages descended from SGML. Most predominantly, this includes languages like HTML 4.01 and XHTML. Hence this walkthrough.

In our specific case, it references a specification for XHTML, which is a modular XML-expressed version of HTML. Let’s look inside.

Firstly, if we look in the declaration, we see the link ““http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd” which, if you download it, shows the DTD itself. For XHTML, this is a relatively short document; the specification largely consists of modules, referenced from this document. Let’s have a look.

Within the DTD, you’ll see this section (around line 121):

<!-- Text Module (Required)  ..................................... -->
<!ENTITY % xhtml-text.module "INCLUDE" >
<![%xhtml-text.module;[
<!ENTITY % xhtml-text.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Text 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-text-1.mod" >
%xhtml-text.mod;]]>

This defines a module to be included, which itself is a technically part of the DTD as it is INCLUDEd.

If you navigate to the included module, “http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-text-1.mod”, you’ll see a further set of INCLUDEd items, for example:

<!ENTITY % xhtml-inlstruct.module "INCLUDE" >
<![%xhtml-inlstruct.module;[
<!ENTITY % xhtml-inlstruct.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Inline Structural 1.0//EN"
            "xhtml-inlstruct-1.mod" >
%xhtml-inlstruct.mod;]]>

This entry includes the inline structural elements br and span, and further down the document we have more included modules containing inline phrasal elements (em, strong etc.), block structural (p and div), and block phrasal (h1, h2 etc.).

Try them:

• xhtml-inlstruct-1.mod
• xhtml-inlphras-1.mod
• xhtml-blkstruct-1.mod
• xhtml-blkphras-1.mod

In each, you’ll see the definitions for tags such as p, div, code, strong, em and so on.

For comparison, have a look at the HTML 4.01 DTD, which you’ll be able to follow using the DOCTYPE:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">

…and linked to from here: http://www.w3.org/TR/html4/strict.dtd. As you’ll see, it’s not quite modular, but still contains code defining the elements (and their contents, attributes and so on) that are legal within the dialect concerned.

Some other useful metrics:

• What sort of bandwidth do they support? How about if it’s a shared pipe and they’ve multiple high-volume clients? You’re unlikely to get an honest answer to this from the vendor.
• If you’re on a shared host, what sort of competition for resources will you have on the box? Again, this is competitive information, so you’re unlikely to get an honest response.
• How independent is each application? i.e. if another application on a co-hosted box loops MySQL, will your app suffer?
• How often do they upgrade dependencies, and does that affect their 99.98% uptime?

Then there are the fluffy not-entirely-QoS related hosting problems:

• Will they do your backups etc.?
• How responsive are they to queries? Do they have a guaranteed response time e.g. 3 hours from first email to first response, 24/7?
• Are they efficient? Have they resolved issues within a useful timeframe? A quick response-time is nice and feelgood, but if they don’t fix the problem, that’s not quite so good!
• Are they patient with you when you suggest issues, but due to your own technical background are slightly off-base?

An example of hierarchical data

As an example, let’s say you have forums within categories. The category “Web Programming” may have forums like “PHP”, “JavaScript” and so on, so we want to list each forum under each category. The problem here is that you’ll have:

• a table for categories
• one for forums (with a foreign key for categories)
• one for posts, with a foreign key for forums
• and probably one for comments.

This fits quite neatly into a hierarchy: each comment belongs to a post, which belongs to a forum, which belongs to a category.

Using multiple resultsets

If you want to display the Categories with Forums under them in your page, one way to do this is by setting up multiple resultsets, each focusing on one level of the hierarchy. To achieve this, you’d need to get a resultset for the categories first, and then iterate over this list with another loop for your forum list.

The following code is an example of iterating using nested queries:

$cat_rs = mysql_query("select id, name from categories");
while($cat_row = mysql_fetch_array($cat_rs)){
     // print category name from $cat_row[1]
     $forum_rs = mysql_query("select name... "
                          . "from forums "
                          . "where cat_id = '" . $cat_row[0] ."'");
     while($forum_row = mysql_fetch_array($forum_rs)){
        //print forum stuff
     }
}

Although this matches the hierarchical nature of the data, and is pretty straightforward and intuitive to understand, it is somewhat inefficient; it issues a select statement for each category, plus one to list the categories in the first place. If there are many categories, the page might take some time to load as all queries are issued and processed.

Using a SQL JOIN: a single resultset

Another way to solve the problem would be to retrieve all relevant data in a single resultset, and use PHP to iterate over the rows, deciding on when to print each individual section.

A join will give you a single recordset with the category in one column, and the forum in another, giving you many rows for a single category.

$join_rs = mysql_query("select c.id, c.name, f.name,... " 
                        . "from categories c inner join forums f "
                        . "on c.id = f.cat_id "
                        . "order by c.id"); // this line is crucial
$current_category = "";
while($join_row = mysql_fetch_array($join_rs)){
        if($join_row[0] != $current_category){
                //set up new category headings here
                $current_category = $join_row[0];
        }
        //print the forum stuff in the current category
}

The PHP is a bit more complex, because you have to close divs or tables correctly, within the loop. The order by line in the above example is vital, because without it, the categories may be dotted throughout the resultset. As we want all forum data related to a single category to appear together, we want rows belonging to that category to be adjacent in the resultset. The order by clause achieves this.

Despite the complexity, there are still benefits to this approach. The earlier example was simple and intuitive, using nested queries for each parent element. On the other hand, in this example we’ve only issued one select statement, so the page is likely to load more quickly, given that the number of round trips to MySQL will be substantially fewer.

So, fiddling with AJAX, let’s do a little Hello Worlding:

Here’s a button, that when clicked, calls the “startRequest()” function in some javascript behind the entry:

<input onclick="startRequest()" type="button" value="Hello World!" />

And here’s a div:

<div id="ajaxtest">
<em>(although you can't see it as a separate div, 
this text will be replaced)</em></div>

Go on, watch the div text above, and click the button.

Here’s the javascript:

var xhr;
if (window.XMLHttpRequest){
  xhr = new XMLHttpRequest();
}
else if (window.ActiveXObject){ // in case it's IE
  xhr = new ActiveXObject("Microsoft.XMLHTTP");
 }
// set up the callback
xhr.onreadystatechange = function(){
  myDiv = document.getElementById("ajaxtest");
  if(xhr.readyState  == 4) {
  if(xhr.status  == 200){
   myDiv.style.background = "green";
   myDiv.innerHTML =  xhr.responseText;
  } else {
   myDiv.innerHTML = "Error: " + xhr.status;
  }
  }  
}
function startRequest(){
  xhr.open('GET', '/ajaxtest.php', true);
  xhr.send(null);
}

Firstly, the code sets up a variable xhr, which contains the magical object. This is the XmlHttpRequest object, and is responsible for communicating from the live Javascript to the back end server.

The request object is first set up at the script’s execution, but the only thing we do with it is tell it what to do when its “ready state” changes; that is, when the request shifts from not initialised, to set up, to having been sent, to being in process, to completion.

These states are numbered 0-4 respectively. Hold that thought; we’ll use it later. Suffice to say that, on the script’s execution, we now have an otherwise anonymous function that will be called when the ready state changes.

Now, in order for something interesting to happen, we click the button. That kicks off startRequest(), which in turn sets up a asynchronous request to ajaxtest.php, and submits it with no parameters (that’s the null). Asynchronous means we don’t sit around waiting for a response, and that’s why we need the readystatechange callback function.

So, when something interesting happens to the xhr object, the ready state changes (e.g. when we get a response back after sending our request). The browser then executes the anonymous function: first, the function checks that the request is complete – remember Ready State 4 above? don’t forget the ready state changes several times per request. We only want to read the response text once, at completion. Once the function has checked the request has been successfully completed, it then uses the xhr’s response-text to fill in the div called “ajaxtest”.

Et voila, we have “Hello World” in AJAX.