I have an PNG image file that is partially transparent. I need toggle its opacity .
Currently I am using the following CSS code to permit opacity:
filter:alpha(opacity=50);
However, IE has trouble handling the transparent portion of the PNG. When I try to fix it by adding the following CSS:
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader (src='../images/translucent_effect.png', sizing Method='scale');
Well, it doesn't work. My question is: what is the best solution that people have found to this problem? Should I just convert PNG into GIF? Or is there a more elegant solution?
Thanks.
IE's filter style is a horrible mess. It does allow the browser to do a few tricks that would otherwise be out of its scope, but it is non-standard, and has some major issues.
I can't be certain without seeing your complete CSS, but it looks to me as if you've been caught out by one of filters biggest 'gotcha' quirks:
If you need to specify more than one filter, you have to specify them together. If you specify them separately, as you've done in your example, the second filter overrides the first, even though they are in fact performing completely different actions. This is in fact consistent with the way CSS stylesheets work in general, but is counter-intuitive because of the scope of what filter is able to do.
You can specify multiple filters in a single filter style, separated by a space.
See here for a reference: http://msdn.microsoft.com/en-us/library/ms532847%28v=vs.85%29.aspx
The problems with this approach are obvious, if you want to have different effects triggered by different class names on your stylesheet -- because there's not way to combine filters from different sources into the same element.
The other big gotcha which might catch you out is the fact that filters written with the progid: syntax are actually invalid CSS due to the colon, and it's bad enough to cause some non-IE browsers to choke on the entire stylesheet. This can be prevented by using the shorthand syntax (as per the alpha() filter in your your first example), for IE6 and IE7, or for IE8 with the -ms-filter alternative, using the longer syntax, enclosing the whole thing in quotes.
Here's an example:
-ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50) progid:DXImageTransform.Microsoft.AlphaImageLoader(src='../images/translucent_effect.png', sizing Method='scale');"
Hope that helps.
Related
so I've read a lot about the current state of rotating text and not being able to perfectly get real antialiasing to happen in all browsers. It looks like the first box in the pic in chrome, but the second, jaggedy box in firefox. I've tried the most popular fixes including -webkit-backface-visibility:hidden; -webkit-font-smoothing:antialiased; and maybe one other I can't remember.
However this is not asking the same question, but a new one I havent found anywhere. These two screenshots of the same box are both taken from Firefox. The jaggedy box on the bottom is what it looks like normally, however, when I mess with the rotation attributes with another(completely different) element on the page with the css edit console, it renders the box perfect / smoothly...
I do, however, have to continue to press up or down to change the rotation value on another element for the entire box to render antialiased perfectly, then it returns to its jaggedy normal self. I rotated the div that the content is in and put the css fixes on the same div(although I did try putting the css fixes on every element) and I didn't ever seem to get any smoothness or antialising like you see in the box above...only when I rotate another element on the page in the browser. WTF?!!?!? is there a way to do this in css or is it only something the browser is doing in realtime and cannot reproduce that smoothness in CSS yet?
EDIT: PIC for comments section
For whatever reason, it seems under some circumstances browsers "forget" to antialias text while doing complex transforms.
The fix:
Using CSS to force the browser to render the transformed element in a separately-composited "layer" is one solution:
transform: rotate(…) translate3d(0px,0px,1px);
The explanation:
Many rendering engine implementations create a GPU layer for the 3d-transformed element, and composite it onto the rest of the page when painting. This alternate rendering path can force a different text-rendering strategy, resulting in better antialiasing.
The caveat:
However, this is a bit of a hack: first, we're asking for a 3-dimensional transform we don't really want; second, forcing many unnecessary GPU layers can degrade performance, especially on mobile platforms with limited RAM.
dev.opera.com hosts a good discussion of compositing, hacks using transform3d, and the CSS3 will-change property.
Jeremy if you come back and answer this I can give the answer to you. just realized I hadn't had an answer to this so I needed to put something here.
This solution worked as in the comments above:
Jeremy:
I had another thought: it could be related to creating an opengl/webgl layer behind the scenes. If you add translate3d(0px,0px,1px) after the rotate transform, does it "fuzz out" a bit more?
Answer - Yes this works to perfectly anti-alias any text in all browsers!
The more and more we venture into the wonderful world of CSS3, the more and more we all get annoyed by the fact that these features require a MASSIVE amount of browser prefixes to allow compatibility with some older browsers. This problem becomes quite apparent even for small sites, where we need 4 or 5 CSS properties for the exact same effect. A common example would be the background property for gradients.
I know that there are scripts that can help with this issue, but before resorting to those, is there a pure CSS fix that would allow you to work around the prefix issue, or at the very least, some sort of method to keep the extra amount of typing to a minimum? That is, combining things, shorthand, whatever. CSS files can easily double with CSS3-rich content.
I totally agree to the excessive code need to accomplish the same effects in CSS3 but that issue is on the browsers side as other comments stated.
One design practice/tool/technique i think best to follow is using LESS when writing css.
I see the The possibility of over coming this issue (for now) with it. Checkout it out here. http://alittlecode.com/handling-multiple-css3-transitions-with-a-less-mixin/.
If you are not sure what is LESS then check this out - http://www.lesscss.org/.
Yes it is pure CSS from my perspective, but no as stated before, it won't reduce the size of files.
I'm having a really really weird issue...
I have a header with some background which has the background-size as cover. For IE8 I do have this filter:
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='myawesomefile.jpg', sizingMethod='scale');
Which loads fine and it's shown well. However, everything inside the header, becomes un-clickable. hover doesn't work and they don't fire any events...
I've prepared some JSBIN to show this behaviour.
On of the problems with the old IE filter styles is that they do have some nasty glitches, which can result in weird things like this.
This specific issue is a new one on me, but it's just the kind of thing that I'm used to seeing with filter.
I've just spent a bit of time fiddling with your code to see if I could work around it, and I haven't got anywhere. So my suggestion would be to give up on the filter.
Fortunately, there is an alternative: Version 2 of the CSS3Pie library includes a polyfill for background-size, which means that it can be supported in all IE versions.
There are some caveats with CSS3Pie as well; obviously it's a Javascript library, so will fail if your users don't have JS enabled. And it requires you to use the shorthand background syntax rather than a separate background-size property. But the point is that it does work, whereas clearly your current solution doesn't, so I'd say it's worth a try.
Hope that helps.
The following lines are included in the HTML5 Boilerplate template by default:
::-moz-selection{background:#fe57a1;color:#fff;text-shadow:none;}
::selection{background:#fe57a1;color:#fff;text-shadow:none;}
However, I want to keep the selection color as the OS default (blue in Windows, I think it's brownish orange in Ubuntu). If I leave out the background property, there will be no background.
Since this selector is not officially supported for CSS, being removed from CSS3 and not currently in the draft for CSS4, there really isn't much documentation on how exactly the selector should be applied.
As defined by the selector, it is meant to override the system's default text selection colors. The browsers have apparently taken this literally. By specifying ::selection, those colors are immediately overwritten, even if you haven't specified them. The problem is the system's defaults are not part of CSS. The browser is seeing your declaration and thinking "ignore the system's default, use what's in this declaration instead." Since you don't have colors specified there, no colors are applied (background is none and color is inherit). Whoops, kind of hard to tell your text is selected, huh?
This is only a theory of what appears to be happening since, as I said, there really is no documentation on what actually happens, or what is supposed to happen.
Honestly, the only way you'd really know for sure is to look at the source code and see what it's doing when it sees that selector. Maybe asking someone on the development team for one of these browsers would be easier. Either way would still be difficult. Maybe you could submit a bug report and they can delve into the issue a little more...
My colleague and I are having a tough time deciding on a best practices approach for ie6, ie7 support for a site we're building. The site is for an older crowd, so not supporting these browsers is out of the question.
At the same time, we're trying to start incorporating modern coding practices into our work so we can get practice and fully understand capabilities. A specific area I want to touch on with you guys is handling fall backs for CSS3 backgrounds.
We have 2 choices here, if we're to use CSS3 backgrounds and not add extraneous wrapping tags for backgrounds:
Use :after, :before etc. pseudo elements for adding multiple backgrounds to elements. (this is the choice we've made for now)
Use CSS3 multiple background specifications
This produces more elegant markup and is certainly a step in the right direction. But what about browsers that don't support these features?
Modernizr.js tells us to check for specific support and then write fallbacks:
Modernizr.load({
test: Modernizr.geolocation,
yep : 'geo.js',
nope: 'geo-polyfill.js'
});
However, we're not given much guidance on the actual fallbacks for specific features. So, in the case of something like CSS3 backgrounds, what would be an effective fallback strategy?
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
About the CSS3 multiple backgounds and/or background gradients I think there is an approach better than those you proposed: CSS3 Pie.
This way you will be able to use all those nice effects also in IE6, 7 and 8 (including also border-radious) without any JavaScript intervention.
1. Fail gracefully. Certain complex elements can be hidden with CSS and revealed upon page-load with JavaScript depending on the browser as one example.
2. Conditional style-sheets or JavaScript fixes. Spend a lot of time fixing each problem in each browser and write a style-sheet just for it. Also, you could try various JavaScripts that claim to bring older browsers into compliance. I've tried this JavaScript but it seemed to conflict with jQuery. CSS Pie is another option to bring rounded corners to older browsers.
3. Ignore older browsers. Do nothing special for older browsers. People on IE6/7 already see the world differently than everyone else. Alternatively, do nothing special for older browsers but actively avoid overly complex functions & features. Optionally, you can add a nifty "upgrade notification" message with little effort.
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
That is certainly one valid fallback approach. Depending on the design and the elements in question, though, you might find that simply supplying the primary background is enough to yield a decent-looking and perfectly functional, though not visually identical, component.
"Supporting" older browsers shouldn't always mean "taking great pains/writing tons of extra code to insure a near visual match." It is difficult but not impossible to ramp up a QA team so that they understand the concept of Progressive Enhancement as it can be applied to aspects of pure visual presentation.