with a bit of history Thoughts on XHTML
Note! While it still makes a lot of sense, this rant IS over 4 years old. Keep that in mind when reading it ;)
To start out with a bit of a disclaimer; this is a bit of a rant of how I see things. It is my opinion, based on personal experience and insight (both as a hobby as well as a profession). I might however have some of my facts wrong, and you've got the right to disagree or point and laugh at my ignorance.
The net used to be a really (visually) ugly place, since it was developed by technicians with no idea of aesthetics (a law of nature with few exceptions). Along the way regular people were allowed access and eventually the Internet was born. At some point sgml spawned html and shortly after the table tag was introduced. The more visually minded people discovered that it was just too easy to use it to transform a raw design into html, almost exactly to the pixel. The word spread and it became a bit of an accepted standard (so to speak). Unlike its early years the web became a beautiful place to look upon and many became fascinated by it. In its own strange way, it is fortunate this all happened as it did.
Times changed, and somewhere along the way Netscape 4 grew old, became obsolete and died. The times of painful crossbrowser torture were over, and people rejoiced at the dawn of the long awaited IE-only era.
now what A short intro
Now, though it may seem unlikely to happen soon, the waiting is for the end of this era, and the coming of the new era of standards and cross-media browsing. To get them out of the way, I'd first like to elaborate on the differences between some things I'm going to rant about:
- Theory and Reality
- CSS is truly capable of almost anything. It has its own limits, but the more important limits are how well you and others you have to work with master it. In theory it's easy and quick. In reality you might sometimes have to take a few steps back to explain, or learn something new yourself, and in the end you might have lost time compared to doing it the old way. It'll end up being faster though.
- Skin and Redesign
- A skin is something completely different than a redesign. CSS is good for skinning one applicaton to make it usable on several devices or to enhance usability by serving optional differences in a layout (like font sizes). A redesign on the other hand will often mean a change in page structure, introducing new things and leaving others out completely, and this change of structure will be reflected in your markup. You cannot blame CSS for not being able to handle such a redesign by itself, since the markup changed to begin with.
- What you see is not what you get
- When starting out with CSS, a lot of people just change the TD's to DIV's and force them into their position and dimensions like one would to with table cells. When using CSS though, this should be avoided. The looks of an element do not directly imply that it needs to have the fysical dimensions for it; the effect could originate from somewhere else, like a containing parent.
Because of the current IE dominance there is more CSS we cannot use than CSS that we can use. This often makes it harder to css a design than it could have been if everything would work as described in the CSS specs. This is however a consequence of IE's dominance, and not a shortcomming of CSS.
In my opinion it is also a fact that people are actually making it harder on themselves by calling perfectly usable and proper CSS "hacks", and to continue to just treat DIVs as alternative TDs. CSS just doens't work like tables do, and you'll have to learn new ways of implementing a design.
separating stuff Application layers
As mentioned above, the waiting is for the end of this IE-only era, not only to make the life of developers easier, but also that of the user. A client-side application should (in theory) consist of several separate application layers, which in turn either serve a more technical purpose, or help the user by enhancing the usability. The application layers I'd like to discuss are:
- Structure
- Structure defines how data and content are combined to form a whole. This is accomplished by choosing the most appropriate HTML tag to describe each bit of data or content. This is why you can't just put everything in a tablecell. Doing markup in XHTML this doesn't really differ anymore from how you'd do this in XML, except for the predefined tags you are limited to.
- Presentation
- The presentation layer should fully take care of how your structured document should look. Colors, backgrounds, but also the icons you might use in front of links. CSS can do all of this. Image tags <img /> should not be considered for anything (!) other than pictures that reside in you content, which should (obviously) also be there in a completely different layout.
- Behaviour
- The behaviour layer adds extra options or tools for the user, and defines ways for the user to interact with the application. Generally this is done with a clientside scripting language like javascript, although CSS too is capable of defining behaviour (although only to a limited extent).
Working with these separate layers is one step in the right direction. The next one is to combine them into one application, for which there are a few more things to consider:
- Presentation and behaviour are not always present. One or both of these layers may be unavailable in the user's software.
- Support for certain features of any layer might be limited in the user's software.
- Presentation and behavior are supportive layers.
Especially the last point is of importance when considering accessibility. The bare bones structure itself should be viewable with any device (and it usually is). The other two layers should only add features to this, they should not be a mandatory layer for the application to be used. This is often were things go wrong. Even DHTML scrollbars can be built in such a way that a page becomes a long scrolling one when script is turned off (or not available), but generally they aren't.
Apart from that a user on a slow connection might also choose to disable images. This should also be considered when implementing the presentation layer, for instance by ensuring that a background color (instead of the image) keeps content readable.
the more the merrier Usability and Accessibility
In a way the part above about setting up application layers to me defines accessibility. The better the application is constructed, the more devices will be able to successfully request and show information to the user.
Usability on the other hand is something you add in the form of interactive tools, or something simply "is" (or is not) because of you choice in interface design. A lot of these things can be done using presentation or behaviour (or a combo), but the structure has to be a reliable one to build on.
wrapping it up Finally
Theory is not reality, and so in reality you might have to make a few choices that are bad for your application, but good for the deadline and stresslevels. The limits of your knowledge as well as the limits of software, as opposed to what the standards say should have happened, will force you to make these choices. But with the rise of real browsers and other devices that support the above way of development it's becoming more and more apparent that it IS the right way to go.