THOMAS' BUTTON BEAUTIFICATION CRUSADE 1.0

These examples were created to illustrate the ability of CSS to influence the appearance of HTML FORM controls. It was created to illustrate how Freeservers.com could use HTML buttons instead of the images in their interface for contextual HELP buttons.

One serious disadvantage to using images in this context is they require an additional trip to the server to grab the image, or many additional trips if you have browser caching turned off as most developers do. Worse, if you want to add dynamic behaviors such as a highlight when the mouse moves over the buttons, or to simulate the button depressing when a click occurs on it, these are done with image swaps which require more trips to the server... and at the worst possible time from an animation perspective. This process can be excrutiating when you are expecting instantaneous interactions on the part of the interface. So the obvious solution is to use HTML FORM controls in the interface instead of a graphic because they can react instantly to user interaction. The problem was that pre-CSS you couldn't "beautify" the ugly gray buttons. This is a problem no longer...

This was created when IE 4.X was unseating Navigator 4.X as the most highly used browser on the web. Many of the developers at Northsky/About.com (Web Services at least) where unaware of the power of CSS because Navigator 4 didn't implement it very well, and (more importantly to me) didn't allow HTML to be re-flowed once a page had been rendered... except in their <LAYER> tag but don't get me started on layers. Netscape was still thought to be a force and so we were ignoring innovation in order to cater to those poor folks which were still stuck in the past ...such as Universities. Today only the utterly ignorant are unaware of the advantages that Internet Explorer has over Navigator... it's really too bad if you know of Navigator's history. I guess technical innovation like pain, ultimately cannot be ignored.

1. HTML FORM Controls

Notice how fast these are. They take advantage of the IE 4.X+ ability to alert properties of DOM containers AFTER the initial rendering has completed. Buttons can be created in all sizes and even contain line feeds ...but why?


Internet Explorer: "..dynamic, good"
  1. (CSS Inheritance: Fonts primarily) The buttons inherit font-family, font-size, and everything else!
  2. (JavaScript events/Dynamic Redraw) The buttons respond to mouseover and mouseout (background and text color changes requested WITHOUT another hit on the server for a new graphic or page.)
  3. (CSS Inheritance: Button sizing) The buttons honor your size definition (even if the text is too large to fit) .. we'd have to be careful and limit string length or just not declare a button size if its ever possible the button label will exceed the buttons size.
Netscape: "..dynamic, bad"
  1. (CSS Inheritance: Fonts primarily) The buttons inherit font-family, and font-size ok (try it by changing the font-size property in the source for this page), and the size of the button is based on the font properties.
  2. (JavaScript events/Dynamic Redraw) Sorry, too dynamic. (It can't dynamically redraw an HTML page (layers offer some dynamic behavior but they diverge from the W3C standard and are not likely to be supported in subsequent releases of Navigator ... if there ever are any.)
  3. (CSS Inheritance: Button sizing) Size ?!?, what's that? .. the W3C !?! who are they? (Navigator just ignores width and height properties and instead sizes buttons based on the font inside the button, it still looks cooler than the typical button ... but ... well, IE (and the Nav6 preview) do a much more "beautiful" job.

2. IMAGE version

Here is an example of the existing graphical help button found in utility templates... with the addition of two more graphics to allow it to appear to respond to the users mouseover and click events. It highlights when moused over and depresses when clicked. The disadvantage to using this method is the extra time needed to get the images from the server.

Note: Pre-caching the images doesn't work if the browser cache is turned of.. because each additional request of the resource is evaluated by the browser which sees that caching is off and goes back to the server for the latest version. Sorry pre-cache fans. I tested this using Internet Explorer 5 and Navigator 4 by watching my server access logs in real time... when caching was on no hits after the initial image GET occurred, but if caching was off each mouseover resulted in a new GET request which hit the log... wow this is really bad on a JavaScript clock using images.