Safari CSS problems

January 12, 2004 11:49 AM

Safari is being a b!tch about correctly rendering basic CSS elements. Specifically, the 'background' attribute simply is not being honoured in any way, shape or form. The kicker is that according to Apple's own specs, Safari does indeed support that attribute; in addition, Googling turns up nothing--a few lists of Safari CSS oddities, but those don't seem to contain anything about the problem I'm seeing. [more inside]

The first time I noticed this was when trying out a messageboard system I'm coding up; in Moz and IE it looks fine, but in Safari it looks terrible. After investigating I found out that it was, for starters anyway, the background element in my BODY tag. Additionally, using it to repeat an image doesn't work (in a table), nor does it work in a small 'color test' page which uses the attribute inside DIV tags.

Even making the simplest possible webpage--HTML tags, and BODY tags, with the inline style for the background color of the BODY, results in nothing. (The problem specifically is that no matter what color I type in, it shows up white)

Anyone else seen something like this? Seems like a rather big gap to have. Oh, also, I've seen the issue on Safari 1.0, 1.1 on OSX 10.2 and 10.3, and on multiple machines as well.

posted by cyrusdogstar to computers & internet (13 comments total)

Have you checked your code against the HTML validator at the w3c?

One site with backgrounds that comes to mind is simplebits.com, which works fine for me in safari. There's a good tutorial to using CSS backgrounds for layout (by Dan, the guy that runs simplebits) here.

The only problem I've had with safari was that it refused to animate background images.
posted by mathowie at 12:02 PM on January 12, 2004

I had the exact same problem and discovered I had specified an incorrect doc type on my page. I don't know why this was the case, but when I changed to doc type to a more appropriate HTML 4.0 transitional (I think that's what I used) the background rendered fine.
posted by jennyb at 12:03 PM on January 12, 2004

Hmm. Should have mentioned that in the original site I made everything XHTML complaint and set the doctype to XHTML 4.0 Transitional (and got it to verify)...didn't make a difference. I will try changing to to plain HTML and see if that makes a difference, though.

I'm also trying to see if it's only inline ones that make a difference, as some other background attributes seem to work OK and those are, as far as I remember, specified with classes instead of the background attribute being inline.
posted by cyrusdogstar at 12:32 PM on January 12, 2004

Hmm, nope and nope...changing it to class instead of inline did not work, and using the HTML instead of XHTML doctype did not work either. :(
posted by cyrusdogstar at 12:37 PM on January 12, 2004

Dude, post a link to the HTML! Many eyes make all bugs shallow, or something like that. Safari renders backgrounds just fine for me... (Although, what's up with :after on elements other than <a> and <p>?)
posted by nicwolff at 1:36 PM on January 12, 2004

Have you tried setting specific background, rather than the generic (and lazy, IMHO) "background" element?

background-image and background-color work fine on Safari for me.
posted by mkultra at 1:51 PM on January 12, 2004

XHTML 4.0 Transitional

I realize that may be a typo, but XHTML 1.1 is the latest flavor of XHTML. HTML is up to 4.01. This could account for your problem.
posted by adamrice at 2:59 PM on January 12, 2004

mkultra: I tried background-color earlier as well, didn't seem to make a difference :/

adamrice: I copied the DTD spec from W3C's own site, I was being less specific than I should've been when I said XHTML 4.0. Sorry!!! ^_^;

The code in question is at:

http://cyrusdogstar.net/plank

The PHP code generating everything (simple echo statements for most of the actual HTML tho) can be found at

https://cyrusdogstar.net/horde/chora/cvs.php/plank

(specifically, header.php and index.php)
posted by cyrusdogstar at 3:48 PM on January 12, 2004

Don't know if this is your problem, but your style element should be within your head element, both of which should be within your html element. Your html element as it stands comes after the style element and you have no opening head tag at all, although you close it.
posted by IshmaelGraves at 4:41 PM on January 12, 2004

OK, I've got it.

You've got

<td style="{ background: url('images/links_bg.gif') repeat-x; }" colspan="2">

Lose the {brackets}.

Aside: this is really crufty code. You could go a long way towards stripping it down and simplifying it. It may not be invalid HTML, but there's really never a reason to mix CSS and FONT tags--and using CSS as an attribute for a FONT tag is really weird.
posted by adamrice at 4:44 PM on January 12, 2004

Hmm, then my CSS book is wrong about having those brackets there :/ but I will give it a try in a bit :) And yes, I know it's hella crufty code--this project has been written over time from when I knew no CSS up till now, when I am starting to learn it slowly. So it's kind of a Frankenstein's Monster of sorts ;)
posted by cyrusdogstar at 5:42 PM on January 12, 2004

That's crazy...removing the brackets (and the quotes I had put in, in desparation, around the background color value) did the trick. And while I could have sworn the curly-brackets were necessary for inline as well as page-level CSS, now that I go back to my CSS reference book I don't see that being used. Must've been looking at someone's source for inspiration and saw them doing it, or something along those lines.

Many thanks, adamrice :) and everyone else too.

Now to go fix the other various problems, many of which I would bet are due to the same thing. Probably time I did that overhaul anyways, heh...
posted by cyrusdogstar at 6:02 PM on January 12, 2004

Just a bit of advice on overhaul: rather than try to make a gradual transition, start afresh by writing new, absolutely barebones HTML with the least markup you can get away with. Then start figuring out the CSS. You may need to add some DIVs to the HTML to help things make sense as you go along. As a rule, it's best to keep your CSS all together in a separate file--use inline CSS very sparingly. Much easier to maintain that way.
posted by adamrice at 6:36 PM on January 12, 2004