IE9, Opacity, and Alpha


IE9 introduces support for the CSS3 Color Module, including its popular opacity property. As we have done with other standards-based features, opacity is implemented so that the same markup used in other browsers just works in IE9’s ­standard mode.

Internet Explorer 8 and earlier versions implemented an alternative mechanism to apply opacity using the alpha filter of the IE-specific filter property. This creates a compatibility challenge because IE9’s standard mode supports only opacity and not the alpha filter. (IE9’s compatibility modes Quirks, 7, and 8 still support the alpha filter but do not implement opacity.)

For sites that use best practice feature detection, this is not a problem. They will detect that opacity is supported in IE9 and use it instead of filter. The problem is with sites that use browser detection and mistakenly assume that IE always uses filter alpha instead of opacity and then change only the filter property in script. The opacity effect will appear broken in those Web pages when run in IE9’s default 9 document mode. The fix is to detect the standards-based opacity feature first and browser-specific filter feature second as we’ve described in previous posts.

Example Best Practice CSS

.fiftyPercentOpaque
{
opacity: 0.5;
filter: alpha(opacity=50);
}
Example Best Practice Code
// set flags for whether we should use opacity or filter with
// this browser (or browser mode). we prefer opacity.
var useOpacity =
(typeof document.createElement("div").style.opacity != 'undefined');
var useFilter = !useOpacity
&& (typeof document.createElement("div").style.filter != 'undefined');

function setOpacity(el, value) {
// let el be either an element object or an id string
if (typeof el == 'string')
el = document.getElementById(el);

// ensure value is in [0-1] range
value = Math.min(1, Math.max(value, 0));

// set opacity or filter alpha depending on what's supported
if (useOpacity)
el.style.opacity = value;
else if (useFilter)
el.style.filter = "alpha(opacity=" + (value * 100) + ")";
}
Alternative Browser-detection Code

In general, we prefer feature detection to browser detection but we’ve see a lot of opacity-related code use browser detection instead of feature detection.  If you have a site that does that today, you may find it easier to update your browser detection so it works with IE9. Here’s code that properly detects when IE is running in a browser mode less than 9’s standards mode.

function browserDetectSetOpacity(el, value) {
// let el be either an element object or an id string
if (typeof el == 'string')
el = document.getElementById(el);

// ensure value is in [0-1] range
value = Math.min(1, Math.max(value, 0));

if (navigator.userAgent.match(/\bMSIE\b/)
&& (!document.documentMode || document.documentMode < 9))
el.style.filter = "alpha(opacity=" + (value * 100) + ")";
else
el.style.opacity = value;
}
Summary

The problem described above occurs only when the opacity of an element is changed using script that doesn’t detect whether opacity is supported before changing filter. Sites that use only declarative CSS markup will continue to work fine even when opacity is changed indirectly by changing the CSS class of an element or using a pseudo-class such as :hover.

W3Schools offers a clear explanation of CSS opacity and IE’s legacy alpha filter.

—Ted Johnson, Program Manager Lead for Web Graphics

