The office where I'm working currently, we have a lot of this
[ <a ...>main</a>
<cfif xyz> | <a ...>users</a></cfif>
| <a ...>documents</a> ]
I imagine a lot of you are already familiar with this sort of thing... Probably most of you don't think much of it, but this sort of thing can be problematic. Primarily what I'm talking about here is the brackets [ ] surrounding the menu and the pipes in between the menu items. This style of display has been pretty popular at a lot of the places I've worked, but then I've also seen a lot of cases where an item in the menu isn't displayed for one reason or another and you get || in the menu, i.e.
Or sometimes an extra pipe on either end like this
And I know a lot of people think "so what?" ... but the point here isn't that it ever happens. No amount of experience or education prevents us from making mistakes. The most brilliant programmers still create typos and contribute code containing seemingly simple mistakes, because whatever we might want to think about our abilities, we're still human. That's why I always cringe when I hear managers berate people for "not testing your code" -- but every manager I've ever met does it. People make mistakes and sometimes that means code going to production with a bug - PERIOD. Their being human doesn't require they be made to feel like crap. If the software going to production is too error prone it's almost always because the company doesn't have a good Quality Assurance (QA) team and/or continue to demand that changes be made at break-neck speeds and refuse to set reasonable deadlines. (In my experience most companies have *NO* QA team, and demand break-neck deadlines in addition, which is a whole other rant.)
No my point about this in particular is that display bugs of this variety are pretty common when the code is formed the way you see it up above. It's the same reason why I wouldn't want a hot-key for "delete" right next to a hot-key for "save". It's about taking simple steps to make some of these common mistakes less common. This is why the framework offers the features to support this:
<div tap:open="[" tap:close="]"
Now this code will produce basically the same menu above, however, it will also ensure that you don't accidentally leave any pipes in or out of conditional statements to produce that display bug up above. It also has some other advantages, for example it involves fewer keystrokes and no duplication (you only enter the pipe character once). And then there are the extended advantages that you can use a combination of the framework's native XSLT features and/or the native internationalization features to easily replace the pipes and brackets for special needs or for branding for clients who would prefer a different look and feel (because we're a way's off from being able to control that text with CSS across the common browsers).
The other thing I'll point out here is that I removed all the character entities. This is of course not a framework issue, but I think its important for people to know. The style attribute white-space:nowrap; takes care of this for us by eliminating the need to use non-breaking spaces to prevent wrapping, which has a number of advantages, not the least of which being that you don't have to type all those entities... although ultimately I wouldn't prefer to place that in an inline style attribute, I would move it out to an external style sheet.
So long story short, the above code is cleaner and less error prone.