Alt Gr + -(hyphen) = en dash
Alt Gr + Shift + -(hyphen) = em dash

Not sure if the same happens in Gnome; let me know if it works for you.

<div class="tabs">
    <ul>
        <li><a href="#panel1">Tab 1</a></li>
        <li><a href="#panel2">Tab 2</a></li>
        <li><a href="#panel3">Tab 3</a></li>
    </ul>
    <div id="panel1">
        <!-- panel content -->
    </div>
    <div id="panel2">
        <!-- panel content -->
    </div>
    <div id="panel3">
        <!-- panel content -->
     </div>
</div>

What's wrong with that? Well, the semantics are a bit off. Granted, it's not the worse example of content structure, but it's not very user friendly either: you have a list of links to content (the tabs), followed by several essentially unstructured content snippets (the panels). The tabs usually hold a meaningful title for the respective panel content, which makes sense visually since the tab and the content are rendered closely together and with visual clues indicating their relatedness once the JavaScript kicks in.

However, the tabs are not usually marked up as content headers (say, <h*>) since that would not create a meaningful content outline (all the headers would grouped together).  Also, if you wanted to use the same markup to provide different rendering depending on context you'd be in a bit of trouble. Here are just a couple of examples where you might want to do this:

• When printing the document tabs are obviously meaningless, so we'd want to output all panel sections with the correct title above each one.
• On a touch-screen smartphone we'd want to use an accordion widget instead of tabs.
• A screen reader could avoid the whole tabbed interface nastyness

The essential problem is the disassociation between title and content: the markup has been written to suit a specific UI widget. It is possible to work around this by adding the title to each panel and selectively hiding/showing it depending on context, but that is not an elegant solution.

Doing it right

That is all very interesting, you say, but where is the elegant solution, then? Coming right up. We start with some simple, semantic markup:

<h3>One</h3>
<p>Lorem ipsum dolor sit amet.</p>
<p>Proin posuere, velit non facilisis rutrum.</p>

<h3>Two</h3>
<p>Quisque tempor ligula risus.</p>

<h3>Three</h3>
<p>Suspendisse a orci turpis.</p>

And we add some scaffolding (note the selected class to highlight the selected tab):

<div class="tabWidget">
    <div class="tabWidget">
	<div class="tabPanel">
		<h3 class="tab">One</h3>
		<div class="panel">
			<div class="panel-inner">
				<p>Lorem ipsum dolor sit amet.</p>
				<p>Proin posuere, velit non facilisis rutrum.</p>
			</div>
		</div>
	</div>
	<div class="tabPanel selected">
		<h3 class="tab">Two</h3>
		<div class="panel">
			<div class="panel-inner">
				<p>Quisque tempor ligula risus.</p>
			</div>
		</div>
	</div>
	<div class="tabPanel">
		<h3 class="tab">Three</h3>
		<div class="panel">
			<div class="panel-inner">
				<p>Suspendisse a orci turpis.</p>
			</div>
		</div>
	</div>
    </div>
</div>

Note that I am using <div>s simply to keep the original semantics. You can use whatever elements make sense — there is an example using a list on the demo page. Here is the CSS:

.tabWidget {
    overflow: hidden;
}

.tabWidget .tabPanel {
    display: block;
}

.tabWidget .tab {
    float: left;
    /* change rules below for your desired visual effect */
    cursor: pointer;
    border: 2px solid #000;
    margin-right: 5px;
    padding: 2px 8px;
}

.tabWidget .panel {
    display: none;
    float: right;
    margin-left: -100%;
    margin-top: 1.7em;  /* adjust as needed */
    width: 100%;
}

.tabWidget .panel-inner {
    /* change rules below for your desired visual effect */
    border: 2px solid #000;
    padding: 10px;
}

.tabWidget .selected .tab {
    /* change rules below for your desired visual effect */
    background-color: #000;
    color: #FFF;
}

.tabWidget .selected .panel {
    display: block;
}

