The little "RSS" and "iCal" boxes on the DNA Lounge site look good in Firefox but are messed up in Safari:
<LJ-CUT text=" --More--(10%) ">
| Firefox: | Safari: |
 |  |
 |  |
The top pair appears on the calendar pages, and the bottom pair appear on the top-level page. The CSS for those boxes is this:
- .xml_button {
color: #FFF;
background: #F60;
text-decoration: none;
padding: 0 0.5em 0 0.5em;
border: 2px outset #F60;
}
.xml_button:hover { background: #F90; }
.xml_button:active { border-style: inset; }
In case it's not obvious, the problem that I want to fix is that the inner margin ("padding") between the text and the beveled edges of the box is all wrong in Safari. Note that it's wrong in two different ways: it's less bad (but still wrong) in the top right box, because that page has an extra there. Without the , both the top and bottom padding vanishes. With the , only the bottom padding vanishes.
These screen shots are from the latest Safari and Firefox running on OSX, but Linux Firefox behaves the same as Mac Firefox.
How do I make Safari behave like Firefox?
What does MSIE do?
Note:
- Hard-coding pixel heights anywhere is the wrong answer.
- Yes, I know I could just put the orange box in an image like everyone else does.
- Yes, I know that I use <TABLE> and <FONT> all over the place.
- Yes, I know you don't like it.
- Yes, I know I could do all that with CSS.
- Yes, I know that would mean I'd get into heaven.
Update: apparently having FONT and B inside the styled A was what was making Safari render differently from Firefox. Thanks rsdio and vample!
padding: 0 0.5em 0 0.5em;
Um, given that padding is NorthEestSouthWest, don't you already have a padding of 0px at the top and bottom in your CSS definition?
Maybe I'm being dumb but it looks to me as if Safari is the browser rendering correctly.
Alternate thought... What is your line-height defaulting to?
Is that supposed to be a question I would have any way of answering?
Well, assuming you've got control over the CSS, then yes. It's possible it's defaulting to different values on different browsers, in which case you'd need to set the line-height manually along with the font. (Generally a good idea if you're dealing with text in buttons instead of flowing text).
I'd lean towards my first guess though. There's no padding at the top in Safari because you've explicitly defined that there shouldn't be any (0em North, 0em South). Perhaps:
padding: 2px 5px 2px 5px;
would be more appropriate. Or at least display consistently across both browsers.
If I misunderstood your question, I apologize.. :)
You may be onto something with that. One reason I've held off commenting to this post is I have no idea what other CSS (or lack of it) may be affecting the buttons, i.e. stuff defined in parent elements, lack of stuff leading browsers to default, and so on. The fact that the same CSS renders differently in different locations suggests parent voodoo.
Well, you can view source... There's only like 8 lines of CSS in the whole page (but a whole lot of nested tables.)
If I add top/bottom margins, then:
All three browser will look slightly different.
Usually you just have to tweak it until it looks right. Good luck with that.
That's some science right there.
More like job security! And with new browser versions coming out everyday...
it's basically impossible.
Oh and hey there's a new release of java. :(
whimper
Ditto on the science part.
Science means there is a hint of stability.
This is a black art pure and simple.
Disclaimer: I never use MSIE unless it's absolutely required. That said, the buttons look similar to the Safari screenshots, save that the white text doesn't quite as washed out to me. Would you like me to send screenshots?
You know, I bet he's just dying to make sure it looks great in IE. Really.
Go back and reread the entry, it's there. I'm as surprised as you...
On a completely unrelated note, are the tools you use to maintain/display that calendar open-source? If so, what are they written in and where could I find them?
(Sorry not to be of use; my CSS skillz are far from leet.)
It ain't pretty, but it works for me.
Awesome; thank you!
If I end up doing anything to this code to make it more general or parameterizable, would you like diffs? ("No" is a fine answer, of course.)
Sure.
Suggestions:
Try setting 'line-height' for the box.
Try playing with margin instead of / in addition to padding.
To make life with IE easier: http://dean.edwards.name/ie7/ It is a JS libary that only loads in IE and grabs IE by the neck and throttles it into compliance.
Ah - you might also want 'display: block;'
If someone else hasn't solved this by tomorrow I'll play with it when I'm in front of my development systems.
i think the issue is that you're applying the style to an anchor element, which is an inline element by default. Different browsers get all confused when you treat inline elements as boxes. I don't have safari, but since IE/6 seemed to be doing the same thing safari did in your screenshots, i tried this, and it seemed to work:
.xml_button {
display: block;
width: 1.2em;
height: 1em; /* the 1:1.2 ratio seemed to be nice to me */
color: #FFF;
background: #F60;
text-decoration: none;
padding: 0em 0.5em; /* padding shorthand so top-bottom are 0 and sides are 0.5 */
border: 2px outset #F60;
line-height: 1em; /* so the space between lines of text is the height of the box */
vertical-align: center; /* this aligns the characters to the center of the line, in this case the center of the box, dependant on the line-height property. slightly odd css but it works. */
}
one thing i think might be screwing with you is the font size declaration, it's possible that ie and safari allow the font size to affect ems but firefox (incorrectly?) doesn't. this could be completely wrong.
also, i noticed that you're declaring your styles twice, which makes for excess html output. also, your styles declarations are in your body instead of the head, which could possibly cause some browsers to not see it.
Assigning a width instead of letting the enclosed text determine that is completely evil!
but the width is in ems!
if you enlarge the text, the box gets bigger too!
You're assuming a fixed aspect ratio of the enclosed text, which won't hold for other text, or possibly even other fonts.
well, here's the only way i can find to shrink-wrap it
.xml_button {
display: block;
float: left;
color: #FFF;
background: #F60;
text-decoration: none;
padding: 0.2em 0.5em;
border: 2px outset #F60;
}
you'll need to change the float to right for the calendar page, which is annoying.
the :hover/:active pseudo-selectors only work on A tags in IE. don't know if that's a hard requirement for you. if not...
.xml_button {text-decoration: none;}.xml_button b {
color: #FFF;
background: #F60;
display:block;
text-decoration: none;
/* all browsers screw up padding/margin shorthand, differently */
padding-top:0.25em;
padding-left:0.5em;
padding-bottom:0.25em;
padding-right:0.5em;
border:2px outset #F60;
text-align:center;
}
.xml_button b:hover {background: #F90;}
.xml_button b:active {border-style: inset;}
problem with this:
display: block without a width causes it to fill all available horozontal space, and thus sucks. i think there's a way to make shrinkwapped boxes, but it's a huge pain in the ass, if I recall.
unless you float it, but then shit gets really weird.
ah. oops.
This seems to do it:
.xml_button {
color: #FFF;
background: #F60;
text-decoration: none;
vertical-align: top;
padding: 0 0.5em 0 0.5em;
border: 2px outset #F60;
}
Weird...
That prevents the margins from disappearing in Safari, yes. But it pushes the text almost all the way up to the top. (Or the bottom, if I use "bottom", which I guess is what happens when there's an after it.)
"middle" and "text-bottom" yield the original bad behavior in Safari.
This looks less wrong to me:
.xml_button {
color: #FFF;
background: #F60;
text-decoration: none;
padding: 0 0.5em 0 0.5em;
border: 2px outset #F60;
font-size: smaller;
font-weight: bold;
}
...with the FONT and B tags removed completely from the "iCal" text. The padding is a little smaller in Safari, still, but adding 0.1em padding looks ok. Safari probably takes display info from FONT, but not CSS info, so the CSS part of the code thinks the glyphs are larger than they will be when rendered. Or something.
I think that did it -- it was the FONT and B inside the styled A that was causing Safari and Firefox to do different things. Thanks!
IE6 SP1 (Win2k):
The problem, as <lj user="wetzel" /> noted, is that you are trying to style an inline element like a block one, which is only partially possible per the spec, and different browsers implement different levels of support/bugginess for that.
display: blockis wrong because it causes the element to consume all available horizontal space so you can no longer shrink-wrap it. I’d try addingdisplay: table-cell, which gives you a shrink-wrapping element stylable like a block which behaves kind of like an inline element, but not… as you’d expect from a table cell floating free I suppose. I have no access to a Mac (nor a Windows machine), unfortunately, so I don’t know if my suggestion fixes anything, I’m afraid. Firefox, FWIW, renders as intended either way.IE5/6 do not support any values for the
displayproperty other thaninlineandblock, so behaviour should be unaffected.If they are, styling like this seems to work, at least in Win/IE and Win/Ff. You may have to change it to a <button> to get it to show a non-Aqua button in Safari and Mac/Ff though.
.xml_button {background: #f60;
color: white;
border-right: 2px solid #730;
border-bottom: 2px solid #730;
border-top: 2px solid #fb7;
border-left: 2px solid #fb7;
padding: 0 0.5em;
}
I set the colors on each side manually instead of using "outset" or "inset" because I remember Win/IE having trouble with those. That may have been version 5, though, so if it works in enough browsers to keep you happy, doing outset and inset will make things simpler for you. The (tiny) advantage of this is that you can tweak the colors if you're not happy with the 3-D effect on the colors.
Just realized you may want the link to appear in the status bar and the cursor to change to the pointer onMouseOver. The extra CSS you'd need in .xml_button would be:
The status bar change would require JavaScript, which you probably wouldn't be happy doing, though it's pretty simple:
The only problem is that a lot of browsers let the user tell sites not to muck with the status bar, so some people will get a whole bunch of nothing unless they click.
Well, that and the whole "I thought standards were supposed to work the same way everywhere, preventing me from having to use a button when I don't need one" thing.