Please ignore my previous post on this thread... it's entirely wrong.
See below for more detail.
On Mon, Feb 27, 2012 at 7:01 PM, Ghodmode [EMAIL-REMOVED]> wrote:
> On Mon, Feb 27, 2012 at 1:25 PM, Theresa Jennings
> [EMAIL-REMOVED]> wrote:
>> Here's a sample of the interior pages (the home page is handled a little differently):
>> Style sheets, so you don't have to look for them:
>> In Safari and Chrome (Win and OSX), the white #box juts up against the bottom of the text of the
navigation. There should be a 1px space between the bottom of the nav bar and the top of the white
box, like there is on the home page. It does it perfectly in all the other browsers. If I add extra
margin pixels in the CSS to make the white box go down in Safari and Chrome, then it goes down a
bunch in FF. Bleccch.
>> On the home page, there is no #box rule.
>> I have validated the html (woot!), and the css validates except for a few things having to do
with the smoothmenu and the webkit hacks. I've been futzing with the original code.
>> Can you help me, please? I imagine I'm going to need to hack the CSS a little.
> The short answer:
> Change your selector for the #box (about line 285 in main.css)
> div#wrapper #box
> It looks like you're having a weird specificity problem and you might have even
> stumbled into a bug in Webkit that I haven't seen before.
> In your main stylesheet, the #box is set with a top margin of 8px.
> In your ddsmoothmenu stylesheet the '*' selector is set with margin 0.
> There's no way that the general asterisk selector should override the more
> specific #box selector, but chrome's developer tools show that is exactly what's
I misunderstood what I read in Chrome's developer tools. It's not the asterisk
selector that's overriding the top margin on #box.
In your stylesheet at about line 293, you have a media query that will only be
accepted by webkit browsers. It's overriding your #box top margin with a 1px
top margin. That, along with the -7px bottom margin on the navigation, makes
the #box move up under the bottom of the navigation text.
I agree with Markus Ernst. As this example proves, hacks like these are likely
to cause problems.
Have you seen situations where Firefox and Webkit interpret CSS differently?
I've never heard of any significant differences other than Webkit's support for
newer CSS3 features.
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/