(at least on my local version) so that the left_table class comes after the table td, table th statement, and I’m still not seeing a change. Is there an extra step that I need to “override” my initial table td, table th?
I’m just stuck wondering what makes ANY of your tables be… well… tables… Of course the broken layout (due to mixing px and em’s in a willy-nilly fashion) resulting in your sidebar on the left overlapping the content, etc, etc…
One big tip – if every element inside a tag is getting the SAME class, NONE of them should have classes on them; hence that ‘no_border’ class just being pointless bloat. for the life of me I can’t figure out what you are trying to do (the missing images probably don’t help on that), but whatever it is I suspect it’s all broken/flawed methodology; dimes to dollars you’re over-complicating something simple.
Thank you for the CSS tips…I agree that a table isn’t the most appropriate way to do things and I’ll give your code a shot. However, in the meantime, --and more disconcerting for me-- are the comments that you made:
Missing images (yikes!)
Overlapping sidebar (ugh!)
I haven’t done “full-testing” of my site as I’m furiously working on site content locally on my computer (I almost didn’t even investigate the exponential issue as described above but a few people had mentioned it so I thought that I’d just fix it) though plan on cross-browser testing later this summer, in addition to fixing all of the bloat. However, I have looked at it using Internet Explore, Safari, and Firefox, and didn’t notice the issues that you were talking about.
So…if it’s not too much trouble:
Would you mind telling me what image isn’t there? (This couldn’t be related to the browser, could it?)
And, don’t shoot me, but why is it bad to mix px and em? Why would that cause the sidebar issue? And, finally, is one better than the other?
I look forward to hearing your thoughts. And if there are other CSS issues, which I’m sure there are, I’ll get to them when I finish the rest of the content this summer.
the ENTIRE reason to use EM is that it will auto-enlarge for users of different font metrics or those who change the default size in their browser – like me. I have my computer set to 120dpi, aka “windows large fonts” or going back to the 90’s “8514”, so that ALL user interface elements are rendered 25% larger… a setting I’ve used since it was introduced with Windows 3.0 – At the time I used it to run one resolution higher than most people found comfortable (1024x768 on a 14" CRT, 1600x1200 on a 19" CRT, etc) – helped give more pixels to each character while keeping them the same size at the ‘normal’ resolutions most people would have run. Still in use today, and Microsoft is pushing for it to get more use which is why it’s a LOT easier a setting to get at in Windows 7. (since it’s the FIRST thing that comes up in control panel -> display, though now it’s Small/100% Medium/125% and Larger/150% — the first two corresponding to the old 96 and 120 dpi small/large settings).
You’ve declared 90% over the entire body, that’s the same as saying 14.4 on 96 dpi/small font machines (rounds off to 14), so that 10em is 140px, fitting the 144 wrapper… but at 120dpi that’s 18px (exactly 18 in fact), so now the content is declared as 180px wide while you’ve got a 144px container.
When you use EM as a width on a child element (like that UL), you need to use EM on it’s container (#navigation) if you want it to fit when the system metric changes.
It’s why as a rule of thumb fixed width layouts and declaring widths in PX is filled with problems from an accessibility standpoint. That said, a better solution would be not to declare a width on that menu at all; letting it expand to fit the parent container (#navigation) though that might make the right-side flyouts harder to position. It’s very easy to go overboard declaring widths on elements that frankly, don’t NEED widths.
When you use EM – which is a good thing because it increases accessibility – you HAVE to keep in mind that they get bigger automatically while px does not… which seems complex the first few times you deal with it, but ends up very simple in the long run.
Thank you for clearing up the difference between the two! And, yes, you did actually point this out to me many months ago…but you also pointed out many, many other issues in that particular email that were more of a priority at the time and I fear that the zooming issue had gotten lost in the shuffle since I couldn’t see it on the browsers that I had checked out.
Anyway, as I mentioned in a previous post, I’m slogging away at content right now and will hit all remaining CSS issues (including the very important Accessibility issue that I know has its own set of things to think about) as well as try to clean up the bloat in the site this summer. Of course, it would have been better to do it right the first time, but for us first-timers, it’s a trial/error sort of process.
At that point, I’ll revisit this email and see if the seemingly quick fix --which makes total sense, by the way-- doesn’t throw something else out of whack.
And until then…I’ll swear of px and tables that aren’t really tables!