Hello,
I’m using a table to try and “format” a mathematical exponent that functions as an input box (basically as superscript) as seen on the bottom of the page (right below the big words “Explore!”):
http://www.myalgebrabook.com/Chapters/Exponential_Functions/rules_of_exponents.php
Might there be some way to make the input box closer to the base of the exponential? I’ve tried valign=“baseline”, but it doesn’t seem to be working.
Thank you,
-Eric
You have specified some padding in the chapters.css
table td, table th {
font-size: 1em;
border: 1px solid #333;
padding: 5px 7px 5px 7px;
}
You could reduce those values.
Also where the rows where the numbers are you could add Valign=top .
Thank you for the quick response!
In my Chapters.css I’ve now changed it to:
table td, table th {
font-size: 1em;
border: 1px solid #333;
padding: 5px 7px 5px 7px;
}
.left_table {
margin-left: 30px;
padding: 0px 0px 0px 0px; !important;
}
(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?
-Eric
You need to set .left_table td and .left_table th so that the padding applies on the table cells themselves, rather than just the table as a whole, which is that you’ve got there.
Thank you both for your help! With your suggestions, it looks way, way better. 
Enjoy the rest of your week…
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.
Even as a table:
<table width=" " class=“left_table” border=“0” cellspacing=“0” cellpadding=“0”>
could just be
<table class=“left_table”>
if you set
.left_table {
border-collapse:collapse;
border:none;
}
does the same thing. Then you only have to say it once in the css instead of every time you use one of those tables.
NOT that I’d use a class with a word like “left” in it, since that’s presentational and doesn’t say what the table is actually OF. Really though, who needs a able for THAT?
<form action="" method="" class="calcForm">
<fieldset>
2
<input type="text" name="box_4" id="box_4" maxlength="3" size="2" />
x 2
<input type="text" name="box_5" id="box_5" maxlength="3" size="2" />
= 2
<input type="text" name="box_6" id="box_6" maxlength="3" size="2" />
<input type="submit" class="submit" value="check"
onclick="triple_check('box_4','box_5','box_6','different_base')"
/>
</fieldset>
</form>
.calcForm fieldset {
padding:1.5em 0 1em;
border:none;
}
.calcForm input {
position:relative;
top:-1em;
}
.calcForm .submit {
top:0;
}
Simple… and no table on something that isn’t tabular data.
Deathshadow,
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:
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:
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.
-Eric
Actaully, what I thought were missing images were your form inputs – my bad. Clicking on the first one did nothing – or more specifically LOOKED like it did nothing because it was under the sidebar.
Lemme first show you what’s going on, and then why it’s happening. Huh… ok, apparently this isn’t the first time I’ve pointed it out.
http://www.cutcodedown.com/for_others/kreut/broken2.jpg
Apparently, I’ve shown you broken before, as there was already a broken.jpg there from months ago:
The cause is actually pretty simple, your sfhover ul is set thus:
.sf-vertical, .sf-vertical li {
width: 10em;
}
While the wrapper/float around it is set thus:
#navigation {
background: #99CCFF;
float: left;
min-height: 810px;
width: 144px;
}
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.
Deathshadow,
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!
Regards,
Eric