Posts tagged "Internet Explorer"

BrowserLab update removes IE7

Internet Explorer 7 has been retired from BrowserLab

Today we have pushed a minor new version of BrowserLab that no longer contains Internet Explorer 7. If you still need to test for IE7 in BrowserLab, you can do this using IE8 and a by adding bit of code to your page(s). To learn more about IE8’s Compatibility Mode, you can read about it in these Microsoft Blogs:

Introducing Compatibility View
Understanding Compatibility Modes in Internet Explorer 8

Remember to remove that code once your testing is complete, unless you want your IE8 visitors to see your page as they would in IE7.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

IE 9 and Compatibility View

BrowserLab and Internet Explorer 9

Are you seeing IE9 rendering inconsistencies in BrowserLab?

Since we’ve added support for Internet Explorer 9 to BrowserLab, some users have been asking why BrowserLab shows a different rendering result than they see when testing locally with a real IE9 instance. Most of these differences end up being rooted in the same issue: IE9’s Compatibility View List.

Microsoft’s IE9 Compatibility View List contains a list of websites, which Microsoft believes are best displayed in a mode other than IE9 Standards mode. When viewing a site, IE9 will check whether the site is on the Compatibility View List, and if it is, the site will be displayed using Compatibility View – usually as if it were IE7.  If the site is not on the list, it will be displayed in IE9 mode, and the rendering mode will be determined based on any meta tags and the DOCTYPE.

As mentioned previously on this blog, our philosophy for BrowserLab is to provide browsers that are as close to the default installation settings as possible. Most people do not change their browser settings, so the browsers in BrowserLab are most likely to reflect the installed base of browsers. Compatibility View List is on by default in IE9, so we’ve left it on for the IE9 browsers in BrowserLab.  Some web pros have turned off Compatibility View in their local IE9 installation, which can cause a different rendering result.

IE9 Standards and Compatibility modes, side by side

IE9 Standards and Compatibility modes, side by side

For example, it is pretty common for web pros to temporarily host their sites on Dropbox, allowing simple synchronization and the ability to easily share with clients, etc. Unfortunately, dropbox.com is on Microsoft’s Compatibility View List, which causes all content from the dropbox.com domain to be rendered in IE7 mode.

Assuming that the final host of the content is not intended to be Dropbox, BrowserLab may end up providing a false negative (though if a client previews the content from dropbox.com with IE9 they may also see it rendered in IE7 mode). The BrowserLab team believes this to be preferable to the alternative where we turn off the Compatibility View List and run the risk of providing a false positive where BrowserLab shows you that the site renders correctly in IE9, but the majority of users with Compatibility View List turned on will see it in IE7 mode.

What Can You Do?

If you notice a discrepancy between your local IE9 browser and BrowserLab, there are some things you can do to identify and fix/work around the issue.

Start by determining whether the difference in rendering is due to IE9’s Compatibility View.


Verify whether Tools > Compatibility View Settings > Include updated website lists from Microsoft is checked in IE9. If this is checked, you have Compatibility View turned on and your results should match those from BrowserLab.  If your results do not match BrowserLab, please let us know of the issue by posting on the BrowserLab User Forum.

If Include updated website lists from Microsoft is unchecked, you can either enable it to see if IE9 then renders it differently or you can manually check whether your domain is on Microsoft’s Compatibility View List.  If your domain is on the list then it will not, by default, render in IE9 Standards mode.

To force IE9 to render in IE9 Standards mode despite the Compatibility View List, you can add either of the following X-UA-Compatible meta tags to your HTML:

Render page in IE9 Standards mode, ignore doctype: <meta http-equiv="X-UA-Compatible" content="IE=9">

Render page in IE9 mode assuming a standards-based doctype, IE5 (quirks) mode otherwise: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">

Alternatively, if you control the domain on which you are previewing the page and don’t think it should be on Microsoft’s Compatibility View List; you can contact Microsoft to address this.

Feedback

Tell us what we can do to make this experience better for you.  Do you need to see IE9 results with Compatibility View explicitly off as well as on?  Should we somehow display the document mode that BrowserLab’s IE9 browsers are actually rendering in?

In a future blog post, we’ll talk about other factors that might affect rendering consistency and cause you to see different results between BrowserLab and your local browsers, and ways to minimize them.

Matt Johnson
BrowserLab Engineer

References

Understanding the Compatibility View List: http://msdn.microsoft.com/en-us/library/dd567845(VS.85).aspx
Current Compatibility View List: http://ie9cvlist.ie.microsoft.com/ie9CompatViewList.xml

Release 1.5.3 adds Chrome 10, IE 9 & Firefox 4 RC

BrowserLab 1.5.3 is now live!

