Safari Bug
This site uses a CSS2 pseudo-element and pseudo-class to create three centered bullets before each day of posts. But I don’t want them to appear before the first set of posts on the page, so I use another rule to eliminate them in that case. The CSS looks like this:
#content h2:before {
content: "\2022 \2022 \2022";
text-align: center;
font-weight: bold;
display: block;
margin-bottom: 1.5em;
color: #d0d3da;
font-size: small;
text-shadow: none;
}
#content h2:first-child:before {
content: "";
}
The first rule says that any second level heading inside of anything with an ID of content should have 3 centered light blue-gray bullets put in front of it. There should be no text-shadow applied to the bullets (which are indicated by their HEX equivalents, 2022). The display: block; declaration is important as it is what causes the bullets to be rendered above the heading rather than preceding it on the same line.
The second rule tells the browser to display nothing above any second level headings that are also a first-child.
This works in Mozilloid browsers and in Safari 1.1.1. I believe it also works as intended in Opera. All IE variants ignore it.
After downloading the latest update to Safari, however, I noticed that it was no longer rendering these bullets. I had also played with the template a bit, so I checked things out in Firebird as well. I had indeed created a situation where every instance of a second level heading was also a first-child by inadvertently nesting it inside of a DIV in the template. So the browsers were correctly following the second rule, and not rendering any bullets anywhere.
Once I fixed the template, I noticed the Safari bug. Instead of rendering the bullets above the heading, it renders them next to it, on the same line (click image for a full-sized screen capture):
Safari 1.1.1 (and Firebird) still does everything correctly (click image for a full-sized screen capture):
What appears to be happening is that the latest version of Safari is ignoring the all important display: block;, since it also adds the bottom margin to the heading and centers everything (note that the heading is left-aligned, as intended, in the second screen capture). Curiously, the first heading on the page is centered and has the extra bottom margin, but no bullets.
I’m off to report the bug to Apple...
More Like This
- CSS 102: Borders and Backgrounds
- Hey, I know that guy!
- New Article at Digital Web Magazine
- Safari Bug update
- CSS Validator Broken
By Category
- Apple
- CSS
- Christianity
- NaBloPoMo
- cycling
- design
- digital photography
- digital video
- family
- fitness
- iPod
- meta
- politics
- random
- speaking
- web standards
- writing
Recent Posts
- Liberal Bias
- A key to success in the marketplace?
- 100!
- 100 push ups, week 6, day 3
- 100 push ups, week 6, day 2
Monthly Archives
- October 2008
- July 2008
- June 2008
- April 2008
- March 2008
- January 2008
- December 2007
- August 2007
- December 2006
- November 2006
- September 2006
- July 2006
- March 2006
- February 2006
- October 2005
- September 2005
- August 2005
- July 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
- January 2004
- December 2003
- November 2003
- March 2000-August 2003
Comments
Hi Mark, have you noticed any other instances of display: block being ignored? I (and I am sure many other 10.2x users) am still running an older version of Safari and can’t check this stuff. It is a bit of a worry because I use display: block all over the place for CSS based menus.
Posted by: gavin on February 8, 2004 07:32 PM
Since I don’t have a net connection at home for my Mac, I usually surf at work on an XP machine. I have to say that the Safari screenshots look incredible compared to the render I get here on this crappy Windows system. Not that the site looks bad, but Safari’s text rendering is infinitely better.
Posted by: Brandon on February 9, 2004 09:14 AM
Gavin:
I haven’t noticed any other display: block; issues, only within the generated content. For instance in my Taming Lists article I use display: block; in the final example, and it still renders fine:
http://www.alistapart.com/articles/taminglists/
If you have a site or two that you’d like me to look at, give me the URLs and I’ll let you know.
Posted by: Mark Newhouse on February 10, 2004 08:36 AM
“If you have a site or two that you’d like me to look at, give me the URLs and I’ll let you know.”
Thanks for that — though now I may be installing the “black cat” sooner rather than later. I will then — somehow — have to be able to check in older versions of Safari.
It never ends…
Posted by: gavin on February 12, 2004 07:17 PM
Displays as intended in Opera 7.23 on WinXP.
Posted by: Mark Krawec on March 3, 2004 07:44 AM
Good to hear, Mark.
Posted by: Mark Newhouse on March 9, 2004 10:24 AM
Just FYI, the bug still occurs in Safari 1.2.1 (v125.1) that was bundled in with the OS X 10.3.3 update yesterday.
Posted by: Mark McLaughlin on March 16, 2004 12:40 PM
This is totally unrelated, but I just updated to 10.3 friday and today when I went to
http://www.complexspiral.com/publications/containing-floats/
I saw that safari now displays everything in between pre tags as non-sensical garbage. Did Safari just take a big step backwards?
Posted by: Erik Porter on March 22, 2004 12:57 PM
Hmm. Just checked that page, and I didn’t notice anything amiss. I just checked in Safari 1.2.1 from the 10.3.3 upgrade. Is that what you are using Erik?
Posted by: Mark Newhouse on March 22, 2004 04:07 PM
Odd. I’m using 1.2.1 on 10.3.3 and here’s what I see.
http://www.erik-porter.com/safari/pre-bug.gif
as opposed to this
http://www.erik-porter.com/safari/pre-bug2.gif
Also, on this page:
http://www.devguru.com/Technologies/xhtml/quickref/xhtml_pre.html
the green Output without style code is garbled, but the purple code is fine.
http://www.erik-porter.com/safari/pre-bug3.gif
Posted by: Erik Porter on March 23, 2004 08:21 AM
Ok. All is well. Software update just updated Java 1.4.2 and Quicktime and somehow that fixed everything.
weird.
Posted by: Erik Porter on March 23, 2004 08:35 AM
Hmm. I wonder what those things had to do with the rendering engine of Safari?
Anyway, glad to hear things cleared up for you.
Posted by: Mark Newhouse on March 23, 2004 08:37 AM