The magic happens in the rules float: right, margin-left: -100%, and width: 100%, applied to the .panel <div>. These rules remove the panels from the horizontal flow of the document (since their width is cancelled by their negative margin), but leave their vertical dimension intact, allowing them to push down the bottom of the tab widget. A gotcha is that the .panel <div>s must be pushed down by the correct amount so that they line up with the bottom of the tabs (i.e. adjust the margin-top: 1.7em rule to suit your design). This also means that multi-line tabs are probably difficult to achieve (I haven't tried them; let me know if you have ideas). The purpose of the .panel-inner <div> is to allow for borders and/or padding to be added to the panel content without interfering with the width: 100% rule applied to .panel <div>. If you need neither, these can be removed. All we need now is some JavaScript to handle the tab switching. Here's an example using JQuery:

$.fn.tabsDoneRight = function(options) {

    return this.each(function(index, el) {

        $(el).find(".tab").each(function(tabIndex, tabEl) {

            $(tabEl).click(function() {

                $(el).find(".selected").removeClass("selected");
                $(this).parents(".tabPanel").addClass("selected");

                return false;
            });

            $(tabEl).attr("tabindex", 0).keypress(function(ev) {

                if (ev.keyCode == 13) $(this).click();
            });
        });

        if (!$(el).find(".tabPanel:has(.selected)").length) {

            $(el).find(".tabPanel").first().click();
        }
    });
};

$(function() {

    $(".tabWidget").tabsDoneRight();
});

More accessible

We're adding onclick behaviour to elements that don't have a default interaction (the <h3> tabs) so keyboard navigation won't automatically be added by the browser. We must make the tabs focusable by the tab key (setting the tabindex attribute), and triggering the click event handler when the enter key is pressed (see the keypress event handler in the code above). What if JavaScript is disabled? The display: none rule will keep all non-selected tab panels inaccessible, so I recommend a little trick: display all panels by default, and trigger the hiding if JS is enabled. Let's change the CSS:

.tabWidget {
    overflow: hidden;
}

.tabWidget .tabPanel {
    display: block;
}

.tabWidget .tab {
    clear: both;
    float: left;
    /* change rules below for your desired visual effect */
    cursor: pointer;
    border: 2px solid #000;
    margin-right: 5px;
    padding: 2px 8px;
}

.js .tabWidget .tab {
    clear: none;
}

.tabWidget .panel {
    clear: right;
    display: block;
    float: right;
    margin-left: -100%;
    margin-top: 1.7em;  /* adjust as needed */
    width: 100%;
}

.js .tabWidget .panel {
    display: none;
    clear: none;
}

.tabWidget .panel-inner {
    /* change rules below for your desired visual effect */
    border: 2px solid #000;
    padding: 10px;
}

.tabWidget .selected .tab {
    /* change rules below for your desired visual effect */
    background-color: #000;
    color: #FFF;
}

.js .tabWidget .selected .panel {
    display: block;
}

To trigger the correct CSS for JS-enabled pages, add this code as far up in the <body> as possible:

<script type="text/javascript">
document.body.className += " js";
</script>

Putting it all together

With the above markup it should now be relatively straightforward to create alternative styling for mobile and print mediums. Even better, making use of CSS media queries you can decide to change the appearance and behaviour of the widget based, for instance, on the available viewport space. This solution has been tested in IE6, IE7, IE8, FF3.6, Opera 10, Chrome 6. It also seems to work in mobile browsers (Nokia and Sony Ericsson), although you will need to make the tabs either links or buttons (maybe via the JQuery wrap() function?) since the onclick event doesn't seem to trigger on non-link elements on those browsers..

The method doStuff(String) in the type Stuff is not applicable for the arguments (int)

int x = 100;
Stuff.doStuff(x.toString());

Cannot invoke toString() on the primitive type int

int x = 100;
Stuff.doStuff((String)x);

Cannot cast from int to String

int x = 100;
Stuff.doStuff(new Integer(x).toString());   // OMGWTFGRRRBBQ!!!

BUILD SUCCESSFUL

So, here’s a quick solution that works pretty much like the similarly-named PHP function, htmlspecialchars:

function htmlspecialchars(str) {

    if (str === undefined) return "";
 
    return str.replace(/[<>"&]/g, function(match){
        return (match == "<") ? "&lt;" :
               (match == ">") ? "&gt;" :
               (match == '"') ? "&quot;" :
               (match == "&") ? "&amp;" : "";
    });
}

What’s missing? The “quote_style” parameter which allows deciding what will happen with single quotes (‘). If your markup is sane and under control, there should be no need for it — if it isn’t, it’s not hard to change the above function.

So, quick fix coming up:

var radioGroup = new YAHOO.widget.ButtonGroup({ container: aDivSomewhereItDoesntMatterWhere });
var radioButtons = anArrayOfPlainNormalRadioButtons;

for (var i = 0, len = radioButtons.length; i < len; ++i) {

    var nodeIndex = getNodeIndex(radioButtons[i]),
        parentNode = radioButtons[i].parentNode,
        radioButton = new YAHOO.widget.Button(radioButtons[i]);

    // This will put the button somewhere silly
    radioGroup.addButton(radioButton);

    // Move the button back where it was
    parentNode.insertBefore(radioButton.get("element"), parentNode.childNodes[nodeIndex]);
}

So, it’s more verbose than just using the simple “new YAHOO.widget.ButtonGroup(radioButtonContainer)” syntax that does everything for you — if you are willing to have the radio buttons where YUI put them. Also… what’s that “getNodeIndex()” function?, I hear you ask. Just a simple utility off my toolbox; it gets the index of a node within all the nodes with the same parent:

var nodeIndex = function(element) {
    for (var index = 0, el = element; el = el.previousSibling; ++index);
    return index;
}

Hope that’s helpful…

The function is_category() falls short, since it only indicates whether or not the current page is a category page, but not which one. And get_cat_id(), get_category(), get_the_category(), and the half-dozen other “obviously”-named functions either require that you already know something about the category or provide information about a post.

So, the solution?

if (is_category()) {
   $categoryId = $GLOBALS["cat"];
}

Yes, it’s a global variable…

Fortunately, you know how to fix the problem with the use of the great technique of CSS Sprites. If you don’t, you should. Click the link and learn about it; I will assume that you know what CSS sprites are from here on… Yes, CSS sprites are great, but they are a pain to create manually. Not only you need to stitch the images together but also there will be lots of CSS rules to position the background image correctly. Automation comes to the rescue in the form of the montage command (part of the fantastic ImageMagick collection of image-manipulation software goodness) and some quick script hacking…

Creating the sprite

This little tip will create a sprite off a directory of image files with identical size (in this case, 16×16 icons), each one named something sensible. The objective is to get one image file and a bunch of CSS rules built automatically. First, ensure that you have ImageMagick. In Ubuntu this command will do the trick:

sudo apt-get install imagemagick

There are also downloadable distributions for Windows and Mac. Once you’re ready, open a command prompt and go to the folder where your images live, and run this command:

montage *.png -alpha on -background "#ffffff00" -tile x1 -geometry 16x16 ../sprites.png

This will create a file, sprites.png, in the parent folder (in Windows, make sure that you type “..sprites.png” as the last parameter – notice the backslash), with all the images tiled side-by-side. If you require the images to be tiled top-to-bottom substitute -tile x1 with -tile 1x. And if your images are a different size than 16×16, specify that in the -geometry parameter. And if your source images are not PNGs, replace “*.png” as appropriate. I recommend that you open the sprites.png file in your editor of choice and perform any conversions or optimisations as you see fit. Don’t forget to apply OptiPNG if you use PNG as your final format (why wouldn’t you?) to get a really small final file size. Your sprites file will look a bit like this (icons off the excellent Silk Icons set):

That takes care of the sprite image. Now for the CSS rules.

Auto-generating CSS rules

We’ll be defining a couple of base rules that apply to all elements (note the references to 16px, the size of the icons; adjust as necessary):

.i16:before, .i16 span {
    content: "";
    background-image: url("sprites.png");
    background-repeat: no-repeat;
    padding: 0 0 0 16px;
    margin: 0 0.25em 0 0;
    *zoom: 1;  /* For IE 6 and 7 */
}

.i16block {
    display: block;
    margin: 0 0 0 16px;
    padding: 0 0 0 0.25em;
    position: relative;
    *zoom: 1;  /* For IE 6 and 7 */
}

.i16block span {
    background-image: url("sprites.png");
    background-repeat: no-repeat;
    height: 16px;
    left: -16px;
    min-height: 1em;
    position: absolute;
    top: 0.115em;
    width: 16px;
}

And one more rule per image, which provides the correct background position. The objective is to be able to use classes like this (in this case, to obtain the PDF icon):

<a class="i16 i16pdf" href="example.pdf">PDF link</a>

Or, for links that might span multiple lines and require nice text alignment (or for IE6 support) we need an extra element:

<a class="i16block i16pdf" href="example.pdf"><span></span>PDF link</a>

First, we need to get a list of files in the directory. Each file will produce a rule, and it is important that the contents of the directory haven’t changed since the sprite was created (this is why we placed the sprite in the parent directory). So, drop to the command line and, in Linux, run this:

ls -1 *.png > filelist.txt

Or, in Windows:

dir /b *.png > filelist.txt

Now we only need a quick script to output a bunch of CSS rules. This can be done with your favourite programming language, but here is an example in Python:

rules = ""
f = open('filelist.txt', 'r')
x = 0
for name in f:
    rules = rules + ".i16Mime" + name[0].capitalize() + name[1:] + ":before"
    rules = rules + ", .i16Mime" +  name[0].capitalize() + name[1:]"
    rules = rules + " span {n    background-position: -" + str(x) + "px 50%;n}nn"
    x = x + 16
f.close()
f = open('rules.css', 'w')
f.write(rules)
f.close()

The above code can be saved as a Python script file (say, “myscript.py”) in the same directory as the images, and run from the command-line like so:

python myscript.py

This will generate a new CSS file, “rules.css”, with all the correct rules for all the icons. It should be pretty easy to rewrite the above in your language of choice (PHP, Ruby, Assembler…)   Simple apply to your links the appropriate “i16 i16type” class names and you should be good to go.

BBC: “Euro train booking system shelved”

Is IT still such a headache that these systems are too hard/expensive to implement? I say make the routing, timetable, and booking information freely available and I’ll have a go at making it work…

$.support.outlineCss = function() {
    var $el = $("<div></div>").css("outline", "1px solid black"),
        outlineStyle = $el.appendTo(document.body).css("outline-style");
    $el.remove();
    return outlineStyle == "solid";
}();

Simply test if $.support.outlineCss is true and you’re good to go…

Why? Mostly because the previous setup still required quite a bit of work for me to be happy with it: it looked OK for a visitor, but integrating S9Y into an MVC framework like Zend was somewhat nightmarish, and the admin interface was quite cumbersome even for simple things like adding a post. So I’m setting up a vanilla WordPress installation (apologies about the design; I’m working on it!) which will hopefuly translate into more interesting content and less hassle for me!

I initially set up a ZF site to try and get some more experience with the framework itself, and I am very glad I did. It was a completely overkill application of the technology but I feel I can now use ZF for quite more complex applications: it is very capable and powerful while avoiding the typical “application server” setup that seems so common with larger frameworks. I especially liked the way you can cherry-pick which parts of the framework are of interest, including whether or not the whole MVC stack gets used. For simpler applications something like Cake PHP might still be a faster and simpler way to do things, and I’ll keep to plain-no-frills-PHP for really simple things like prototyping.

As for S9Y, it was a bit of a disappointment. I was looking for a blogging engine that could be plugged into my ZF setup, but since there seem to be none that are happy to do that kind of “blog backend” role only, I settled for something that seemed easy to hack into submission. S9Y does bring its own kitchen sink as well, but it seemed easy to hack. However, two things let it down: convoluted, poorly-documented code, and the templating system.

I won’t say much about the code quality, except that it was at first sight simple but in fact quite messy once you tried to wok out interactions between different parts. The lack of documentation was the really frustrating part, though. So far WordPress seems much better documented and understandable.

The templating system of S9Y is Smarty. There’s nothing wrong with Smarty itself; I guess my problem is with templating systems in general. I know these have their usefulness in some development environments, and of course it is essential to separate as much logic as possible from your markup. However, I don’t think templating systems are a great solution: many times the behaviour of a template is itself complex, and a custom-syntax, crippled language like Smarty is a hindrance.

So there you have the reasons for moving on. Both ZF and S9Y had its fun moments but that setup wasn’t really suitable for this tiny site. Getting rid of the not-invented-here syndrome is also a good thing. In the coming days/weeks I hope to put together a nicer design (I promise I’ll go easy on the orange…) and I now also have fewer excuses to create content more often. So overall I think this was the right decision!