In 1953, a man named L. Ron Hubbard founded the Church of Scientology, complete with a set of beliefs and related practices and presented as a new religion.
Over time, the Church of Scientology grew larger and larger and spawned several offshoots aimed at more specific and narrowly-focused teachings. Eventually, Scientology is recognized as an established religion and starts gaining even more followers and benefits, one of them being tax exemptions from governments.
One of the teachings within Scientology is that psychiatry is evil and should be abolished from the world. They claim that it is "destructive and abusive".
Sometimes, a member of the Church of Scientology is actually in need of psychiatric help, but because of these teachings, which have no scientific evidence backing them up whatsoever, that help is never extended and the member leads a life full of suffering and problems—in some cases, it even leads to the death of the member.
In one of the more extreme situations, some of the Scientology members take the teachings too literal, too liberally and too far, and they go out and kill a local psychiatrist. Someone who was simply an innocent doctor, helping others deal with their personal and/or professional problems. Someone who some of his patients claim they owe their life to, a man who was regarded as a small hero in the local community for all the great work he did. He was kind, gentle and helpful. But now he's dead.
It's all as sad and regrettable as it sounds.
But is it?
I have to apologize, for I lied to you. My story is not all true. Yes, the Church of Scientology was founded in 1953 and yes, it does truly aim to abolish psychiatry from the world. But to my knowledge, none of its members ever went so far as to kill a local psychiatrist. [update: so I was half-wrong; they do kill people]
You see, my story is really about Christianity. Replace 1953 with "Middle Ages", replace Scientology with "Christ", and replace "psychiatry" with any of the things that are as innocent and harmless as psychiatry but which the Bible, for whatever reasons they are, preaches to be "evil" and "sinful". You don't, however, have to replace the killing of an innocent man with anything but today's news of the killing of Dr. George Tiller, for that is the true state of things today.
How much longer will it be before we start asking ourselves why we, the people, keep paying money to these religions—any of them—through Government tax exemptions when they also produce members within our own society that commit such intolerable crimes?
How much longer will it be before we start asking ourselves why we turn a blind eye to much of religion when so much of it speaks of hatred and violence and it requires us to interpret these teachings through many layers of better consciousness, something that clearly is too much to ask of for some of the members of these religions?
How much longer is it going to be before we say "enough is enough"?
It takes a well-educated, intelligent mind to easily separate the good from the bad amongst religions' preaching, whereas it takes very little thinking to take religions' preaching and use them to justify heinous acts of terrorism against innocent people.
I know I'm tired of indirectly funding these organizations that don't do a good enough job of self-moderation. Why aren't you?
Disclaimer upfront: any opinions expressed in this post are the sole opinion of myself and do not necessarily reflect the opinion of any of my employers, past and/or present.
In part one of this article, I described the situation with IE8 and the X-UA-Compatible header that the browser uses to decide what rendering engine to use. By far the most important takeaway from that piece is that detecting a browser by sniffing its UserAgent string is a terrible practice. It was already an unreliable method of doing so, but now, with IE8, it is fundamentally broken and you simply cannot rely on it to ever accurately present you with what rendering engine you’re dealing with. And when we’re detecting for browsers, most of the time it’s the rendering engine we really care about.
Let’s look at the two primary solutions to dealing with the disparity between rendering engines: the first is more ideological, the second more pragmatic. Both are acceptable ways of doing web development; if you’re doing neither, then you probably need to work on that. But that’s my personal opinion.
Build sites the Right Way™
If you want to know what the right thing to do is, read no further than this section. The absolute best way to build and maintain a website is to completely remove your dependency on user agent sniffing—not just for IE, but for browsers in general. UA sniffing is an unreliable and dangerous practice and it is the primary reason the Web is so broken today, so stop sniffing the User Agent string and basing your code off of that. There are more reliable metrics to use; for JavaScript, the most prevalent one is feature detection. There is a great resource on feature detection that goes into incredible detail, and is an absolute must-read, but in a nutshell: feature detection is an approach wherein you first detect whether the browser supports the use of certain functions, before you actually use those functions. Practicing this method also has the very valuable benefit of making your code far more robust and forward-compatible.
As for CSS, there is no similar thing to feature detection[1]. There is, however, the nature of the language itself: CSS offers many different solutions for any given problem, and I can tell you from experience that there is almost always one that will work across browsers. Keep in mind when developing and testing your CSS that your first choice of layout/style approach may not work as well in some browsers, but that doesn’t preclude a different solution from working better. Over time, and with enough experience, you’ll learn to instinctively reach for the solutions that work well across all browsers, reducing if not eliminating your need for hacks.
The Good Alternative
The Right Way is obviously a rather ideological approach, but that doesn’t mean it isn’t the absolutely best way to do web development. However, real world constraints such as time and resources make it a less practical, sometimes not even possible solution for the website at hand. Fortunately, there is a way to detect for Internet Explorer’s various rendering engines reliably, and I mean absolutely 100% reliable. The reason for that is because of the so-called Version Vector.
The Version Vector is an IE-only mechanic that powers the more widely known IE-specific thing calledConditional Comments, simple HTML comments that IE parses differently from any other browser. Throughout all the various possible combinations of UserAgent, implementation of X-UA-Compatible and blacklisted domain or not, the one and only thing that accurately matches what rendering engine you’re dealing with is the IE Version Vector. No matter the UA, no matter what you set for X-UA-Compatible (if you even set it at all), the Version Vector will tell you what rendering engine you’re dealing with.
Conditional Comments in Internet Explorer exist as both HTML and as JavaScript implementations, but ironically, for IE8 they only have mutually exclusive detection patterns. What I mean by that is, you can’t use only one or the other to get the information you need. So, that’s why I created this small bit of code that will, guaranteed, tell you what rendering engine in Internet Explorer you’re dealing with. JavaScript libraries should take notice:
After this code executes, any non-IE browser (regardless of any meddling with the UserAgent string) will only have a single variable, __IE__, which is false. But in any Internet Explorer browser, the value of__IE__ will now be guaranteed to match the rendering engine being used. If the browser is IE 5.5 or older, it will be set to 1 — this is, in my belief, a good enough differentiator because we really shouldn’t be worrying about anything older than IE 6 anymore at this point. Come on, people.
A quick run-through of that code might be educational, so let’s look at the most interesting lines:
Line 2: this is how a JavaScript IE Conditional Comment starts. All non-IE browsers will ignore everything until line 11.
Line 3: the IE-specific variable @_jscript_version maps to the browser chrome. IE5.5 = 5.5, IE6 = 5.6, IE7 = 5.7 and IE8 = 5.8, regardless of what rendering engine or UserAgent string is in use.
Line 11: this IF clause will only evaluate for IE 7 and 8. It is at this point that we need to do the HTML Conditional Comment check to see what rendering engine we’re dealing with. To do so, we create an element in node-space and then, the crucial line:
Line 13: we set the innerHTML value of that element to contain two Conditional Comments with a div inside each. IE will still correctly parse these Conditional Comments, which brings us to the final, really important line…
Line 14: we look at the first child inside the element in node-space. It will either have a className of “ie7” or “ie8” and this will depend solely and reliably on the rendering engine that’s being used. We then strip away the “ie” part, turn the number into an integer type (instead of a string) and voilá, the variable __IE__now contains the version number of the rendering engine.
Using the above code, you will be able to detect any version of IE and get the version of the rendering engine being used, giving you an easy way to build your code on top of it without any UserAgent sniffing and without any risk of engine-to-browser mismatch.
Dealing with the browser landscape today can, at times, be difficult and cumbersome, but the more you adopt the best practices in web development the easier it becomes.
Yet. I have something related to this that’s merely waiting for approval and will hopefully go live soon. ↵
Disclaimer upfront: any opinions expressed in this post are the sole opinion of myself and do not necessarily reflect the opinion of any of my employers, past and/or present.
Update: Make sure not to miss Part 2: Solutions of this article to see what your two best ways of dealing with IE are!
If you’re a web developer, you’ll already know that Internet Explorer 8 (Final) was released to the public recently, and with it comes the “X-UA-Compatible” header, a mechanic that the IE Team devised as their way of “not breaking the Web”. In this two-part article I will first explain what IE8’s behavior is with regard to this header, then, in the next piece, provide you with technical solutions that allow you to maintain control over the display and functionality of your website(s) no matter what your constraints may be.
Let’s start from the top: the X-UA-Compatible header, which can be set as both an HTTP-level header or as a <meta> tag inside your HTML document, allows you to specify which rendering engine you want IE8 to use; setting it to IE=EmulateIE7 will tell IE8 to use the IE7 rendering engine; setting it to IE=8 will enforce the IE8 Standards Mode engine. It is designed to be forward-compatible, so a hypothetical IE9 will support it, as will an IE10, and so forth. If you want to simply enforce the latest and greatest engine in all currentand future versions of IE, you can set the X-UA-Compatible header to IE=Edge, which is the instruction to “always use the most cutting edge engine available”.
Just as examples, here are both the HTTP and the <meta> tag ways of setting X-UA-Compatible:
On top of this header implementation, Microsoft has also added a blacklist of sites to IE8 that, by default, are instructed to render in IE7 Compatibility View mode. This list, formally called the Windows Internet Explorer 8 Compatibility View List, is actively maintained by Microsoft and contains (currently) over 2400 top-level domains for sites that are not deemed or are proven not to be ready to handle IE8’s far more Standards-compliant rendering than its predecessor. I’ll get to that later on; what’s important to know right now is that this list is only used by IE8 if the user has chosen to use it. The default setup of IE8, “IE8 Express Setup”, enables the use of the list. The Custom Setup routine allows you to choose not to use it, so if you run, maintain or develop for a site whose top-level domain is on this list, you can’t simply assume that the visitor in IE8 is going to get the IE7 rendering engine (or the IE8 one for that matter, but more on that, again, later on). Also important to note is that the list is top-level domains only but applies to any and all sub-domains for those domains.
As the cherry on top, there is the Compatibility View button that is present in the UI (the chrome) of IE8 if and only if the X-UA-Compatible header is not specified in any way; neither on HTTP level nor inside the HTML via <meta> tag (it will also not show up in the UI on sites that are blacklisted, as the blacklist is really just an implicit way of saying IE=EmulateIE7). This button allows the user to toggle between default (IE8 Standards) mode and IE7 Compatibility View. If you allow it to, IE8 will send your clicking behavior of this button back to Microsoft as a means of gathering data for which sites should be on their blacklist.
Lastly, before going into the nitty-gritty, I want to point out that this entire EmulateIE7 / IE8 Standards Mode stuff only matters for sites with a DOCTYPE. If you’re actively choosing to rendering in Quirks mode, stop doing that. No, I’m not joking, you should really be doing web development properly by now and that means the use of DOCTYPEs. But, for completeness’ sake, Quirks mode documents are not affected by the X-UA-Compatible header.
IE8 findings
I’ve done a lot of testing, and every so often I would discover another behavior piece that meant I either had to re-do all my tests or add a new dimension to my results (and thus do even more tests than previously thought). At this point, the number of permutations and combinations is so large that I’m not going to bother you with the full set of results. Instead, I will just list off a couple of the important behavioral patterns I’ve gleaned from all this.
Let me start with something that will cause some immediate concern among many of you:
It is entirely possible to encounter IE8 sending the IE7 User Agent string to the server while using the IE8 Standards Mode rendering engine; conversely, you can encounter the IE8 User Agent string while rendering in IE7’s engine.
If there ever was an argument against merely sniffing the User Agent string to base your code off of, this would be it.
Now let’s go over some rendering engine logic.
By default, out of the box, IE8 will choose to render a website in IE8 Standards Mode
If it loads a page from a blacklisted domain, IE8 will use the IE7 Compatibility View rendering engine
If the user presses the Compatibility View button on a non-blacklisted domain, IE8 will use the IE7 Compatibility View rendering engine
If the website specifies X-UA-Compatible to IE=EmulateIE7, the Compatibility View button will be hidden and IE7’s rendering engine will be used
If the website specifies X-UA-Compatible to IE=EmulateIE7 via the <meta> tag (only) but there is a<script> element in the source code before the <meta> tag, then IE8 will actually use its IE8 Standards Mode rendering engine
If the website specifies X-UA-Compatible to IE=8 via HTTP header and X-UA-Compatible to IE=EmulateIE7 via <meta> tag, then EmulateIE7 will prevail and IE8 will render using the IE7 Compatibility View rendering engine
…providing you don’t have a <script> element above that <meta> tag, of course.
Are you a little confused yet? It’s okay if you are, this is decidedly more complex than any other browser makes it. Let’s power through!
If a domain is blacklisted or the Compatibility View button is pressed by the user, which puts the entire domain you’re on in Compatibility mode, IE8 will send the User Agent string for IE7 to the server (it is at this point undecided which rendering engine is going to be used)
If a blacklisted domain is framing a non-blacklisted website using HTML Frames, then the non-blacklisted website will inherit the rendering engine and User Agent choices that IE8 made for the blacklisted domain…
…and vice versa.
What that means is that if your site is viewed through a Google Images’ frame or, for example, the DiggBar, your domain is effectively blacklisted—completely regardless of whether your own domain is on Microsoft’s list or not. The reverse is also true, so if you create a frame on a non-blacklisted domain that points to a blacklisted domain, you will be requesting that blacklisted website with the IE8 User Agent string.
For both scenarios, the framed site (i.e. the target) still has full control to override the Rendering Engine in IE8 by specifying the X-UA-Compatible header.
By the way, I used the Google Images frame and the Diggbar as examples because both google.com and digg.com are on the blacklist, and there’s no telling if they’ll ever be removed until the day they’re just not on that list anymore.
Now, while wrapping up the second piece with the technical solutions on how to deal with all of these permutations and possible rendering engine/UA combinations, feel free to ask me any questions using Twitter for comments—something I instated on this blog a while ago, but which now makes even more sense thanks to Twitter’s recent changes to the @replies system. Just use the comment link below to send me your comments and/or questions. This is the time to get your specific question answered in my second post!
Atheists are the new black people from the worst of the racial discrimination days:
So needless to say, I take my minority status as an atheist seriously. It upsets me when I read that the Boy Scouts of America not only do not accept scouts and scout leaders who identify as gay, but that it requires scouts to believe in God. And it hurts me when I read that only 20 years ago, a President named George H.W. Bush stated that atheists should not be considered citizens or patriots of the United States.