Comments (61)

  1. Sean Hogan says:

    Wow, charging ahead. That's great.  

    One question: The CSS example has the opacity setting before the filter setting.

    What is the IE9 algorithm that gives priority to the earlier setting?

    Does IE9 detect that opacity is specified and ignore later filter: alpha(opacity)  directives?

    What happens if the order is reversed? What if different filters are used?

    I would check this myself but don't have IE9 preview.

    Thanks,

    Sean

  2. Paul says:

    Sean,

    From the post "IE9’s standard mode supports only opacity and not the alpha filter."

    So it should just be ignored.

  3. wai says:

    a off-topic question..

    I am reading this post with IE8 @ XP SP3. When browser window's width is small, content in sample code block is overflow and horizontal scroll bar is displayed. But there is extra white space at the bottom of the sample code block. This happens in IE8 browser mode only, not in IE7 browser mode.

  4. E says:

    Hey, I'd have a somewhat related question, is IE9 going to support CSS3 2D transforms (http://www.w3.org/…/css3-2d-transforms)? I'm asking because we're looking into heavy usage of those in our upcoming stuff and it'd be kinda sucky to not be able to do that just because of IE9.

  5. Meni says:

    I'm repeating myself, but this is more great stuff, namely non-standard features obsolescence.

    There was a discussion on another thread about companies creating webapps and wanting absolute stability from their browser. This is an example why this is the wrong way to go. There will always be stupid tricks in your app, like browser detection instead of feature detection. There is no escape from updating your app. The web was built for that. Don't demand that the world will stop for you. Either write for for common denominator standard, meaning you wont be able to use the latest and greatest, or use libraries and tools to take care of this variety for you and hope they will be updated for this kind of situation. Things like jQuery and GWT.

    IETeam, can we get a statement on WebGL? Will be supported (big news) or not (sad news). I'll also like to get some behind the scene politics at Microsoft regarding your work. I'm sure some heads at Microsoft would love if you stop with this openness and standards direction.

  6. c says:

    It's really unfortunate that IE9 can't use the same markup to display opacity that worked in IE8.  And that I have to write javascript to spit out CSS instead of, you know, just putting it in a .css file.

  7. mitch074 says:

    @c: the aim of this post is to deal with script-side property settings (when you want to modify element properties, say, in a fade-in/fade-out effect); if you want to do it the 'static CSS way', then it's much simpler:

    – you put your standard code in a CSS sheet that all browser load (and Firefox, Safari, Opera, Chrome and IE 9 will use just that)

    – you put IE fixes (such as 'filter') in a spare sheet that you load through conditional comments (and IE 5/6/7/8 will apply these over/on top of what they could understand from the above CSS sheet)

    Well, dealing with IE 5/6 may be overkill… But it can be done!

  8. hAl says:

    @c

    The article gives an example of, "you know, just putting it in a .css file"

  9. When you say you're supporting the Color module, does that include HSL values too?

  10. revised says:

    Here is the same code revised for readability and normal coding standards:

    CSS:

    .fiftyPercentOpaque{

       opacity:0.5;

       filter:alpha(opacity=50);

    }

    Code 1:

    /*

    set flags for whether we should use opacity or filter with

    this browser (or browser mode). we prefer opacity.

    */

    var useOpacity = (typeof document.createElement('div').style.opacity != 'undefined');

    var useFilter = !useOpacity && (typeof document.createElement('div').style.filter != 'undefined');

    function setOpacity(el, value){

      // let el be either an element object or an id string

      if(typeof el == 'string'){

         el = document.getElementById(el);

      }

      // ensure value is in [0-1] range

      value = Math.min(1, Math.max(value, 0));

      // set opacity or filter alpha depending on what's supported

      if(useOpacity){

         el.style.opacity = value;

      } else if(useFilter){

         el.style.filter = 'alpha(opacity=' + (value * 100) + ')';

      }

    }

    Code 2:

    function browserDetectSetOpacity(el, value){

      // let el be either an element object or an id string

      if(typeof el == 'string'){

         el = document.getElementById(el);

      }

      // ensure value is in [0-1] range

      value = Math.min(1, Math.max(value, 0));

      if(navigator.userAgent.match(/bMSIEb/) && (!document.documentMode || document.documentMode < 9)){

         el.style.filter = 'alpha(opacity=' + (value * 100) + ')';

      } else {

         el.style.opacity = value;

      }

    }

    Although I wouldn't recommend the 2nd code snippet as it goes against coding principals – your method should only do one thing, and be labeled as such.

    The real question is – is this a full proper opacity implementation or a wrapper on the filter:alpha code? because we all know that filter:alpha has some bugs still.

  11. mitch074 says:

    …still, it's all well and good, but I wonder WHEN, with the new Jscript engine AND the new DOM support, will setAttribute be properly supported. And yes, the DOM is entirely loaded.

    Whether I do

    document.getElementById('test').type = 'hidden'

    or

    document.getElementById('test').setAttribute('type','hidden')

    I get 'command not supported' – whether it's in IE 8 proper, IE8 mode or IE 9 in IE9pre4.

    All other browsers do it properly without a problem.

    Please IE team, could you at LEAST fix the DOM support in IE 9?

  12. Tim says:

    @revised – that may be normal coding standards (I'm not sure what normal coding standards for CSS are), but I disagree that removing whitespace aids to the readability of that CSS sample…

  13. Brian LePore says:

    Just wondering, why has the alpha filter been singled out to not run when opacity has been set, but not other filters that mimic the display of other CSS features that IE9 still supports? For example, the shadow filter still works even when box-shadow is being used.

  14. jayp says:

    Great stuff, nice job IE team. Keep up the blog.

    A statement on WebGL (either way) would be very welcome, as per someone above.

  15. c says:

    You're right – I completely missed the .css example.  Which was the first thing on the stupid page.  My bad.

  16. Ted, I appreciate that your example code uses feature detection to determine the appropriate opacity property, but if you're going to use the phrase "best practice" your code should actually universally exhibit best practices.

    A major area for improvement here is that this code is not very DRY. For example, you use document.createElement("div").style twice. Instead of this, why not just maintain a reference to a single created element, and use that wherever appropriate? Also, instead of testing 'typeof' obj.prop == 'undefined', just test obj.prop === undefined (which poses no problem, since obj has been declared). Finally, all of this code could be placed in a closure so that variables aren't exposed unnecessarily.

    You need to consider that many people are just going to copy + paste this code, wholesale, into their projects, and since you're in a position of responsibility in the community (posting on a very high-profile blog), you should really vet your "best practice" code in order to best educate your readers. We, as a community of educators, really need to step up our game.

  17. Ted, I appreciate that your example code uses feature detection to determine the appropriate opacity property, but if you're going to use the phrase "best practice" your code should actually universally exhibit best practices.

    A major area for improvement here is that this code is not very DRY. For example, you use document.createElement("div").style twice. Instead of this, why not just maintain a reference to a single created element, and use that wherever appropriate? Also, instead of testing 'typeof' obj.prop == 'undefined', just test obj.prop === undefined (which poses no problem, since obj has been declared). Finally, all of this code could be placed in a closure so that variables aren't exposed unnecessarily.

    You need to consider that many people are just going to copy + paste this code, wholesale, into their projects, and since you're in a position of responsibility in the community (posting on a very high-profile blog), you should really vet your "best practice" code in order to best educate your readers. We, as a community of educators, really need to step up our game.

  18. Silly says:

    <<I'm sure some heads at Microsoft would love if you stop with this openness and standards direction>>

    Yeah, I'm sure the IE team is coding away at night, sneaking in to use the Microsoft facilities despite the objections of the top management they all work for. They're secretly embracing standards and they have collected dirt on their bosses so that they cannot be fired despite failing to follow orders.

    You have an amusingly naive view of the world.

  19. Chris B says:

    This is a first for me, but nice job Team IE. Getting rid of the non-standard stuff is the best way to make sure it doesn't continue to propagate in the wild. Yes, in some cases it will require updates to long-stable code, but it's for the best. Nice to know that even my older sites that used conditional comments to implement IE specific CSS will continue to function in IE9 since it will obey the original opacity rule and disregard the alpha filter in the IE8+ stylesheet.

  20. Will Peavy says:

    @Cowboy – I think the best practice for most people is to use a library to abstract away the need for feature detection.

    Then all you'd need is something like – "el.fadeTo(100, .5)" – and you're done.

  21. Meni says:

    @Silly,  so you're telling me that EVERYONE at Microsoft sees eye to eye with Google here on the importance of the web as an OPEN platform? You are telling me that all the managers at Microsoft think that? Pushing open standards over closed ones?

    Remainder: Google makes money from advertising, while Microsoft from selling licenses. Google, IMO, understand the value of open-source (think Wikipedia vs Encatra RIP), while Microsoft makes money from software. Yes, I naively believe Google is for openness, and even though MS yells all day "yes we're open, DOTNET is open, etc." I don't believe them for a sec. IETeam excluded :-).

  22. Spindel says:

    @Meni – Google? Open? You mean like the Google deal with Verizon about Wireless Internet access?

    http://www.crunchgear.com/…/not-neutrality-did-google-verizon-just-stab-the-internet-in-the-heart

    And "WC3 standards" like Google Chromes Native Client?

    code.google.com/…/nativeclient

    Stop talking bullshit. Google is not for openness (read about the Google-Verizon deal). They just want to make more money and rule the web.

  23. Greg says:

    Is there a way to disable this fade in and fade out effect in IE?

  24. Anonymous says:

    @Meni

    I do not work at microsoft, however I can say pretty certainly that IE will never support webgl. The reason for this is that while other browsers are regular applications, Internet Explorer is also a component of windows. WebGL requires direct bindings to openGL, however openGL is not a component windows, it must be made available by the drivers of GPU vendors. This means that clean installs of windows with IE will not have openGL and webgl applications will not function over remote desktop because WARP, the software fallback for Direct2d acceleration, will not be able to provide a fallback for OpenGL.

  25. mitch074 says:

    @Anonymous: ever since Vista's release, OpenGL has been made available in Windows as an OpenGL-to-DirectX9 translation layer. Your objection is valid WRT Windows XP, but it doesn't hold water for Vista/7.

  26. Neal says:

    Will rgba color declarations be supported in IE9?

  27. Anonymous says:

    @mitch074

    This article contradicts your claim

    http://www.dailytech.com/article.aspx

  28. jayp says:

    The article seems to state that an OGL to Direct3D wrapper exists in Vista already, but that Khronos have made available drivers to allow OGL to run natively. Assuming that's true, the article doesn't contract mitch.

    If not, IE could still implement some kind of wrapper for the GL functions that are contained within the GL spec that would translate it to Direct3D. Google are working on something that will do that.

  29. hAl says:

    If the W3C creates a 3D version of Canvas or SVG it could be supported by either OpenGL or Direct3D.

  30. jabcreations says:

    I use conditional comments for IE specific stuff however I also now (Version 2.9+) use object detection with the DOM to determine the browser's rendering engine and version and load a CSS3 style sheet specific to that browser. This allows me to load all the properties, selectors, etc that are CSS3 based for each browser without triggering errors and/or warnings. It's a bit more JavaScript code then that is posted (I cover IE 5.5+, Gecko 1.0+, Opera 7.0+, and Safari 2.0+) however the coverage for CSS3 it provides is everything one could need.

    …so knowing this why are you guys looking at the user agent string in your example code? Seriously, you guys should email me before you post JavaScript on the blog.

  31. Tiredoftwits says:

    jabber: You should probably work on Reading Comprehension. They explicity state why they offer a version that uses User-Agent detection. And no, I don't think you get the benefit of the doubt just because you're the author of Version 2.9 of "Unusably ugly site."

  32. jabcreations says:

    Must be sad living under a bridge refreshing the IE blog once every 30 seconds just to troll someone only to never get an emotional response. =^.^=

  33. mitch074 says:

    @Anonymous: ah damn – it was planned in a RC of Vista, and since I was so much not impressed by said OS I didn't dig deeper. That'll teach me to expect good things from MS.

  34. Nick says:

    Maybe I'm missing something here but shouldn't the best practice for the CSS opacity declaration be:

    .fiftyPercentOpaque{

       opacity:0.5; /* Modern Browser support (including IE9) */

       -ms-filter:"alpha(opacity=50)"; /* IE8 support */

       filter:alpha(opacity=50); /* IE fallback support for IE7, IE6, IE5.5, IE5… */

    }

    Or have you guys already forgotten about IE8? blogs.msdn.com/…/the-css-corner-using-filters-in-ie8.aspx

    @mitch074 – Precisely! fixing the existing DOM bugs should be of highest priority.

  35. Jane says:

    @MSFT – this is a bit off topic but as a developer I'm often testing quick test case pages on my local machine. e.g. I want to quickly mock up a widget interaction. (static HTML and Javascript)

    The problem is that IE presents the security bar every single time! and often times I use a popup window which then loses data passed to it from the opener when it is reloaded to allow the javascript.

    I realize the security risk in what I'm about to ask, but please for the love of god what is the registry setting/? to allow pages loaded on the localhost filesystem to load without the warning.

    - I hereby realize that if I bork my pc by opening it up to some malicious drive-by hack on the internet that allows spawning of localhost pages that run JScript/VBScript that erases my hard drive it will be my own darn fault… but I FULLY ACCEPT THIS.

    Please don't tell me to use MOTW because I have no intention of adding a line to the 1,000's of files I have and the 1,000s of files I'm likely to make in the future… just to make a test page work in IE when it works just fine in ALL other browsers I use.

    thanks

  36. Sergei Yakovlev says:

    (Comments on "HTML5, Modernized…" seem to be closed, so I'm posting here.)

    I urge IE Team to consider supporting the "text-shadow" CSS property in IE9, while there is still time left for that.

    "text-shadow" has been supported since Safari 1.1 (October 2003), Opera 9.5 (June 2008), Chrome 2.0 (May 2009), Firefox 3.5 (June 2009) [see http://www.kremalicious.com/…/make-cool-and-clever-text-effects-with-css-text-shadow]. By now, it has become pretty wide-spread. A lot of real websites and blog themes use it, mostly for engraved/embossed-style text [also: http://www.w3.org/…/text-shadow].

    I'd argue that "text-shadow" is probably the single most used CSS3 feature not yet supported by IE9. CSS 2D Transforms? Still exotic. Multiple columns? Even more rare. On the contrary, text shadows are already being used on lots of real sites. So, in keeping with the IE9 philosophy of "same markup everywhere", "text-shadow" really belongs in IE9 as a feature. Plus, once you implement it, it will work right away on all existing sites, since it has no vendor prefix.

    Now, just as you are retiring "alpha" filter while simultaneously introducing "opacity", you can do the same for "dropshadow", "shadow" and "glow" filters. Here are a few examples:

    1) filter: dropshadow(offx=5,offy=3,color=red);

    => text-shadow: 5px 3px red;

    2) filter: shadow(color=red,direction=45,strength=5);    [looks like fade-out extrusion]

    => text-shadow: 1px -1px rgb(255,  42,  42),

                                2px -2px rgb(255,  85,  85),

                                3px -3px rgb(255, 127, 127),

                                4px -4px rgb(255, 170, 170),

                                5px -5px rgb(255, 212, 212);

    3) filter: glow(color=red,strength=5);

    => text-shadow: 0 0 8px red,

                                0 0 8px red,

                                0 0 8px red,

                                0 0 8px red;

    To sum up, the main motivation is to be able to use blurred drop shadows (which is currently impossible using filters), and to support existing and widely-used CSS property that currently works in all browsers except IE.

  37. sy says:

    @mitch074 — Please add it to the bug tracker, so we can vote up.

  38. planetarian says:

    @jabcreations That wasn't a troll, just the truth. You need to learn how to read.

  39. EricLaw [MSFT] says:

    @Jane: In IE, click Tools > Internet Options > Advanced. Tick the box "Allow active content to run in files on my computer" in the security section. It is not recommended to browse the Internet at large with this box checked.

  40. TopHatTrick says:

    @Sergei

    I'm pretty confident the final build will include text-shadow. (You can laugh at me when time proves me wrong.)

    Microsoft has this new mantra: underpromise, overdeliver.

    They will *not* let this one slide, especially so because it is such an exposed feature for the end-user.

    They're just aiming for the buzz and excitement it will generate among the developers. (Remember canvas?)

    I expect the IE-team to tie up a *lot* of loose ends before the beta.

  41. Ted Johnson [MSFT] says:

    @Nick — Yes, the markup you propose using the -ms-filter property does indeed work in IE8 but it's not needed. During the IE8 endgame, a change was made to also support the legacy filter property (without the -ms- prefix) to improve compatibility with existing sites. I chose to show the minimum markup that's required.

  42. David Mark says:

    "Also, instead of testing 'typeof' obj.prop == 'undefined', just test obj.prop === undefined (which poses no problem, since obj has been declared)"

    Wrong.

    http://www.cinsoft.net/host.html

    And to those recommending using junk libraries (e.g. jQuery, GWT) as a "best practice", where have you been?  Swapping out large, complicated blobs of JS every time a new browser comes out is the epidemy of futility.

  43. @cowboy

    "Also, instead of testing 'typeof' obj.prop == 'undefined', just test obj.prop === undefined (which poses no problem, since obj has been declared)"

    Wrong (particularly in the context of IE).

    http://www.cinsoft.net/host.html

    And to those proposing the use of junk libraries (e.g. jQuery, GWT) as a "best practice", realize that swapping out large and complicated blobs of JS (most with bad histories in the context of compatibility, forward and backward, with browsers and themselves) every time a new browser comes out (or an old one does something unanticipated) is the epidemy of browser scripting futility and therefore can only be considered a worst practice (despite popular myths to the contrary).

    For example, 90% of the "major" libraries use browser sniffing extensively.  That's pretty much the kiss of death for compatibility (and always has been).  The remaining 10% use poor object inferences based on observing current browsers (the dubious mantra is "show me where it fails".)

  44. Sorry for the double-post.  This site sucks.  I'm sure I don't need to explain any further.  :)

  45. still not fixed says:

    Just a reminder: innerHTML is still broken in IE9 platform preview 4.

  46. Hadi says:

    Please Microsoft this time I want a better Internet Explorer. A faster, lightweight, secure IE9 than all the other browsers.

  47. mitch074 says:

    @Nick, @sy: the bug is marked WONTFIX in IE8, and was solved in IE9 (actually, IE 9 didn't want to run Jscript on my machine until I completely reinstalled it – not repair, uninstall then reinstall); I actually switched to IE8's debugger too fast (due to the above problem) that made me report it as an IE9 bug – but it's fixed. The report is 587185, and it can be closed now (I said so in a comment, but it hasn't been read by the IE team since last week).

    However, we can add as an IE9pre4 bug that switching rendering mode (through the developer tool's interface or the Debug menu) doesn't work (my app remains in IE9 mode). This may be solved in time for the beta, it's a big enough bug the IE team must have noticed it…

  48. Mitch074 says:

    @still not fixed: you should not use innerHTML. Period. Use DOM methods (or libraries that do), that'll spare you some headaches. It did for me.

  49. Realistic says:

    @Mitch074 if you are creating a bunch of content all at once innerHTML outperforms any other DOM method hands down. jQuery is awesome and all, but it still has to use the underlying native JS that the browser provides.  Intentionally crippling your browser by not supporting innerHTML on all elements that can contain HTML is confusing, inconsistent and makes web development a pain.  IE9 will live on for at least a decade after it ships – do you really want to be using hacks to fix innerHTML in IE in 2020?!?! for a version of the browser that hasn't even shipped yet?… when the bug has been known since at least 2000? I'm sorry but prolonging a bug for 20 years doesn't seem like the kind of thing a browser vendor does that is trying to tell the world they have fixed their ways and is now adhering to web standards and cross-browser compatible code.

  50. hAl says:

    @realistic "if you are creating a bunch of content all at once innerHTML outperforms any other DOM method hands down"

    The HTML elements that IE does not support with InnerHTML do not come in bunches generally.

  51. hAl says:

    @realistic "when the bug has been known since at least 2000"

    A bug against what spec?

  52. meni says:

    @Spindel,

    you have said:

    {{{

    And "WC3 standards" like Google Chromes Native Client?

    code.google.com/…/nativeclient

    Stop talking bullshit. Google is not for openness (read about the Google-Verizon deal). They just want to make more money and rule the web.

    }}}

    Thanks for remaining me about NaCl! It's one of these amazing disruptive technologies. The idea is to serve the browser i386 code (a later scheme makes it more portable RE other CPUs like ARM, amd64), that will be checked for correctness and run at native speed. In one of their demos, they run a unity game! (unity is heavily into dotnet/mono stuff, it all runs in a browser, coross-platform, talk about irony). See http://www.youtube.com/watch

    IF they pull this off, (i'm a little skeptical myself security-wise,) it's an amazing piece of tech that will narrow the gap between native apps and web apps. There are some f*&^%^&ing smart brains at Google (that's no easy feat) working on this, so it looks promising.

    of course it's not a w3c standard, what's your point?

    Oh, and it's open source. Google WILL NOT SUE YOU FOR USING THIS. You may doubt this, good for you.

    Google is into the web (selling ads of course, i don't like seeing ads, life's a birtch), Microsoft is into selling Windows copies. And making sure poeple wont buy Macs or Linuxes. I have a feeling Microsoft isn't all keen on open web. I think it was brought kicking and screaming there, with IE9. But that's just little looney me.

    I have a feeling you learned some MS specific technologies, and you feel the world has just pulled the rug under your feet. I'll bet Silverlight, ASP.NET, are some of them. Otherwise i have a hard time understanding your views on Google. I have a suggestion: learn some basic standard stuff: HTML, CSS, JS. learn to make web apps, not windows apps. Don't trash JavaScript as inferior to C#. It's the new bytecode. see Douglas Crockford at developer.yahoo.com/…/theater . Learn Canvas, SVG. Use libraries such as jQuery. Don't relay on Microsoft to make life easy for you. Developing for the web is hard! Or, just forget it and develop windows apps.

    In conclusion, let me finish with my "Carthago delenda est":

    IEteam, can we have a statement on WebGL?

  53. mitch074 says:

    @realistic: while innerHTML used to be much faster than DOM methods (more specifically, it was 300x faster in IE 6; in other browsers, the ratio was MUCH lower – and we're talking 2007 browsers, before the speed rush to DOM and JS optimizations), it's no longer so true  – and on the other hand, innerHTML is risky, supported unevenly across browsers, and a kludge.

    I know that doing away with innerHTML and replacing it with DOM methods (and I don't use jQuery: I do my code myself, not to say jQuery is bad – I just enjoy tinkering) didn't make my pages slower, and solved a bunch of Schroedinbugs in all browsers. Which is a win in my book.

  54. Jace says:

    @realistic

    Don't forget that IE9 PP4 is now one of the top 2 browsers – Chrome and IE9 – in ECMAScript performance, so you may want to revisit using DOM operations.

    Benchmark here:

    ieblog.members.winisp.net/…/Dean_PPB4_6.png

    (Opera is slightly faster than both, but is not a major browser in terms of marketshare)

  55. Opera is really not important. But the same goes for IE9.

    Firefox rocks.

  56. @Ted Johnson [MSFT]

    You said

    "

    Example Best Practice CSS

    .fiftyPercentOpaque

    {

       opacity: 0.5;

       filter: alpha(opacity=50);

    }

    "

    and later added

    "

    the markup you propose using the -ms-filter property does indeed work in IE8 but it's not needed. During the IE8 endgame, a change was made to also support the legacy filter property (without the -ms- prefix) to improve compatibility with existing sites.

    "

    but Sylvain Galineau [MSFT] said on 20 Feb 2009

    "

    The -ms prefix in your static style rules is something **_ we recommend _** not just to be a good standard citizen but because it is the **_forward-looking thing to do in your future stylesheets_**.

    "

    You provided the code

    [

      else if (useFilter)

         el.style.filter = "alpha(opacity=" + (value * 100) + ")";

    ]

    but that is not how MSDN ( ms532847 ) recommended and recommends to do this.

    There are blatant contradictions here … or again nobody ever udpates anything (content, code, example, markup validity, schemas, interactive examples, etc.) at MSDN and no one ever bothers about recommendation coherence, code consequence, etc.

    Gérard Talbot

  57. @Ted Johnson [MSFT]

    function browserDetectSetOpacity(el, value) {

      // let el be either an element object or an id string

      if (typeof el == 'string')

         el = document.getElementById(el);

    Personally, I would never name a string variable which is supposed to hold an id attribute value like you did. This reusing of the el identifier creates a confusion in the minds of beginners; it's a poor (and misleading) choice of identifier too. I would have chosen strIdAttribute (prefixing the returned value type) or something like that.

    "

    W3Schools offers a clear explanation of CSS opacity and IE’s legacy alpha filter.

    "

    Does such statement officially announces that MSDN will soon become some sort of documentation graveyard or archives not worth upgrading nor updating and that, from now on, people should go/will have to go to W3Schools to get clear explanation, good examples written with valid markup code and valid CSS code?

    Gérard Talbot

  58. Roel says:

    The Opacty filter has some mayor bugs in IE8 with PNG files. Why can't this be fixed in IE8? This will not affect any excisting website. It is just a bugfix.

    I am assuming that it will be fixed in IE9.

  59. Stephane says:

    I found box-shadow is quite slow to render (when scrolling a shadowed box, the browser becomes slow) compared to Firefox & Chrome…