I have a menu that has text-shadow applied to it, so that it blurres the links. It works as expected, except that in IE10 it completely hides the links.
Only when hovering over links they are revealed, because on hover text-shadow is removed.
Here is the applied code:
text-shadow: 0px 0px 3px #fff;
Also, here is the link...the menu is positioned bottom left part of the screen.
http://madebym.net/test/ractiv/index.html
There's a few possible reasons for this problem.
IE does not display text shadows the same as most brosers: IE shadows are more opaque for some reason. Then you would have to check the browser.
IE <=9:
filter:progid:DXImageTransform.Microsoft.DropShadow(color=#000000, offX=1, offY=1);
(Details: http://msdn.microsoft.com/en-us/library/ms532985%28v=vs.85%29.aspx)
(There also seems to be a filter named "blur" that might be more what you need. It's mentioned on the page.)
IE 10+:
text-shadow: 0px 0px 3px rgba(100%,100%,100%,0.8);
(Slightly transparent shadow to offset IE's shadow opacity. You could also reduce the size of the shadow and see what it does.)
Other browsers:
text-shadow: 0px 0px 3px #fff;
(Your normal code.)
The reason could also be that you made a shadow using an IE filter for previous IE versions, but forgot to NOT make it apply to IE 10, which supports normal shadows, resulting in the two effects stacking.
Sounds unlikely, but maybe there's a default value difference somewhere that affects this. Do you use a CSS reset?
Use This text-shadow: 0px 0px 3px 1px rgba(255,255,255,0.5).
It works here on IE10, Can you open the developer tools (F12) and make sure the rendering and document mode is set to IE10 and IE10 standards mode?
dstorey and Mark already pointed you to what is probably causing your problem. More specifically, you can search for a
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
or similar tag in the
<head>
section of your document and delete or conditional-comment it for IE versions lower than 10, since in case it is present it will prevent your document from rendering properly in IE 10.
Related
Maybe someone out there can fill me in on whether I've encountered an odd edge case Safari bug or there was something that I missed in my CSS.
Basically, the landing page of my site (http://www.seanmichael.me/test/kodiak/) is not showing the set background (it's just showing a white background) only in Safari (6.0.5). I was surprised by this because I have used similar full-page background images with this type of css and never encountered this issue. The code is set on the body element as seen below:
body {
background: url("img/landing-bg.jpg") #2c5277 no-repeat center center fixed;
-webkit-background-size: cover;
-moz-background-size: cover;
-o-background-size: cover;
background-size: cover;
}
I linted my css and had no errors, so I spent substantial time messing around with the CSS in dev tools to find a solution. Oddly enough, the edit that fixed my issue was setting a background-color property on the html element. I'm happy it works, but am still confused as to why this might happen. Please let me know if you have an explanation.
Thank You,
Sean
After having the same issue occur on another client site, I was able to figure out what the issue is. I'm still not sure if this is a bug in Safari, but the problem is as follows:
When using the _'s (underscores) WordPress starter theme and Modernizr together, the default css in the theme is putting a clearfix on the html element itself (not on purpose). For some reason setting the pseudo elements (before and after) of the html element in Safari to display table causes the html element itself to overlay everything on the page (which is set to white by default). You can check out the ticket here https://github.com/Automattic/_s/issues/212 on the github page for the _'s theme.
My problem was already described here:
http://the-dees.webs.com/iepp1/45-input-padding.html
but no solution or work-around was provided.
Problem: if you have input text with padding in IE8, the initial position of text and the blinking cursor is invalid (it's rendered at the top of the input). Once you start typing, text and cursor move to the proper position (the middle of the input).
Input is only styled with following:
input {
padding: 10px 0;
}
I've found a workaround, which is unacceptable for me. Namely, if I remove left or right padding (or both), everything looks fine:
input {
padding-top: 10px;
padding-bottom: 10px;
}
However, if you don't declare padding-left or padding-right to be zero, then IE may give a weird default value (in my case it was 1px)
Interestingly, this problem appears only in plain IE8 and in IE9 with IE8 document mode. It does not appear in IE7, IE9, IE10 or IE10 with IE8 document mode.
How can this problem be solved?
Setting the line-height property on input will fix the position of the text and caret.
Is there a line-height discrepancy in Firefox that would be affecting the line-height on this input element? http://cure.org/curekids/
You'll see in the signup form right in the middle of the page that my email a dress input field has the text vertically aligned very awkward, whereas in Chrome, Safari and IE (gasp) all is well.
What's causing this inconsistency in Firefox and how should I remedy it?
All browsers have a default style for many elements, and they are not at all consistent, so the best approach to it is using a CSS Reset style sheet to remove all those default CSS rules.
The only "disadvantage" is that after including a reset you may have to add a couple more of rules, as you might have used some of the browser's defaults styles, like heading sizes for example.
I have been using the YUI 3 CSS Reset and it works really well, but be sure of including it before your CSS.
on sponsor.css you have div#sponsor-notify-me input#email-field there this padding:10px 10px 0; just change this to padding:0 10px 0; and also change the height:32px; to height:42px;
Firefox and Webkit based browsers treat line-height differently and this affects input elements. One work-around that worked for me was to use the same values for line-height and height in the css properties for each element.
e.g.
#button{
vertical-align: middle;
line-height: 60px;
height: 60px; /* Firefox needs this to be equal to height */
}
You could take a look at this issue as well:
Font height changes between Firefox & Webkit browsers?
I'm experiencing what appears to be a bug in WebKit's rendering of floating elements' width when they have margins.
The following renders as one would expect in Firefox (3.6) and WebKit (Chromium 5.0):
<div style="width: 100%; background-color: green;">
<div style="background-color: red; float: left; width: 50%;">n</div>
<div style="background-color: red; float: left; width: 50%;">n</div>
<div style="clear: both;"></div>
</div>
That is to say, as a completely red box, with no green background showing.
Now try this:
<div style="width: 100%; background-color: green;">
<div style="background-color: red; float: left; width: 40%; margin-left: 10%;">n</div>
<div style="background-color: red; float: left; width: 50%;">n</div>
<div style="clear: both;"></div>
</div>
What is expected is the same as as before, except for 10% of the box on the left-hand side to be left green. This is what is seen on Firefox.
However, on WebKit browsers, one pixel of green is left on the right-hand side of the box: the floating elements no longer completely fill it up.
The problem appears to compound when more floats and margins are used, leaving a larger amount not filed up.
Is this a bug? A rounding error? It's certainly not what I expected. And more importantly, what can I do to get around it?
EDIT: After much searching I found that it is a reported bug; probably a rounding error as suspected: https://bugs.webkit.org/show_bug.cgi?id=5531
My most important question still stands: is there any way around the bug?
I suspect there is no magic workaround for this. Browsers interpret sizes in a mathematically different way. There is another question slightly related to this here, which is the particular problem I encountered. There is wider infomation here. I once read a great article explaining the problem very exactly, but I lost the bookmark. I'll try and find it again so I can post it here.
Essentially, different browsers round decimal pixel values differently. So, the short answer is you will never get an exact cross-browser solution as long as this differences exist. The particular problem I had was the one described in my first link: even without using percentage values (fixed pixel sizes), I encountered 2 "sides" between browsers, in which the vertical alignment of some elements would be different: Firefox and Internet Explorer, on the one side, and Opera, Chrome and Safari on the other.
Yet, this depended on the exact values of line-height and font-size I used, so sometimes I would get differences even between Firefox and IE, or other combination. Without using conditional CSS, I could only reduce the problem to those 2 groups, and then used conditional CSS to adjust the margins in Opera and Chrome.
So, to sum it up, as far as I know, I'm afraid you'll have to use conditional CSS. Cheers!
Perhaps something like this instead?
<div style="width: 100%;">
<div style="background-color: green; float: left; width: 10%;"></div>
<div style="background-color: red; float: left; width: 40%;">n</div>
<div style="background-color: red; float: left; width: 50%;">n</div>
<div style="clear: both;"></div>
</div>
I'm trying to achieve cross-browser consistency for my website.
It's about this page: http://www[insert-dot-here]geld[insert-dash-here]surfen[insert-dot-here]nl/uitbetalingen.html (please note that I prefer this URL not to be made crawlable for seo-bots)
If you view this page in IE, Firefox or Opera, everything is fine, but in Chrome and Safari the tables are a little out of line (as you'll probably clearly notice).
What seems to be the problem?
It appears to me that in Chrome and Safari the left and right border (2px) in total are added to the set table width, while in the other browsers the border is considered part of the width.
The (most) relevant CSS-lines are the following ones (from the table.css file, also available through the page's source file):
table.uitbetaling {
margin: 11px 18px 10px 19px;
border: 1px solid #8ccaee;
width: 498px;
padding: 0;
}
table.uitbetaling img, table.uitbetaling td {
margin: 0;
border: 0;
padding: 0;
width: 496px;
}
table.uitbetaling tr {
margin: 0;
border: 0;
padding: 0 1px 0 0;
}
So basically I have used a table-structure to organize images, like this: (the class of the table is uitbetaling)
<table>
<tr><td><img /></td></tr>
<tr><td><img /></td></tr>
...
<tr><td><img /></td></tr>
</table>
If, here, I set the width of table.uitbetaling and table.uitbetaling img, table.uitbetaling td to the same value (e.g. both 496 or 498), the "problem" in Chrome and Safari is solved, however in Firefox the right side border is than blank. Because the right-side border can't "fit" in anymore. img and td must be at least 2px more narrow than table.uitbetaling for the right-border be visible in Firefox.
Is there any way to solve this?
Nowadays you should be using the HTML5 doctype, if you're having issues about borders adding themselves to the element's width look up the CSS style: box-sizing
border-box - include border width/height and padding width/height or basically the width you set includes the borders/padding
content-box - the width you set on the element is only the content area, this does not include padding or borders
There is also padding-box which I don't use, usually the above two are enough.
Now sometimes, I think IE8 uses a different box-sizing than Chrome/FF etc, this is why sometimes you have issues. You can always debug and check what the box-sizing is set to.
Note: if you don't have the DOCTYPE then you're in quirks mode, and IE differs WILDLY from Chrome/FF on the box-sizing/box model - and that's your problem right there
segment your code into its simplest elements and test them on each browser. When you find the differences you can use different methods of browser detection to subtly alter the code for each instance. With that said... if you do not want to go stark raving mad, and CSS will do that more then anything in programming let the pixel go if you can.
To be safe, I usually open a table in this way:
<table cellspacing="0" cellpadding="0">
It is "old" HTML, but at least it forces coherency along browsers, and then I apply CSS as needed.
I'd checked with Opera 11, Google Chrome 7.0.517.44 and FireFox 3.6.12 have seen no difference with your site design.
Did you declare the DTD (DOCTYPE)?
Read this:
http://msdn.microsoft.com/en-us/library/bb250395.aspx
It looks that browsers have different ways to display the borders, but the DOCTYPE declaration (which goes at the top of the html document) force them to comply with the actual standards, at least in regard of css box model.
Note: I always use the xhtml transitional DTD to make my document as much compatible as possible...
Good luck!
Try:
table{border-collapse:collapse;}
Its good practice to always set table{border-collapse:collapse;} in the css, and then use cell-padding="0" and cell-spacing="0" in the html anyway.