I've been searching for answers, but unfortunately still havn't found one the right one..
I'm creating buttons using images and the button itself looks good in ALL browsers..
The thing is though that the text is placed differently (vertically) depending on which browser you are viewing it from. I've tried applying both line-height, padding/margin, top/bottom and several other attributes, but without success..
Isn't there a way (with CSS) to place the text correctly in all browsers? (Opera, Firefox, Chrome, Safari)... Don't worry about Internet Explorer - I'll apply some speciel CSS for this!
I've put up an example here to play around with: http://jsfiddle.net/GydjP/1/
button::-moz-focus-inner {border:0;padding:0;margin:0;}
and adding Line-height to the buttons is apparently the best solution I can find for my buttons so far.. It doesnt work in very old versions of Firefox + Chrome though
Related
i have spent 3 days trying to figure out this issue and cannot come up with a viable solution.
ive even tried using javascript to load stylesheets tailored to each browser, but even that didnt work.
my problem is my horizontal menu (http://mydomainsample.com/fire_rebuild) is displaying perfectly fine i n chrome, but when i load in safari or firefox, the child menu is way out of position. oddly enough IE(9) is closer to being correct than the other two, but even thats not quite correct.
i have played with the stylesheet trying to figure it out, but when i get it right in fff, safari, or ie its screwed up in chrome.
i cant seem to find a solution that works in all browsers.
can someone please help me find a solution to this?
ive tried using a different menu but this one looks the best and any vertical drops ive used give me z-index problems between the menu and the slideshow that i cant seem to fix.
I do not think src is an optional attribute for link tags. Replace it with hrefs like the first two. When I look at the page in firefox, I do not see two files above being imported.
The order of the files in those link tags are very important as well.
href="stylesheets/reset.css"
href="stylesheets/coda-slider-2.0.css"
I do not know if you already have them but firefox and chrome has the firebug and web developer plugins that makes life easier.
jQuery has been updated to v1.7.2; I would update all your plugins & see if that helps.
First of all, remove all the javascript you applied to match for different browsers.
Then Remove the width:750px; and left: 548px; on style.css line 83 (ul#nav li:hover > ul)
Hope this will solve your problem
Also your page width is 1220px. Stick with the 960px width in order to compatible with small screen sizes.
I'm using css gradients and padding to simulate buttons around an anchor tag. The problem I am running into is that firefox seems to make the button 3 pixels larger. 1 pixel on top and 2 on bottom. This seems to happen with not only the example i posted but everywhere on the page where i use the padding. I put up and example at http://wemw.net/example.php. In firefox the button top and bottom line up perfectly with the search box, but in chrome as i said its off by 1 pixel on top and 2 on bottom. I am using the w3 transitional(tried strict as well) doctype and a css reset. In the reset all anchor tags are set to padding: 0, so I'm confused as to why this extra padding is being added. Is there a workaround to this or is it just something you have to deal with when working with gecko and webkit browsers?
EDIT: So I logged over to windows and it is appearing the same in both browsers now. I'm assuming it is OS specific problems? Since no where near as many people use linux I'm going to change the padding to make it work, but in the interest of consistency can anyone offer a solution for cross-os cross-browser solutions? I do not own a mac and cannot easily test it there, but if windows/linux can have problems with the same versions of the same browsers is it safe to assume mac could also have issues i am unaware of?
It's not the padding on the anchor tag, it's the size of the text box that is inconsistent. <input> elements always caused such problems for me too, and I always found it extremely tedious to align them together nicely (you haven't yet seen it in IE8, have you?). I think that the easiest cross-browser solution here would be to remove the border from the text box and use a background image instead (or better yet, a background image on the element containing the text box) properly aligned with the button.
So, I have written out a site in HTML and CSS, and all looked fine and dandy in Safari, Chrome, OmniWeb... even Opera. Then I tested in Firefox and Camino (which I believe uses the same rendering engine as Firefox) and was unpleasantly surprised: some of the positioning of my divs was off - noticeably off - by at least 5 pixels. While that might not seem like a whole lot, I use divs to put borders around things that I would otherwise have difficulty with putting borders around (jquery image gallery, for example), so 5 pixels matters quite a bit.
My question is this - what other quirks does Firefox's rendering engine put in, and how can I get around them? Are there special properties I need to add to my CSS in order to make it behave the same for Firefox/Camino?
Thanks in advance for the help!
You should look into using a css reset, this will give you a blank slate and will for the most part normalize how browsers render the box model.
I recommend http://developer.yahoo.com/yui/reset/
This is going to be a vague and obscure question, which is probably due to the fact that even using IE Web Developer, I have no idea what is going on.
I have a utility which I am working on. It's mostly JavaScript, and it has a small floating DIV user interface that shows up on a page. So far, standard stuff. The problem is the background color of some DIVs in the UI. The colors are assigned by CSS, and (tired refrain:) it looks fine in Firefox, Chrome, and Opera, but of course IE is being difficult.
The background does not show up in IE in quirks mode or IE7 mode, but it does in IE8 mode. For the life of me, I can't seem to figure out why IE7 isn't showing the background.
The page you can see the offending code is here: Log Hound Demo. Floating DIV is in the upper-right-hand corner - click the "V" to open it up.
Looking at that page in IE and then in [any other browser on the planet] will show you the missing background colors easily enough. I swear, even Lynx renders it better... ahem. The offending DIV IDs are lhPlateHead, lhPlateCtrlPanel,lhPlateTagPanel - easy to find with Firebug at least. They should be heeding the .lhPlateColor class with a background color of #DFEAF8, but that color is never applied.
With IE web developer up, I tried removing the CSS classes and re-adding them. I tried every combination of browser and document mode - again, only IE8 browser mode in IE8 document mode had the background colors working.
If anyone is bored enough to take a look and figure something out, I'd be much obliged.
Well - I finally figured it out, and as far as I'm concerned, this is another reason IE will always suck.
The circumstances of the problem are:
You are creating an element programatically:
myelmt = document.createElement('DIV')
You are setting the styles of that element programatically:
myelmt.setAttribute('class', 'myclass');
You are then adding that element programatically to the DOM:
body.appendChild(myelmt);
You are using IE.
IE hates you.
In cases such as this, IE8 will honour the "myclass" css and style the element properly when it is added to the DOM. IE7 and I'm guessing below will blow off the CSS styling and leave you thinking that employment at McDonald's is probably a whole lot less stressful.
To recap for the impatient:
Works in IE8 and EVERY OTHER BROWSER ON THE PLANET
var myelmt= document.createElement('DIV');
myelmt.setAttribute('class', 'myclass');
body.appendChild(myelmt);
Works in IE7 and below:
var myelmt= document.createElement('DIV');
var attr = document.createAttribute('class');
attr.value = 'myclass';
myelmt.setAttributeNode(attr);
body.appendChild(myelmt);
If someone can expound on exactly why this is a problem for IE7, feel free as I revel in the minutiae. Otherwise, just remember that it's all fun and games until someone loses an object reference.
Try adding zoom:1 to whatever element the background color doesn't work on.
I believe the issue has to do with how IE paints table cells. Try putting in a IE only CSS rule that applies the background color explicitly to TD's. Like this:
.lhWarnMsg .logMsg td
{
* background-color: #fbffbf;
}
Hopefully that will work for you.
http://betawww.helpcurenow.org/media/press/
You'll see I have used spans within an anchor, with the span.hover-description set to display:none; by default, and on a:hover that span is set to display block and absolutely positioned to create a tool-tip effect when hovering over the name and email of the "For Immediate Release" contact names.
Everything looks as desired in Firefox, but Chrome reveals my unknown blunder somewhere.
Any help on what's the problem that is causing Chrome to not display like Firefox?
Incidentally, Explorer shows the tool tip as expected, although I'm getting a funky bottom margin issue below the names, and Safari has the same issue as Chrome (must be a webkit rendering setting that I need to accommodate for).
OK, I figured it out. Since I'm using a pretty complex nesting structure to accomplish the CSS tool-tips, I overlooked the fact that I had actually nested a p tag within a p, and of course that is a no-no.
Firefox is really friendly to a lot of validation errors, but Chrome and Safari seem to be much more strict.
In the end I changed the p's to span elements and all is well across browsers.