As part of our ongoing efforts to keep the browsers in BrowserLab current and relevant, we’ve released BrowserLab v1.5.3 today.  This release added Chrome 9 and 10 (Windows), Internet Explorer 9, and Firefox 4 RC (Windows). In addition, we’ve updated Safari to 5.0.4 (OS X).

When we do these kinds of releases, we also update our browser servers to include the latest system updates and security patches. The other notable change we made was to enable Font Smoothing on our Windows Server 2003 browser servers – now all of our browser servers have Font Smoothing enabled.

Tell a friend about BrowserLab! We need your help to raise awareness. In addition to this blog, there are a few ways to stay in touch with us:
Facebook: http://www.facebook.com/browserlab
Twitter: @adobebrowserlab, @brucebowman
BrowserLab User Forums: http://forums.adobe.com/community/cslive/browserlab

Next up: we’re working on more browser updates for OS X, as well as an update for our BrowserLab for Firebug extension so it will work with Firebug 1.7. You can expect these changes to come soon.

We’d love to hear from you in the comments!

Bruce Bowman
Adobe BrowserLab product manager

Using Web Fonts with BrowserLab

Before wide browser support for the CSS @font-face rule, web pages were limited to “browser safe fonts.” This meant the designer was constrained to using fonts that were available on every visitor’s machine. @font-face allows a web designer to make typeface decisions based on aesthetics rather than availability.

All modern browsers now support web fonts, in some form. Microsoft Internet Explorer has supported @font-face since 1997 in version 4, Apple Safari implemented support in 2008 in version 3.1, Mozilla Firefox added support in 2009 in version 3.5, and Google Chrome added support in 2010 in version 6.

Adobe BrowserLab has full support for @font-face. BrowserLab can help you ensure your @font-face declarations are working across multiple browsers. By giving you the ability to quickly test your @font-face declaration across target browsers, you can move on to designing the rest of your site. Give BrowserLab a try with your web fonts enabled pages.

When using @font-face you need to be aware of supported font formats and browser specific syntax.  There is currently no universally supported web font format. Failing to provide proper font formats and browser supported CSS will result in your page rendering inconsistently across browsers.  If done incorrectly, visitors will see the browser’s default font instead of the specified font.

There are some great font services that take care of cross browser support by dynamically generating the appropriate CSS for each browser. Typekit, Webtype, WebINK, and Fonts.com are some of the services available, and all of them generally take care of hosting and licensing. Using one of these services allows the quickest path to implementation without having to know too much about the underlying technology. Typekit provides many fonts created by Adobe, and we are working together to offer more Adobe fonts in the future.

If you find yourself needing to roll your own web fonts, there are a few basics that are required to ensure your intended fonts show up on all browsers:

First, and most importantly: Ensure your font license allows you to use a font on the web. Many foundries do not permit the use of their desktop fonts on the web. For more information, check out the Adobe Type blog on this subject.

Know your font formats. There are a few different versions of web fonts in use today.

  • Embedded OpenType (.eot) – Supported by Internet Explorer only.
  • TrueType/OpenType (.ttf/.otf) – Supported by the widest range of browsers, but, not supported in Internet Explorer. (this may change in IE9)
  • Web Open Font Format  (.woff) – Supported in recent versions of Chrome, Firefox and Internet Explorer, but not yet supported in Safari.

In addition to needing to worry about licenses and multiple font formats, browsers interpret CSS code differently, so writing a rule to include your fonts is less than straightforward. “Bulletproof” syntax for @font-face has evolved over the years to work around browser inconsistencies. Much of the syntax seems repetitive and counter intuitive. For a good history of @font-face and a clear explanation of the CSS syntax read the “The New Bulletproof @Font-Face Syntax” blog post at Fontspring. Learning how the syntax has evolved gives a clearer picture of how each browser handles @font-face.

FontSquirrel is a web service that will convert fonts for you and generate CSS code.  After uploading your fonts, FontSquirrel will convert your fonts for cross browser usage and generate CSS for you. The CSS code generated by FontSquirrel also happens to work just about everywhere, including mobile devices. If you use FontSquirrel to generate web fonts, make sure you have the proper license to do so.

I hope this brief introduction to web fonts has been helpful, and that you find BrowserLab to be a useful tool in helping you test your pages with web fonts.

Shout out to Paul Irish, Christopher Slye on the Adobe Type team, and Fontspring for their help and insight on web fonts.

Charlie Scheinost
Adobe BrowserLab Software Engineer

BrowserLab and User Agent Strings

When visiting a web site, your browser provides a number of details about your system and browser version to the web servers via a user agent string. This information can be used by the web site to, among other things, provide browser specific content to you. The user agent string generally looks something like this:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv1.9.2) Gecko/20100115 Firefox/3.6

See What is a User Agent for a more detailed look at the individual components of the user agent string.

User Agents in BrowserLab

