Hi,

As I observe myself, I see that I most often use ExpressionEngine’s “Allow PHP” feature for inserting browser sniffing code. Server-side browser sniffing so common task, that I think it perhaps would be quite nice and usable if browser sniffing were achieved using ExpressionEngine’s variable and conditionals.

I would like to be able to write the code such as this:

Of course, ability to write code similar to this could be achieved via plugin. But I think that browser sniffing is so common task that it really merits to be included as ExpressionEngine’s core feature.

If I may ask, what are you sniffing browsers for?  For my part, I’ve honestly seen it as a technique of bygone days and that most in the web development world frown upon it now.  I’m not saying that I think your request is no good, just that I’d like to have some more concrete examples to get an idea of how you would use this.

Hi, Derek,

My perception about browser sniffing is quite different than yours: it does not seem to me that it is dead or dying or even marginal; perhaps it will become marginal when IE6 will be dead, but when such blessed times will come? It seems that as long there will be browsers which interpret the same code differently there will be need for browser sniffing.

I will present some examples from my experience where I am using browser sniffing:

1. IE6 and less does not support css property position: fixed. Using browser sniffing I pass position: absolute to IE6 and less and position: fixed to modern browsers and IE7.

2. IE does not support css property display: table-row and display: table-cell. Using browser sniffing I pass display: table-row and display: table-cell to modern browsers and display: block to IE.

3. IE has quite useful object called “Dialog helper”. Using browser sniffing I embed into html page Dialog helper if browser is IE and flash object having similar functionality if browser is not IE.

These examples may not be representative about what in real world browser sniffing is used for.

What I believe is representative, is this kind of workflow: you develop using Firefox for
display of the code you are writing and when everything works OK in Firefox you test on other browsers. Quite often something does not work correctly (usually in IE).  Then you search for a technique which might work equally well on all supported browsers. If such technique does not come to mind, you fork the code.

For code forking there are essentially three options: server-side browser sniffing, client-side browser sniffing and css hacks, such as *html hack. Of these options server-side browser sniffing is most universal and powerful since css hacks invalidate the code and using client-side browser sniffing there may be a danger of displaying ugly page before browser specific code is applied.

#3 is new to me, but #1, #2, and the others you refer to have pretty much been deprecated in the design world in favor of IE conditional comments, where you can do like we did for our sites, which we approached the way you describe.  We developed in browsers that observed standards well, and then tested in IE, noting all of the things that weren’t quite right.  We still serve one CSS to everyone, but with IE conditional comments, IE users get their own stylesheet as well, which because of CSS’s cascading nature allows us to override only what we need to.  No sniffing, and the markup maintenance is dead simple.

You can always make a plugin out of the PHP that you are using, and since this can be handled in PHP, or even with path.php variables, I don’t think this will be something that we will likely add to the application.  But that’s three ways that ExpressionEngine allows you to accomplish this now, so hopefully that will still make your work easier!