I'm using the CSS3Pie htc file to enable border-radius in IE8, but I'm getting no effect. My CSS is:
button {
border-radius: 4px;
-webkit-border-radius: 4px;
-moz-border-radius: 4px;
behavior: url(PIE.htc);
}
I've put PIE.htc in the public root (as is done on the CSS3PIE demo page), having tried in the same folder, using a relative uri and an absolute uri.
The demos are working; just not my code!
Thanks, Adam
Try adding
position:relative;
z-index: 0;
as suggested here http://css3pie.com/forum/viewtopic.php?f=3&t=10
This question is similar to the one posted here:
CSS3 PIE - Giving IE border-radius support not working?
The URL of PIE.htc as referenced in behavior: url(PIE.htc); is a relative URL, so it is probably looking for it in the same directory as the stylesheet, so I'd suggest adding a slash to make it an absolute URL. But you say you've already done that.
Check that the URL you're specifying does actually load the PIE.htc file - ie put that URL directly into your browswer and see what comes out. It is possible that your web server is not serving it correctly for one reason or another (not recognising the mime type? etc)
Have you gone through the known problems on the PIE site? Have you added position:relative; to your style? Could it be the known z-index issue?
You specify that it doesn't work in IE8. Have you tried it in IE7? IE6? Same result? (this will eliminate ths possibility of it being an IE8-specific issue)
By the way -- unrelated point, but you should put the border-radius style below the versions with the browser-specific prefixes. This is the standard way to do things, as it means that when for example, Firefox starts supporting border-radius, it'll pick up the standard style over -moz-border-radius. If you've got the -moz version below it, that one will continue getting used, which may not be what you want.
As Daniel Rehner stated, you need to use the position: relative and z-index properties for IE8. If you are using a website with sub directories to call the CSS file, you will also need to use an absolute path in your CSS to PIE.htc - this was one part of our issue.
The other part of the issue could be that your server is not outputting the PIE.htc file as text/x-component. You can correct that via IIS or Apache, or call the PIE.php script in your CSS. More info here: http://css3pie.com/documentation/known-issues/#content-type
Both of these issues had gotten us, and hope they help you out.
I actually had this problem for a completely different reason.
The border-radius will not work if a filter is applied to the same element. I was applying the border-radius to a button with a linear gradient applied as a filter. As soon as I removed the filter the border-radius worked.
This is documented behaviour and gradients should be applied using -pie-background:
http://css3pie.com/documentation/supported-css3-features/#gradients
behavior: url(PIE.htc);
Make sure there is no space between the url and ( as this stopts it from working at all in IE8
Just in case anyone is trying to apply this to table cells, you'll need to apply position: relative to the table element (and not the tdor th, even though those are the elements being rounded).
Related
I'm doing som cross browser fixes for IE8 and I came across something I've never seen before. Is there someone who have seen this crazy shadows before? and is there someone who knows what possibly is causing this?
I'm attaching two screenshots, one from IE8 and one from Chrome.
IE8 - http://cl.ly/image/1u0t0A2D0p0l
Chrome - http://cl.ly/image/411L1B0Y2X3Y
Thanks for any kind of help!
View HTML and CSS here: http://marcusfriberg.com/skillbird/stof.html
This problem is not only happening in IE8 but also in IE9. When I checked through Developer tool, It is clearly showing that it is happening because of the property filter which is given in the post-top and stats-type classes. I suggest you to go with conditional css to overcome this problem. Have a look at this link(community additions too) for clear understanding about the behaviour of filter in IE browsers.
EDIT:
And also in MDN, The filter property is not documented for IE browsers. Check compatibility section. It also stated that
Older versions (4.0 through 9.0) of the Windows Internet Explorer browser supported a non-standard "filter" that has since been deprecated.
The other filter property which is compatible with IE Browsers can be found at this link (not for IE9).
IE8 does not support text-shadow in CSS, which is what Chrome and IE appear to be using here.
http://caniuse.com/css-textshadow
If this is code you inherited, then it is quite likely that someone tried to use an alternative method for IE which went horribly wrong.
There are a number of fallback ideas for IE, but one popular one is to use 'IE Filters'.
Sometimes these propriety IE filters can achieve similar effects as the standard CSS, but at other times, they need fine-tuning.
You might want to scan your CSS file for the use of filters and make adjustments as needed. Code would look something similar to:
#element {
filter: alpha(opacity=70); /* the opacity won't work! */
filter: glow(color=black,strength=5);
}
See this article for more:
http://www.impressivewebs.com/css3-text-shadow-ie/
To achieve a better effect of text-shadow in IE, I use CSS Pie. It's amazing. Check it out here:
http://css3pie.com/
And it's even being used right now on one of my client's website: http://www.tokheim.com
Hope that helps.
As of this website:
p { text-shadow: 1px 1px 1px #000, 3px 3px 5px blue; }
"The first value specifies the horizontal distance and the second specifies the vertical distance of the shadow. The third value specifies the blur radius and the last value describes the color of the shadow."
It means your filter value for Y axis is too big.
The site I am currently working on is http://rattscallion.com/ I am focusing my efforts on getting the site to look proper in IE.
I was having trouble getting the frame on the pages (look at /murals.html for the page I'm working on first). IE9 said that the inline-style stated that the background-image was "none," so it crossed out the original background image. I figured it might be getting this from somewhere on the main stylesheet so what I did was make a new frame that only exists in IE and style it only in the IE stylesheet. Unfortunately this also doesn't work...it still says that an inline-style is setting the background-image to "none", but there is no such thing!
I double-checked and this is happening in IE9 standards mode. So why is this happening? Can anyone help figure out how to "force" it over what IE perceives as the inline style?
Well there's your problem:
CSS was ignored due to mime type mismatch
normalize.css
If you check the network calls the normalize.css is received as text/plain instead of text/css. You should install static content (under server roles) in your IIS as for some weird reason it's not installed by default. I'm betting one WHOLE dollar you're using IIS.
You could have just copy pasted the normalize.css into a server side css file so it's not accessed remotely.
I got it working by doing the following:
remove #framePos img{ display: none; } from styles-ie.css
remove unitpngfix.js - the png filter fix was for ie6 and serves no purpose on ie9 (it's actually one of the reasons the frame does not show)
Note: the frame.png pic is place in lots'o'places as background so you should consider a little clean up of the css files
Another Note: unitpngfix.js replaces the frame.png with the clear.gif and places transparency filters on every png element. So tinkering on css will not do anything until you remove the js.
I have just found something very weird while developing a website. While trying to get a div element to display across the top of the screen, I noticed that I wasn't achieving a desired result in any browser except for old versions of IE. In order to test some different code, instead of deleting the faulty line, I used '//' to comment it out (I'm not really even sure if that works in css) but what happened was, the compatible browsers used the uncommented code, while IE used the code marked by '//'. here is the code:
#ban-menu-div{
position:fixed;top:0;
//position:relative; //<-- IE keeps the banner with rel pos while the other
display:block; // browsers used fixed
margin:auto;
padding:0px;
width:100%;
text-align:center;
background:black;
}
so basically, it seems as though // can be used to instruct newer browsers to ignore specific lines of code, and instruct older versions of IE to use it? If this is common practice someone please let me know. it sure makes developing for older browsers a hell of a lot easier
// is not a valid CSS comment.
Browsers that parse CSS properly will ignore //position because //position is not a valid property name (details are here, property -> IDENT S* -> follow it through).
This only works in IE7 due to its well known bug of accepting properties with junk prepended to them.
It's not just // that works. IE7 will have red text here:
body {
!/!*//color: red;
}
This is most typically exploited with *, for example *display: inline; as part of the display: inline-block workaround for IE7.
Don't fall into the temptation of commenting out single lines or blocks and not using the correct /* */ couple. A customer who has access to the website folder just chose by himself to comment out a single line using this:
//* comment here *//
Actually, Chrome and Safari will ignore ANYTHING that follows this line. I would call it a "css killer". :D
I'm new in this area and I wrote a div style which didn't work properly for firefox 4, opera 11.1 and for ie 8.0 but worked for chrome 11. The code which was a style for a div was the following only with a different order
#info_text
{
background:#fdf6cc;
width: 650px;
margin-left:1px;
padding-left: 30px;
padding-right: 263;
min-height: 90px;
}
After changing it this way it worked for all the browsers except for the Internet Explorer 8.0.
Can I do something to make it work or it's the problem of the browser?
Does it metter the order in this case?
The order doesn't matter in this case.
You are missing units for the padding-right property. Running your code through a validator will flag errors like this.
Welcome to world of web development! All browsers interpret CSS differently, particular old versions of IE (try the above in IE6 for some fun!)
To understand exactly what problems you're having we need to see a working web page with the above.
The order of the CSS doesn't particularly matter to be honest, though obviously later CSS overrides earlier CSS and this something which is used commonly in the industry.
try opening "developer options" under "tools" in ie, if there is a more specific class, it may be overwriting something, or if something is formatted poorly, IE may be excluding it all together. Another option is "firebug lite", firebug is a very useful tool for getting started with css, javascript, and page structure. Without a link to the page that you are having the problem on, it's very hard to determine the cause, I copied your css and tried it myself, but got the expected result in all browsers
I'm working with some CSS (from a Joomla template) like this:
div#logo {
-moz-background-clip: border;
-moz-background-inline-policy: continuous;
-moz-background-origin: padding;
background: transparent url(../images/head.png) no-repeat scroll 0 0;
...
}
I've looked up some of those -moz- properties and they seem to be assigned their default values, and if I turn them off in Firebug nothing happens visibly.
Would there be a reason to add them to a CSS file? Are they for an old version of Firefox perhaps?
I think what's happened is someone's set a background shortcut rule and then looked at the ‘computed style’ resulting from that shortcut rule in the DOM inspector. They've noticed that setting the style also sets Mozilla's background-clip, -origin and -inline-policy properties, and tried to reproduce these rules without understanding what they're for (namely a detail of Mozilla's CSS implementation, and potentially CSS3 in future).
Certainly changing -moz-background-inline-policy would only have any effect on elements that were display: inline (which div isn't by default), and changing the clip/origin properties around the border would only make any difference if the element actually had a border.
Get rid of them.
Chances are good that these properties don't need to be there. I'd suspect that they're included to ensure consistent rendering across different versions of Firefox. I guess the answer is, if you're seeing no difference from disabling them in the versions of Firefox you're interested in supporting, take them out.
background-clip isn't supported on current Firefox builds AFAIK, so the author has probably put them in preempting a problem (though that would be odd as they are all set to the default anyway, and they haven't included the opera or webkit prefixes...)
background-inline-policy is default as continuous in all Firefoxes, and background-origin is default as padding in them all too.
I'd say pointless code for this one.
If I turn them off in Firebug nothing happens visibly.
I'm not sure on those particular attributes, but have you checked that the browser isn't using a cached style sheet?