Here I explain how this site was put together with some information on the usefulness of CSS. And, making things look simple, as usual, is very difficult. Just try to, in a cross-browser friendly way, get pictures to show up with no border and no extra pixels surrounding them.
- one (1) style definition applies to many documents
This is real handy and represents features commonly found in wysiwyg texteditors since MacWord, Interleave and Framemaker. It helps you to create a consistent layout throughout a site's set of documents. Changes made to a particular "element" of the layout are automatically applied to all instances.
- declaring dynamic behavior, as in visual feedback while hovering links
This is nice. I do not need to program dynamics, I can just declare them. Unfortunately different browsers do not agree too much on the effects of such declarations. For instance try and see what happens if you use a surrogate class like span:hover. Place your cursor over this text, do you see the background and foreground colors change? In Mozilla and Netscape they do, but not in MS Internet Explorer (version 6 on XP). And I built sites that also needed to work on the Mac. Then things get worse. If you'd have something working on IE for XP there is of course no guarantee that it would also work on IE for the Mac.
- fluid behavior, in rearranging and scaling objects upon re-sizing the browser
A new religion is emerging: "thou shall not use the HTML TABLE element for the purpose of layouting". Well, I tried. I tried hard to get my desired layout using DIV elements in combination with the FLOAT attribute. I could not get to solutions that on different browsers on different platforms resulted in more or less similar layouts.
It is nice that browsers volunteer to re-arrange my elements when users change the size of the window. Very nice would be if the browser would tell me that it re-arranged my elements, and would tell what their -new- location is. Ancient GUI packages managed to handle such stuff. Why can "modern" tools not do this?
The graphic designers that I sometimes work with ofcourse hate fluid behavior. They want the layout to always look exactly the way they designed it.
- frames and iframes
W3C is going to drop the iframe element, hence expert-advice is to not apply it anymore. You are also advised to not apply the frame element. The reason is that browsers get confused about the history. (Your users get in trouble when clicking the browser native back-button.) Who can now tell me how to build a site from data and menu's such that I do not need to re-program the menu within every data-page?
Very nice. This site I built with those techniques. Unfortunately the search-engines cannot deal with it.
Even nicer. Get a true separation between data and representation and have the latter handled by the browser. Unfortunately no cross-browser and browser-platform compatibility.
- HTML and PHP
After finding a suitable, hence free, development environment I became more and more enthousiastic. PHP is an easy to pick-up language. It allows to make decent Object Oriented solutions. And... you can now, because this is serverside software, stop using frames or iframes.
Keep your HTML pages displayed while, under the surface, exchanging data with the server. But now we still have XML to deal with on the client side. Not as easy as you'd like, parsing that XML and doing something useful with it.
Using AJAX and JSON: be careful to maintain a stateless AND non-blocking interface in order to achieve resilient applications. Why PHP? Well you do need something on the serverside that will respond to the 'under the surface requests'.
Now we have arrived at the present time. With this stuff in my toolbox I think I can build about anything you'd like. It is just a matter of time.
Theo van Eijndhoven, 2007