The change won't be quite so easy.
The "buttons" are actually individual GIFs, two versions each, in pushed and unpushed states.
(BTW, I think the yellow on kahki "pushed" state in your sample GIF doesn't work so well. Probably best to pick another color for the selected button text.)
The "Silicon Investor" logo is rather interesting. It's anti-aliased against butterscotch, but the actual background is white, presumably with transparency set. That is, the logo really IS blue with a yellow fringe. It will only look good if displayed against a butterscotch background.
The butterscotch background isn't part of the GIF, but is supplied as the background color of the table that the logo is embedded in. This introduces a dependency between the GIF and the HTML page source. Change one, and you have to change the other.
The artist apparently drew the logo against a butterscotch background, then changed the background from butterscotch to white, then set white as the transparent color. Why? Beats me.
This might cause "interesting" results in some browsers. An awful lot of faith is given to the browser to lay the logo against the background properly. I would have made the whole banner a GIF, but not including the butterscotch on blue menu to the right, which is dynamic content, or the buttons. That would knock out both the potential browser-dependent rendering problem, as well as the dependency (get tired of the color of the banner, change only the GIF).
Background colors in a GIF are "cheap" (byte-wise), and it wouldn't increase the size of the GIF more than a few bytes if that. At the same time, it would insure consistent rendering of the banner.
"Enter name or symbol", "symbol lookup", and the Portfolio, Inbox, etc. menu to the right are text, as is the selected menu's submenu. So, the muddying of these due to anti-aliasing is a browser-specific and user text-size preference-specific issue. It is the BROWSER that is doing the anti-aliasing in this case. (The anti-aliasing in the logo is static, i.e. part of the GIF).
The top-level menu items are GIFs, though. Kinda goofy, and falls apart if the user changes the font size. That is, if you increase the text size enough, the sub-menus are much larger than the top-level menu items.
The top-level menus could probably be done as text in a table, so that they would scale with the font size as well. This would fit with Bob's idea to pare-down the amount of stuff that has to be sent for each page. You'd lose the "selection" highlighing (notice the vertical lines to the left and right of the selected top-level menu item). You could probably replicate this by turning on the left and right borders of the selected menu item's cell, and making the cell borders the right color. |
