Safari 5 dropping floated box down by 1px for some reason

[Makosuke]

Currently in the final stages of browser testing a new site design, and with the exception of a few remaining tweaks the current iteration looks exactly as expected in FF3-3.6, Safari 3-4, recent Chrome, and nearly perfect apart from a few CSS3 properties not supported in earlier FF, Safari, and Operas, and even IE8.

Pages are relatively simple HTML5 with moderately involved CSS, though I'm not using anything fancy apart from some border-radius, box-shadow, and @font-face things in the stylesheets.

So I wasn't expecting any surprises with Safari 5 today.

Oops. For some reason I'm not so far seeing, Safari 5 is dropping a floated box down by a single pixel relative to the two boxes (also floated) beside it. What's odder still is that all three boxes have -1px top margins to cause them to "erase" the 1px border of the containing box, and despite the 1px downward jog the containing box's border isn't visible.

It does this in both 10.5 with a Software Update installed Safari 5, and 10.6 with a downloaded WebKit nightly from today.

I'm still trying to prune down to a testcase, but does anybody have any off-the-top-of-your-head suggestions as to what might be causing this?

Sample page with the issue:

http://tinderbox.animeworld.com/reviews/windnamedamnesia.html

The issue is on the "See Also" section of the three-column box with blue headers; they should be flush across the top, and will be in any other recent-vintage browser.

The page validates as HTML5, as does the stylesheet, excepting the -moz and -webkit bits.

Here's the un-compressed stylesheet.

What's disconcerting is that IE7 has a VERY similar looking issue on exactly the same box. In its case, of course, it's caused by the fact that, even in a very minimal testcase, if there's a div to the left of a left-floated div in the same containing element, and the floated div has a negative top-margin, it cuts off the top of the div entirely. This obviously isn't anything to do with the same bug, it's just that after spending a half-hour pruning down an IE7 testcase on that bug it's nasty deja vu to see something similar pop up in my browser of choice.

 

[design-is]

Have you tried:

div.relatedanime {
float:right;
width:33%;
}

Seems to work...

/Doug

 

[Makosuke]

Hmm... that does seem to fix it, and probably makes a little more logical sense from a layout perspective, at least in my mind. Thanks for the suggestion--good enough as a fix providing it doesn't cause problems in other browsers. Still mystifying to me why Safari 5 is doing that, though.

I've left the un-changed version up in case anybody else has insight or comments (and I'm still going to prune down to a testcase to see if I can figure out exactly what's going on).

 

[angelwatt]

For what it's worth, the issue is present in Safari 5 for Windows as well, but looked fine in Firefox, Opera, and IE8.

 

[Makosuke]

Ok, after playing around with testcases for a while, I figured out what's going on:

http://users.humboldt.edu/mmarshall/safari5example/safari5-testcase.html

In short, it's not a bug, it's expected behavior due to the fact that <section> is now a fully supported tag, while it isn't in any other browser.

The un-floated containing element in a <section> tag, which now behaves like a block-level object, can have margins that go outside the bounds of this container if it has no border. It doesn't, so the margin sticks out and the top of the <section> tag's (invisible) box gets set based on the top of the un-floated child.

When you then go and float something that's also contained in the <section> tag, and ALSO has a margin set, it gets positioned relative to the top of the containing box, whether or not that box has a border. So, it goes and moves itself above or below the top of the <section> box, appearing to effectively double its margin.


Because I had a <section> tag in there that hadn't, to date, been doing anything but (theoretical, thus far) semantic markup, I hadn't realized this side effect of having a combination of floating and non-floating objects in a nested set of boxes.

It's easy enough to just fix this particular issue and assume the <article> <section> <nav> etc tags I'd included for semantic purposes won't cause any future issues, since this is the only fancy box positioning I'm doing, but now I'm nervous that more issues might crop up in the future as HTML5 support broadens. Maybe I should just delete it all until it's actually going to do something.

Aside, I noticed that Safari 5 now supports the true CSS3 versions of corner-radius and similar properties, no -webkit necessary.

 

[angelwatt]

Something to try, do a CSS reset that includes the new HTML5 tags. It may help some.

 

[design-is]

Good advice angelwatt.

...I noticed that Safari 5 now supports the true CSS3 versions of corner-radius and similar properties, no -webkit necessary.

That's cool to know. At least having the problem to solve let you find something out

/Doug

 

[Makosuke]

Something to try, do a CSS reset that includes the new HTML5 tags. It may help some.

It's probably not a bad idea as a "just in case", although it wouldn't have fixed this particular issue -- is there anything you can do to a <div> to force all contained margins to be relative to its edge other than floating it or giving it a border?

An aside, the other solution I came up with, which probably makes more sense, is to just put the <section> tag on the outside of the containing box, rather than inside--it makes pretty much the same amount of semantic sense, and once it's outside it has no effect on the contained elements.


Now, I don't suppose anybody has any idea how Safari 5 identifies blocks of text to offer "Reader" on? I'd been hoping it used <article>, but no such luck. I've got nearly identical pages--same template, just different text--that gives a Reader option on one and not another, and it's picking only a single sub-head of the article on the ones that are offered. Haven't found anything consistent in the other sites that do or don't show it, either. Weird.

 

[angelwatt]

It's probably not a bad idea as a "just in case", although it wouldn't have fixed this particular issue -- is there anything you can do to a <div> to force all contained margins to be relative to its edge other than floating it or giving it a border?

Perhaps using: div * { position: relative; } but I don't have a test case to try on.

Now, I don't suppose anybody has any idea how Safari 5 identifies blocks of text to offer "Reader" on? I'd been hoping it used <article>, but no such luck. I've got nearly identical pages--same template, just different text--that gives a Reader option on one and not another, and it's picking only a single sub-head of the article on the ones that are offered. Haven't found anything consistent in the other sites that do or don't show it, either. Weird.

I've been wondering that too. I did some searching earlier on a similar topic. This page had the most "comprehensive" discussion that I've come across. I was actually looking for how to change the styles of the Reader. On Windows I think the Reader.html file in C:\Program Files\Safari\Safari.resources\ is one place to do it. I wanted to make the links more apparent because they blend in too much right now. I'll look up the Mac location when I get home.

Reader does decent on my web site except on my blog it chooses the blog's name rather than the post name as the main header. It would be nice to know how to "optimize" your page for Reader. I use the Readability bookmarklet and it does a little better job than Reader and is usable on more pages as well. Reader is based on Readability as is noted in the Acknowledgments for Safari. Studying the code for Readability could give clues as how to optimize.

Arc90 ( Readability )
Copyright © Arc90 Inc. Readability is licensed under the Apache License, Version 2.0.

 

[Makosuke]

I'd found the same topic, angelwatt, and you're right that it looks like understanding how Readability behaves is the best bet.

The file is stored in the Safari package under Resources/Reader.html by the way.

It's disappointing that Reader doesn't use the <article> tag (and its relatives) to decide what to display, as that would be a really effective way to control its presentation. I wonder if getting support for such added to Readability would eventually filter into Reader...