February 06, 2005

All the world's a list item - or - How I rid my code of all those nasty divs, tables, and other annoying block-level HTML elements and replaced them with nothing but ul, ol, and li elements coupled with standard inline markup like a, p, h1, h2, etc...

k' call me crazy, you won't get an argument from me nor most who know me but I take a certain pride in my brand of crazy... the kind that finds me locked away in my DevNest day in an day out hacking at code until I have proven that what was once thought impossible (or in this case what I'm sure most will see as possible, just pointless) has been cracked wide open and exposed for how simple (or in this case, stupid) it really is.

If the title didn't give it away then let me clue you in to what I am refering to. If you view source on this site you will notice that what was once a series of nested div's coupled with various other inline elements is now nothing but ul, ol, and li elements. Why on earth would I do such a phreakish thing? There is a method to and reason behind my madness so hear me out before you write this off as just another lonely hackers psychotic endeavor into the utterly stupid and pointless. I promise I'll be brief (I gotta get back to my code! ;)

NOTE: I just realized you will need to go to the main page for the site as the archived pages are not updated with the new code base. You can access the main area here.

About a week or two ago it suddenly occured to me that a web design and development method that is now a fairly common CSS hack, that of using ordered and unordered lists to create script free block-level dynamic menus, could fairly easily be used to create an entire site... and in fact that's exactly what I have just proven. But why go to all this effort?

Simple.

Functional programming languages such as Lisp and Scheme have been built around the premise of List processing. Everything's a list, a TODO: (Oh crap, can I freely write that or do I have to pay royalties to Microsoft... they own the patent for those four letters and one symbol, right? ;) a task list if you will. Everything has a known start and stop point (I'm setting aside the fact for now that any number of the items on the task list can have a task list of its own which brings us right into the "bitter gall" that most people define recursion as being) before getting started and when that task list is complete the job is complete. Its really that simple. Much like mathematical... wait, let me start over... EXACTLY like a mathematical function can be thought of given that when you start "processing" the equation you have a known set of "variables" that are set (can you imagine if your Jr. High math teacher suddenly change the value of your variables half way through solving a problem... "What's 5 + 4 + 3?" she would ask and before you got to the third number in the equation she states "oh wait, little Charlie over there has decided he wants to change the 3 to a 7... you don't mind, do you?" Its no wonder I spent so little time in the classroom and so MUCH time in the principals office growing up... I wasn't a big fan of people mucking with my stuff... Little Charlie and I didn't get along all that well ;) :D

Ok, are you ready for my point? Again, it's simple. If we are moving towards a world in which functional languages like Lisp, Scheme, Haskell, or modern day derivatives such as Scheme.NET, F#, or maybe even my LispML project then why not begin to write code in a way that can easily be adapted to these programming styles. Won't this make our code that much easier to port to these new languages and technologies and furthermore, as in this particular case, allow the ability to use simple element structures and predictable element names to represent a hierarchal data structure of an entire web site? Whats even more cool about using this method is that I can use the same code base to:

- view my entire site in an outline view without changing one line of code. Simply change to a different CSS file and *WHAMO* I go from outline view to site view and back again. At the fundamental level I could even use something like Word(TM) or OpenOffice.org(TM?) to create an outline of a site and through a little bit of XSLT magic take that exact outline and immediatelly convert it into a living, breathing web site. Hell, I could even use PowerPoint(TM) if I became desperate enough ;)
- use the same markup to view, process, and reoutput the result of any particular process. Same elements that come in will go right back out, albeit in a reordered state.
- reduce my entire block-level element code base to three elements that always represent either a block of list items or a member of a block of list items leaving only anchor, parapraphs, heading, sup, sub, etc... elements to deal with/handle.
- lose any and all hardcoded structure from within a web page leaving a completely malleable source base instead. Instead of worrying about how I am going to markup a document to be properly represented to the end user I simply write a site outline and then apply a predefined stylesheet to it or allow the end user to apply one that he or she prefers. While one person may prefer to view the site in a text browser like Lynx another may prefer to view it completely structured into a modern-day dynamic view similar to the way I am pushing this site towards. NOTE: Please disregard the mess... the site is obviosly still in a "work-in-progress" state. I actually plan to call the first phase "code complete" either today or tomorrow and then move to test.xsltblog.com for the next phase of development -- integration with Saxon.NET and server-side data processing via both Windows Server 2003 running .NET 1.1.xxxx as well as Mono's CLI runtime implementation -- leaving the main site as is (well, as it will be after its cleaned up a bit more) and moving towards a release-schedule such that you don't have to fumble your way through the site anymore like you have over the past few weeks.

I could go on but I will save you from my continued banter and simply let you decide if this is something meaningful to you or not. If yes, then stay tuned for a follow-up post later in the week that ties this concept together with the early stages of the LispML project, Atom, RSS, blogs in general, and a few other suprises I may or may not have ready for viewing by then.

Until then, enjoy!

BTW... The one thing I thought was going to be the hardest thing to create, that of the calendar on the left hand side, was actually the easiest. I mention this as I found it amazing to discover how easy it was to implement this concept, even at levels that seemed liked they could have been a bit more difficult than others to implement. The fact that I am amazed is actually the amazing part as this concept is nothing new and in fact is second in age only to Fortan in regards to programming language paradigms still in use today. I guess what amazes me is that I haven't seen anybody use this method as a base for HTML web development. I'm not suggesting that I am the first or that this is something that isn't already in heavy practice in some area of the web that I am unaware of... I just haven't seen it yet. If you know of something similar to this please let me know as I would love to chat with anybody else who may have gone through a similar excercise. I think its a neat idea that has promise, especially if there are others who already feel the same way.

Also, please disregard the chaotic state in which the CSS is in right now as it contains a ton of attributes/properties/values that are completely unnecessary and only represents various stages and forms in which this research project took over the last few days of development. Tomorrow I plan to put this into a combination of a LispML/AspectXML source base that can then be processed by Saxon.NET to build a much cleaner and completely dynamic representation of this same code base.