简体   繁体   中英

PHP: Detect less than IE9 and ignore document and browser mode

/*------------------------------------*\
    FIXES (IE ONLY)
\*------------------------------------*/

if( preg_match( '/MSIE ([0-8].[0-9]{1,2})/', $_SERVER['HTTP_USER_AGENT'] ) ) {
    wp_enqueue_script( 'respond', ( get_template_directory_uri() . '/assets/scripts/respond.min.js' ), false );
    wp_enqueue_script( 'html5shiv', ( get_template_directory_uri() . '/assets/scripts/html5shiv.js' ), false );
    wp_enqueue_script( 'selectivizr', ( get_template_directory_uri() . '/assets/scripts/selectivizr-min.js' ), array( 'jquery' ) );
}

I currently use the above code in WordPress to detect IE under IE9. I do it this way because even if the HTTP_USER_AGENT is faked and they appear, it won't break normal browser behavior, so there's no need.

I need a way (in PHP) to detect if the browser is in compatibility mode (both browser and document mode IE8 (or less)).

http://dev.netcoding.net/sustain/

If you test that site out in a real IE8 browser, respond.min.js works perfectly fine. But when emulating IE8 by changing both Browser and Document mode in IE9-10, it causes the tab to crash.

I need a way to only add respond.min.js when it's the real IE8 browser, not an emulated one.

You could just disable compatibility mode:

header("X-UA-Compatible: IE=edge");

Or in the HTML source:

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

I figured out the problem I was having.

html5shiv and/or selectivizr are interfering with respond at some point during page load.

I moved the loading of respond.min.js to be the very last script called on the page (in the footer), and it works with no problems (or flashing, as the developer assumed would happen).

It is absolutely impossible to detect compatibility mode from the server-side. The only information you have available is the User Agent string, and that is identical between a real copy of IE7 and IE7-compatibility mode (or for whichever IE version you happen to be talking about).

In addition, since you specify that you're particularly looking to deal with people who change the mode using the Dev Tools, you will also be aware that there are two drop-boxes in the dev tools to set the mode: One of these changes the rendering mode, the other changes the UA string. This means that if you're dealing with someone who is setting the mode manually, then you can't even be sure that the UA string is reporting the same rendering mode that the user is actually using.

There are some techniques that may help you work out the mode in Javascript on the client, but even these are not always reliable.

In short, what you're asking for basically cannot be done.

However, I would argue that it shouldn't be done. Set the mode using the X-UA-Compatible flag, and leave it at that; users who are changing the mode manually should expect the site to break when they do so. It's not exactly part of a normal user's browsing behaviour anyway, so I really wouldn't worry about it.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM