Compare referenced URL to Firefox, Opera, and IE/win. Scroll to page base, and inspect pagination block (i.e., "Page 1 (of 12)...") represented by <div class="pages">. Note that the individual page listing is offset from the righthand edge of that block, despite being floated to the right. The contents of that floated child <p> is a simple collection of <a>s and <b>s and separating character entities. Relevant CSS applied to contain <div class="pages"> and its contents: #C p { margin: 10px 10px 0; font-size: 11px; line-height: 1.35; } #C p a:link, #C p a:visited { color: #981C25; font-weight: bold; } #C .pages { clear: both; margin: 20px 10px 0; border: 1px solid #94C5EA; border-width: 1px 0; } #C .pages p { margin: 0; padding: 6px 0; line-height: 1; } #C .pages p.f { float: left; margin-right: 5px; } #C .pages p.l { float: right; word-spacing: -.25em; }/*!sf(2)==w-s(-.25em)*/ #C .pages p a:link, #C .pages p a:visited { font-weight: normal; } #C .pages br { clear: both; } Application of word-spacing as given triggers this layout misfire. I'm baffled as to why, and it's not immediately apparent whether word-spacing is even affected regardless of the additional righthand padding produced. Seen with both Safari 2.0.4 (419.3) and WebKit r18794.
Created attachment 12404 [details] First Cut @ Standalone Issue Demonstration Adding attachment that should visibly demonstrate how Safari compares to other browsers (I checked against Opera 9 and Firefox 2 before upload). What seemed the most relevant css is given within the attached document. Each example includes variants in <p> content in the following order: * anchor/text sequence, one blank line between within markup * anchor/text sequence, no blank line between within markup * anchor-only sequence, one blank line between within markup * anchor-only sequence, no blank line between within markup * text-only sequence, one blank line between within markup * text-only sequence, no blank line between within markup I see marked differences between Safari and other browsers in terms of handling. I also see marked differences between Safari 2.0.4 and WebKit Nightly (r18794). Not much of a reduction yet, but this ought to make the issue more accessible to anyone who wants to help provide (better) test cases.
Confirmed with locally-built debug build of WebKit r18820 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037). I'd say that was a pretty clear reduction!
(In reply to comment #2) > I'd say that was a pretty clear reduction! ...after you know that the blue bars in each group should be the same length.
This is rendering correctly now. Closing.