Does BPS possibly do anything like 'header("X-UA-Compatible: IE=7")'?
-
IE8 in XP cannot display a given clock for me at my site, and this question has been posed to me:
Maybe there is something in your .htaccess that generates a
header("X-UA-Compatible: IE=7")or similar response?
http://wordpress.org/support/topic/coolclock-not-showing-in-ie?replies=10I do not see how BPS could/would be involved here, but I will likely never know without asking…
Many thanks.
-
I read through your other post and the nature of the problem is not something that could be or should be handled by and .htaccess file.
Reference: http://htmlpurifier.org/docs/enduser-utf8.html
I noticed that your source code only has…
<meta charset="UTF-8" />…and not the full meta tag which i have always used…
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />I do not think this will make any difference, but i believe that you should change your Header coding for best practices.
Reference: X-UA-Compatible meta tag: http://stackoverflow.com/questions/6771258/whats-the-difference-if-meta-http-equiv-x-ua-compatible-content-ie-edge
If the issue is a CSS issue then the plugin author or you would have to either create IE CSS hacks, but typically what i do is to use 2 different CSS stylesheets. 1 for IE and then 1 for all other browsers.
If the problem is with some coding in the plugin itself that is outputted to the Browser then logically the best solution would be to ouput IE code for IE and other code for other Browsers.
Using the PHP get_browser() function for example would be 1 approach to take to identify the Browser and then output code based on the Browser: http://php.net/manual/en/function.get-browser.php
Being a long-time troubleshooter, I follow you fully there, and being a rookie at web stuff, I now have more learning to do.
Many thanks for your info and insights.
Ok the Cool Clock plugin issue/problem is very obvious and yes it is simply just a CSS issue. The Cool Clock plugin does not come with CSS stylesheets and the visual display is done purely with javascript.
So the solution would be to either create your own CSS stylesheet specifically for IE and have it be loaded in your Theme header.php file or maybe enqued from the plugin or add the CSS style for IE inline. If it were me i would search through the Cool Clock’s plugin coding and add the additional coding shown below that is based on the outputted HTML source code that this plugin generates.
Adding an IE stylesheet in the header
<!--[if IE]> <link href="http://example.com/wp-content/themes/xxxxxxx/IECoolClockstyle.css" rel="stylesheet" type="text/css" /> <![endif]-->source code generated by plugin – add additional IE specific CSS code.
<li id="coolclock-widget-2" class="widget coolclock"> <h2 class="widgettitle">Cool Clock</h2> <!--[if IE]> <script type='text/javascript' src='http://example.com/wp-content/plugins/coolclock/js/excanvas.compiled.js?ver=3'></script> <div style="Do Custom Inline IE CSS styling"> <canvas class="CoolClock:classic:100:::"></canvas> </div> <![endif]--> <!--[if !IE]>--> <div style="width:200px;height:auto"> <canvas class="CoolClock:classic:100:::"></canvas> </div> <!--<![endif]--></li> </ul> </div>Many thanks, and I have that on my list.
I noticed that your source code only has…
<meta charset="UTF-8" />…and not the full meta tag which i have always used…
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />I have made that change, and I also found
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />here:
http://wordpress.org/support/topic/encoding-set-to-utf-8-but-reading-as-iso-8859-1?replies=8I have also tried that, but stayed at your version that is also mentioned here…
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
…in concurrence with your comment related to .htaccess, I believe.Hi AITpro, thanks for your thoughts on this.
<div style=”Do Custom Inline IE CSS styling”>
Could you share any ideas about what IE 8 in IE 7 compatibility mode might be needing as style rules there? I do not see how
<div style="width:200px;height:auto">would pose a problem for IE in any mode… Nor thestyle="width: 200px; height: 200px; "that the script adds dynamically to the canvas tag.First I thought it might be the
height:autothat would cause the div to collapse because IE would not see the canvas but even the height seems to be calculated correctly on leejosepho’s site, judging by the subtext he has put inside the same div, under the canvas…I have really no idea how to approach this ;(
Well I installed your plugin (very Cool plugin) no pun intended and what I saw was that the clock displayed differently in Chrome then it did in IE. There were significant visual display differences between the 2 Browsers (background clock circle was almost invisible to the eye in IE). So I checked your plugin files/code for CSS styling to see if there was an easy way to add this and I saw that you do not have any bundled CSS stylesheets and are instead doing the styling primarily with js and a bit of inline CSS styling.
It would be very simple for me (being a coder) to add the inline CSS for IE, but for a regular end user this might be a bit tricky for them. The problem with cross Browser compatibility (always til the end of time) is that you have to either do IE hacks/webkits and figure out all the possibilities before hand (pain in the neck) or maybe you could just add an additional IE CSS option in your Widget config and point folks to links around the Internet where they could find the IE hacks/webkits code that they might need/want. This way folks could just do a “do it yourself” thing.
And yeah Cross Browser stuff is HELL! LOL
Personally it seems to me that the easiest and smartest route for you to take is to create an additional option in your Widget config just for IE and in your code that option would write/output an IE conditional area. I guess the best way to figure out if this is really doable is to manually create the IE conditional area and add IE hacks/webkits and see if everything displays the same in IE and other Browsers. If it works then you would just need to create your code to output that new IE conditional area in the IE option in your Widget.
<!--[if IE]> .... .... .... <!--<![endif]-->Or you could do the more time consuming thing and track down all the necessary IE hacks/webkits/mozkits……………….. and bundle them with your plugin.
Hmmm… but I do not see how it is any ‘normal’ style rule that prevents the clock from showing up in IE 8 in Compat mode. I would guess it’s more an issue with excanvas.js
The CoolClock script is not mine, nor is the Explorer Canvas script so I prefer to leave them ‘as is’, as much as possible. I just worked them into a WP plugin for a client 🙂
background clock circle was almost invisible to the eye in IE
This is done deliberately because excanvas.js is not perfect and IE tends to draw some kind of artifact lines between the 3 o’clock point of the scale and the tip of some kind of phantom second hand.
Similarly, the hand decorations that can be seen in any other browser have caused strange effect and are therefore disabled in IE.
Yep that makes sense. The only point i was trying to make is to prevent ongoing headaches for yourself you should either take the approach of pointing out the IE issues and offering folks some sort of help direction to go in on their own (do it yourself) or you could go the extra mile and figure out IE solutions ahead of time and bundle them. Or of course you can always just state that there will be some visual differences in IE and that is just “what is what”. 😉 Personally I found that everything worked perfectly with only minor nick nack visual issues in IE. When i get some spare time i will play around with CoolClock some more.
… but I do not see how it is any ‘normal’ style rule that prevents the clock from showing up in IE 8 in Compat mode.
I hope I have not caused any confusion here. My site specifically disables IE Compatibility View, and I got that idea from links such as this:
http://stackoverflow.com/questions/3803901/how-can-i-programmaticaly-disable-ie-compatibility-modeIf I have understood correctly, doing that forces IE to do better than it otherwise would in Compatibility mode…and that is a fact at least at my particular “mobile-first” (default Twenty Twelve architecture) site.
@leejosepho, well… yes, it IS a bit confusing.
In your page source I see
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
which I understand even though according to Microsoft is ‘not intended for production use.’ But when browsing your site in IE 8 — or rather: letting my browser identify with request headerUser-Agent:Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)— the server responds with an extra response header:
X-UA-Compatible:IE=7.I have the impression that it is this response header that prevails over the meta tag and IE 8 is forced to something less than you say you want.
In the morning I will double-check to be sure I know exactly what I am adding along with whatever might have already come “built-in” via the Twenty Twelve ie.css sheet and try to offer a sensible report here. I am fairly certain the code you have just mentioned is not the one I need to make my Password box work correctly, and the other is “optional” if an IE8 user at my site is either willing to sacrifice a bit of display quality or be sure to not run in Compatility mode. If you have looked at my site in a variety of browsers, you might have noticed IE8 not only misses a great clock, but neither can it render my round corners and blue outline. Also, there have been times when IE8 has presented a momentary view of the clock when first arriving at my site, and then apparently dropped or lost it somewhere. Firefox is certainly my own favorite browser even though it cannot access the audio player (not showing at the moment anyway), but our group at the site has one long-term member that only has XP/IE8 and is not able to upgrade…
…and now off to get my old slippers… 😉
In the morning…
Oops, I forgot, RavanH, and I now have that at top of my list refreshed for tommorrow’s morning.
If you want to find out where that
X-UA-Compatible:IE=7response header is coming from, there are several plugins for firefox you might find useful. I’m not sure of the names (I forgot, I switched to Opera and Chromium a long time ago) but search for ‘Response Hearders’ and for ‘User Agent’… The first search should show you a choice of plugins that allow you to visualise the servers response headers (obviously) and the second search will get you plugins that allow you to make FireFox identify itself as another browser.Use the User Agent switcher to identify as IE 8 and then revisit your site, checking the response headers. You’ll see the one I am talking about as last one.
Then switch off ALL plugins and revisit your site again in the same way, checking again if the response header is still there. If not, re-enable half of the plugins you had disabled and check again. Go on until you know exactly which plugin is causing the response header and then try to find out why…
But if the response header did not go away after disabling all plugins then switch to Twenty Twelve (or Eleven) theme and check again.
If it’s still there, I would be very surprised because it is not your Apache server that sends this header (I’ve checked by visiting a static html file on your site)… Create a fresh new PHP file called test.php with just one line of content:
<?php echo 'test'; ?>Upload it to your site root, visit it the same way as before and check the response headers again.
Make sure to have your browser identify as IE 8 each time otherwise your results will get very confusing 😉
If you want to find out where that X-UA-Compatible:IE=7 response header is coming from…
You might check to see whether it is still there after my site got rolled back a bit last night. I have just been through my
style.cssandheader.phpfiles and these two,<meta http-equiv="X-UA-Compatible" content="IE=Edge" />and<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />, are no longer there. However, I do still have this to make the dots show up whenever IE8 is in the Password box during Login:`<!–[if IE]>
function twentytwelve_child_scripts_styles() {
global $wp_styles;
wp_enqueue_style( ‘twentytwelve-ie’, get_template_directory_uri() . ‘/css/ie.css’, array( ‘twentytwelve-style’ ), ‘20121010’ );
$wp_styles->add_data( ‘twentytwelve-ie’, ‘conditional’, ‘lt IE 9’ );
}
add_action( ‘wp_enqueue_scripts’, ‘twentytwelve_child_scripts_styles’ );
<![endif]–>’Overall, I doubt there is much point in trying to make my site completely friendly with IE since even Twenty Twelve’s Development Team had to make a call there quite some time ago.
Many thanks!
No, your site still sends the
X-UA-Compatible:IE=7response header. By the way, a response header is something different than a HTML header meta tag or any conditional stylesheet…
- The topic ‘Does BPS possibly do anything like 'header("X-UA-Compatible: IE=7")'?’ is closed to new replies.
