"The change won't be quite so easy."
Yes, it would. I'll repeat this at the end of this message: This concept is exactly what currently exists right now in terms of skeletal structure. I didn't want to get into the "colour" fray initially (it's boring), but this works without any significant change to what already exists. Matters not me anyway, the site structure would be the same with or without. Only the readability and visual presence would change.
"The "buttons" are actually individual GIFs, two versions each, in pushed and unpushed states."
Yes, they are, indeed.
"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."
Huh? I'm well aware of how BG colours work. Cells live quite individually.
"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)."
If this were 1997, some minor parts of that argument would be correct. They did better in 95. Not so much this year.
"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)."
It's browser-rendered text, just as it lives now and has been for years. Absolutely a non-issue.
"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."
We did this in your second sentence already, although in a different context. The consistent size of the gifs ensures the opposite of falling apart — staying together regardless of text size changes.
"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 "
No loss of selection highlighting either way. Again, a moot point. Here's the important point: this concept is in no way structurally different than what exists at this exact current moment. Period. If that works, then — it works. |