Most browsers have a single user agent string that they send based on the browser version and operating system. Additionally, the general policy within the BrowserLab service is to run the browsers in their default install states so as to best match the median user’s installation. This means that BrowserLab screenshots for most browsers will report the standard user agent.

However, both Internet Explorer 8 and Internet Explorer 9 Beta include a ‘Compatibility View’ that will force the browser to report the Internet Explorer 7 user agent string and subsequently render the page as Internet Explorer 7 would.

Internet Explorer 7 user agent
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322)

While Compatibility View is, by default, off in Internet Explorer 8, it may be enabled by default when you install Internet Explorer 9 Beta. For BrowserLab screenshots we explicity force Compatibility View to be off in both of these browsers, ensuring that these browsers receive and render content meant for Internet Explorer 8 and 9 Beta. The user agent strings that these browsers then send are:

Internet Explorer 8 user agent (Native)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident 4.0; .NET CLR 1.1.4322)

Internet Exporer 9 Beta user agent (Native)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Would support for Compatibility View in Internet Explorer 8/9 Beta be useful to you within BrowserLab or is the equivalent rendering provided by Internet Explorer 7 sufficient? Is there other functionality related to user agent handling that you would like to see in BrowserLab?

Related Resources

Matthew Johnson
Adobe BrowserLab Software Engineer

Release 1.5.2.2 adds Chrome 8 and an IE9 update

BrowserLab 1.5.2.2 is now live, and ready for you to use. In this version, we’ve added Google Chrome 8 for Windows, and an updated Internet Explorer 9 beta.

Have you told anyone about BrowserLab? We could use your help in raising awareness – please help us spread the word in the web community.

In addition to this blog, there are a a few ways to stay in touch with us:
Facebook: http://www.facebook.com/browserlab
Twitter: @adobebrowserlab, @brucebowman
BrowserLab User Forums: http://forums.adobe.com/community/cslive/browserlab

This is most likely our last blog post for the year. As we leave 2010 behind, we’re very excited about all of the new features we’re working on – 2011 is going to be a great year for the BrowserLab service!

Season’s greetings, and Happy New Year!

Bruce Bowman
Adobe BrowserLab product manager

BrowserLab 1.5.2 is live: adds new browser support

In a previous blog post, we told you that some browser changes were coming. We’re happy to let you know that our BrowserLab v1.5.2 release is live, and you can now use BrowserLab with the latest versions of Internet Explorer 9 (beta), Firefox 4 Windows (beta) and Chrome 7 Windows, which has replaced Chrome 3.

In our next release, which will be early in 2011, we’re planning to add Chrome 8 for Windows and OS X, and any updates for our beta browsers. We’re also planning on removing Safari 3 and Firefox 2 at that time.

With the addition of these new browsers, and the support we already have for Safari 5, you’ve got an excellent test environment for helping you test with a wide range of browsers, from the legacy browsers like IE 6/7 to the newest browsers that support HTML5 and CSS3.

We hope you enjoy them! We’d love to hear from you in the Comments.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman

On Browser support, and some coming changes

Within the next few weeks, we’re going to be making several changes to the browsers we support in BrowserLab.

In our next release, coming in December 2010, we’re going to be adding support for 3 new browsers:

  • Firefox 4 beta (Windows)
  • Internet Explorer 9 beta (Windows)
  • Google Chrome 7 (Windows)

Update December 2, 2010: BrowserLab 1.5.2 is now live, and contains the above browsers.

We’re also going to be removing some older browsers:

  • Firefox 2 (OS X)
  • Firefox 2 (Windows)
  • Safari 3 (OS X)

These changes are pretty significant and represent a couple of firsts for us. It will be the first time we’ve removed any older browsers. And it is also the first time that we’ve ever added support for beta versions of new browsers. Going forward, we intend to bring newer, relevant browsers to you sooner than we have in the past. And of course, once the browsers are no longer beta, we’ll be updating them to the shipping version as soon as we can.

Our BrowserLab browsers all have the Adobe Flash Player installed, and otherwise are left in their default factory install configurations. We believe that this is the way most users run their browsers, and will provide you with a testing environment that is most likely to simulate real world situations. If you ever need to know the exact version of the browsers we’re running, in the BrowserLab client, choose Help > About to see version information for our Client, the Flash Player, and each browser.

To help us make decisions on when and whether we add support for a browser, there are several factors that come into play. We look at several statistical sources to gauge market share/usage of browsers. In some cases we also reach out to the browser vendors and make attempts to work with them to provide the best experience in BrowserLab. And of course we balance these with the other priorities for how we invest our engineers’ time in the product.

In addition to the new browsers listed above, we are working on some additional new browser support, and plan to deliver another new release early in 2011.

Do you have questions about our browsers? Go ahead and ask in the comments, and we’ll do our best to provide answers.

Bruce Bowman
Adobe BrowserLab product manager
twitter: @brucebowman