In a previous post about using CSS to style HTML tables, I covered collapsing borders, empty cells, and the inline-table display type. In this post I’ll cover headers and footers, captions, and columns, as well as other points which are good to know when using CSS with tables.
-
-
Modern browsers have the ability to display very complex HTML tables when using CSS to style them. While there are people who frown upon using tables for page layout, there’s no better nor no more flexible way to display tabular data than using tables. While this post is not a tutorial on HTML tables, it will describe some of the intricacies of styling them. The techniques shown here target recent versions of Safari, Firefox, Opera, and IE.
The information in this post was derived the specifications for CSS 2.1 and various versions of HTML (HTML 4, XHTML 2, and HTML 5 are similar enough for this discussion).
-
If you have a form that has items which should be grouped together, using
<fieldset>is a good way to go. It’s essentially a<div>with a predefined border, but what makes it work well is the ability to label the box with a legend. If you want to change its look, however, you must be very careful to test it against multiple browsers. -
A friend was asking about a Firebug-like plugin for Internet Explorer, and that got me thinking about the importance of being able to see how a particular browser is interpreting one’s CSS. While there are many good tools for developing CSS, there’s nothing better than actually trying things on multiple browsers. Fortunately, at least some developer tools are available for Safari, Firefox, and Internet Explorer.
-
My wife brought up a question she was asked about the dotted-line box that shows up around a link when you use the back button to return to a page, like the picture at the right. Is it possible to remove the box? Yes it is, but there are a few things to consider before doing that. -
With many web applications becoming more dependent on JavaScript, much work is being put into improving JavaScript performance. Even though Google’s Chrome uses WebKit (the same engine as Safari), they’re using a different JavaScript engine named V8. Mozilla will be using TraceMonkey in Firefox 3.1, and Safari will be using SquirrelFish Extreme.
All these engines compile down to native code. How much does this affect performance? Taking WebKit as an example, the original SquirrelFish is about 50% faster than Safari 3.1’s JavaScript engine (already 3x the speed of Safari 3.0). Adding native code compilation, as well as other speedups (including a regular expression just-in-time compiler) makes SquirrelFish Extreme more than twice as fast as SquirrelFish.
The engines are playing leap frog, and all seem to be in very active development, so I find it very interesting to follow. I’ve found that SquirrelFish (Moderate, haven’t tried Extreme) works quite well, and I’ve played a few minutes with Chrome and found that to work well, too.
Exciting times in the JavaScript world.
