HTML and CSS, PHP, Javascript, AJAX, JSON and SQL

• 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?
• Javascript and DOM
  Very nice. This site I built with those techniques. Unfortunately the search-engines cannot deal with it.
• Javascript, DOM and XML
  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.
• HTML and PHP and Javascript
  You will find many sites with Javascript embedded in HTML pages that are largely PHP generated. There is ofcourse nothing against using PHP to -also- generate Javascript. This gives you quite some possibilities in the context of dynamic data driven HTML pages.
• Javascript, DOM and AJAX
  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.
• Javascript, DOM and AJAX and JSON and PHP
  Now that I enjoy! I can have the server respond to a 'under the surface request' by sending Javascript. Yeah!!! This looks like stuff I did many many years ago. I design a language extensible language with C parser and stuff originally to deal with Inter process Communication. Later usages also involved storing algorithms in relational databases and object oriented wide area networking. 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'.
• HTML, Javascript, DOM and AJAX and JSON and PHP and SQL
  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.