UDM Blog – Web Accessibility, Development, Marketing and Trends

Keeping you informed on the lastest web development and accessibility information.

Build it right the first time, every time.

I recently had a small project that went absolutely out of control because the client always had the attitude of “if there’s a 5 minute approach, and a 15 minute approach, take the 5 minute approach every time”.

Sure that sounds nice. And everyone wants to save a few dollars on design and development, especially in this economy, but it’s also possible to be penny-wise (as this client was) and pound foolish.

Cliches aside, what this client wanted to do was to integrate several third party applications into a single platform. They wanted an ecommerce engine, social networking engine, forum software, blogging software and a few other common admin apps like CRM and consolidated invoicing system. The problems with integrating the application code were not trivial, but doable. The real problem is that each and every one of these third party apps had their own CSS “concept”. Every one (or at least it seemed like every one) contained their content in a <div> called “wrapper” or “main-content” or similar. While this is a standard technique when you’re building your own corporate site, I have determined that it is a VERY BAD technique when distributing your application to the world.


Because, resolving the conflicts in CSS can be very time consuming, especially if you’re shooting for 100% pixel perfect matches to design documents.

Case and point: This client (who wanted the 5 minute approach) insisted that I should go into the templates and just add inline CSS styles to the right places. That was the “5 minute” approach. I pushed back, and hard, to wrap the pages in a unique ID for each independent system, then re-code their CSS selectors as needed to resolve the major conflicts, then tweak as necessary. (i.e. the 15 minute solution – ok maybe not 15 minutes because these systems had more than one CSS file and some people do really stupid things, but you get the idea). Well, after a lengthy, non-billable time debate, I gave in to the “the client is always right” concept (Note: post on that coming later). And simply did the changes – inline!

Well, it didn’t take long for all those “5 minute” tasks to snow ball. After about 2 hours of “5 minute” changes, we started checking in other browsers and low and behold there were problems. Yes, they were in IE6, but they were still problems. Now the client wanted to fix those “inline” too. At which point I told them that it wasn’t technically possible to do conditional inline styles and was told to do “conditional comments” to make it work. Oh boy. Needless to say, we ended up with a hodge podge of sloppy code that I am totally ashamed to ever be a part of. (Note: A post on clients who know too much is coming soon too :D ). The bottom line in the project is, with the time it took to make all the “5 minute” changes, I could have completed my original process and had time to spare.

Which brings me back to my original point – and a NOTE to third party web application developers. PLEASE PLEASE PLEASE, start encapsulating, prepending and otherwise uniquely identifying your CSS selectors with some type of naming convention so it’s easier to integrate with other systems. Magento – prepend all your selectors with “MAGENTO_” for example. PHPBB, you can do the same “PHPBB_” etc. In my opinion, the only people who should be using common selector names like “content”, “wrapper” or “main” are the site designers and developers. Your “wrapper” id should not conflict with mine, and to be honest, I really shouldn’t, as a developer, have to either re-code your CSS or mine just to add it to my site. Especially if you’re charging for your product.

I hope you found this article helpful. Feel free to comment.

One Response to “Build it right the first time, every time.”

  1. Brianator says:

    Great post! And you’re absolutely right on the CSS. I’ve run into this issue over and over. Glad someone’s speaking up!

Ultimate Dropdown Menu 4.5

UDM is a fully-featured and accessible DHTML dropdown menu, that provides useable content to all browsers - including screenreaders, search-engines, text-only browsers and any web enabled device such as PDAs, iPhones ®, and Blackberrys ®. But having a dropdown menu that makes use of the key benefits of accessibility shouldn't mean compromise, and so UDM includes a sophisticated range of design and usability controls, to give you a tool with unique capabilities:

We'll customise for you!

With our in-depth knowledge we can save you time and money in development.

Get a quote today!

Server-Side Frameworks

UDM is available in a range of server-side frameworks, that generate CSS and scripting on the server, and can bring the total filesize to only 20K!

Recent articles

Initialization trigger element
Defining a trigger element allows the menu script to initialize before window.onload!
The implications of initializing before window.onload
Any scripting you do which is tied into the API "Ready" event (event "010") may need to be checked to make sure it still behaves correctly.
Setting the character-match value for allowed filenames
The file path in the PHP configuration can now contain "\" (backslash) and ":" (colon), for greater compatibility with Windows server paths.
Refreshing the tree after dynamic changes
Using the um.refresh method, you can add or remove items after page load, or populate the menus using AJAX.

Popular extensions

"You are here"
Tells you where you are in the navigation tree.
Load XML
Use an XML document as your menu data source.
Scrolling Menus
Adds up/down scrolling behavior to overlong menus.

See all available extensions


UDM 4 is valid XHTML, and in our judgement, meets the criteria for WAI Triple-A conformance.