ContentedLife

Look at the state of this… the URL itself I mean, not the page it points to:
http://www.tbs-sct.gc.ca/rma/eppi-ibdrp/hrs-ceh/6/RMA-CGR_e.asp

Can you imagine trying to dictate this to someone over the phone, or read it out on the radio? Reckon you can memorise it? If you saw it in your history list would you remember what the page was about?

URLs should be:

• designed for people, not computers and not filesystems;
• as short as possible (maintaining hierarchy only as necessary);
• as meaningful as possible — using words, dates, standard reference numbers, or whatever will make sense to your users, not a bunch of abbreviations;
• single case, not a mixture of lower and upper case;
• persistent (cool URIs don’t change), and therefore designed with persistence in mind. A URL is more likely to persist if it is sensible and economical in the first place!

URLs should not:

• include implementation details (.asp) and language preferences (_e), both of which can be handled transparently by content negotiation;
• use unnecessary punctuation. Some punctuation is ok, but four dashes scattered throughout the URL is too many.

Ideally, it should also always be possible to remove the trailing part of a path to obtain an index document for that level. If that’s not the case (which it isn’t for this one), it’s a probable sign that you have more levels of hierarchy than you actually need.

I’ve tentatively placed a toe aboard the AJAX bandwagon, thanks largely to Rails which makes it possible, even painless, to achieve AJAX functionality without having to learn Javascript.¹

While AJAX, done properly, can be a big win for Usability for those whose browsers support it, I am also concerned with issues of Accessibility, and indeed keeping things usable for those with non-AJAX browsers.

Standards-Schmandards have come up with some useful hints about how to make AJAX pages more accessible to screenreaders, such as providing an option to pop up an alert box instead of, or as well as, simply updating the page. This is good advice, but it’s only half the story. These methods don’t help those without Javascript at all, or with non-AJAX-aware browsers.

In this article I will detail one method to help ensure accessibility for such people, without compromising on AJAX spiffiness, and most importantly without causing much extra work for us poor developers. The example is in Rails, but may be of interest to those using other frameworks. (more…)

Imagine a creature, about the size of a football, which has long green fur, and several purple tentacles with a glowing red eye at the end of each.

You have never seen such a creature; you are never likely to see such a creature. But I bet you were able to imagine such a creature, and perhaps your mind also filled in additional details than the ones I described. Perhaps you added a mouth, teeth, perhaps the creature moved, the wind ruffled its fur. Maybe it had feet. Maybe it made a sound. Maybe you found that a whole environment sprung into existence around it.

Now try to imagine a sphere, a snooker ball say, which is spinning in one direction, and also, simultaneously, spinning in the opposite direction.

Again you have never seen this, but this time, you could not imagine it.

The simple difference is that the creature, however unlikely you are to ever encounter it in your day-to-day life, is possible. It is entirely feasible that this very creature exists somewhere in the universe. The ball spinning in opposing directions is impossible, by the very definition of “spin”.

Now, something amazing comes out of this seemingly futile exercise. Your mind is capable of imagining only what is possible. If something is possible, you can imagine it, just by someone describing it to you, even if it bears little or no resemblance to anything you have seen before — provided it can be described in terms that you understand. But if it is impossible, you cannot, no matter how well it is described.

Why?

(more…)

For ages I’ve been wishing it were possible to highlight part of a webpage and just view the source for that part, rather than scouring the whole page’s source for the relevant section. Now I discover, to my annoyance and delight, that Firefox can do this… sort of…

If you hold down the CTRL key and left click on part of a web page, that section of the page will be highlighted. If you right click on the selection and choose ‘View selection source’, the source code for that part of the page will be displayed.

That comes from a tips & tricks article on the MozillaZine Forums, which is crammed full of useful snippets like this. Many of them have been sorted into this knowledge base article, but I didn’t see the above one in there.

It’s not quite accurate. ctrl-click actually selects a table cell, not any arbitrary block. So this limits its usefulness. But it’s helpful for sites that are still using masses of nested tables for layout.

The two extensions I cannot live without are Web Developer and Session Saver.

The best order for dynamic link pseudo-class blocks in your stylesheet is (from W3C):

a:link    { color: red }    /* unvisited links */
a:visited { color: blue }   /* visited links   */
a:hover   { color: yellow } /* user hovers     */
a:active  { color: lime }   /* active links    */

The order matters because these dynamic pseudo-classes are not mutually exclusive in CSS2 (some of them were in CSS1), and later rules override earlier ones if they clash. In the example above, if a:link were placed last, all links would be the same colour (red) irrespective of whether they are visited, active or hovered.

Actually this doesn’t only apply to links; in some browsers any element can have :hover, for example.

Name your CSS classes according to what they are for, not what they look like.

That is, use names like codeblock, quotation, document-title, error-message and so on.

I’m currently having to deal with a mess of stylesheets for a client which are full of classnames like bigblack and reddots and bottomrightbox. They are just not helpful. I can see what it looks like by reading the stylesheet, what I want to know is what these classes are expected to be used for! If you have classnames like this, they’ll end up being used indiscriminately, and then you’re in real trouble if you ever want to change anything, because you have no idea what might be affected. But inevitably, at some point, the presentation of the class will get changed, but you can’t change the name because it’s too widely used, so it becomes downright misleading — you have a bigblack class which actually makes the text green or something…

Even worse are names like nobordertable. Here we have an extra dose of useless or wrong information, with the implication that this class is for use with tables (again without telling me what *sort* of table it’s for). Well why not specify that with a selector like table.classname? Then maybe I wouldn’t be finding this class applied to divs, spans, blockquotes….

Addendum 22nd March 2005: The W3C’s explanation is probably clearer.