Web developer, writer, speaker. Co-founder of his company Algonquin Studios as well as evolt.org. Has co-written “Usability: The Site Speaks for Itself,” “Web Graphics for Non-Designers,” and “Web Professional's Handbook.”
Make sure you view this on Google's flavor of Chrome, otherwise, well, I have no idea what will happen.
Sometimes it's frustrating being a developer who's been around to see Mosaic supplanted by Netscape Navigator supplanted by Internet Explorer supplanted by Chrome/WebKit. Developers just love dumping one platform for the new shiny.
As I said last week, all of this has happened before and will happen again. The difference with this post is that I am not going to rant about lazy developers whining over a world that will still contain Internet Explorer and its offspring.
Instead, let's ask the average anti-IE / pro-WebKit developer a very simple question — on how many flavors of Chrome do you test?
I don't mean how many versions of Chrome. I also don't mean how many different WebKit-based browsers. No, how many flavors of Chrome?
I'll guess probably not more than a couple. I have four that I can, but typically don't, use. Even at four that's far too few.
Today Peter-Paul Koch pointed out that there are eleven (11!) flavors of Chrome (Chromia, if you will). All of them built on Chromium. Here's the breakdown from his article:
So maybe it's fifteen (15!) flavors of Chrome. Either way, I suspect that number will continue to grow.
Even if I include IE6, I only have to worry about 5 versions of Internet Explorer across mobile and desktop. If I want the idyllic WebKit-only world so many seem to crave, then I need about a dozen flavors of Chrome before I can get started with the Operas, Safaris, Yandexes, and Vivaldis (plural because those forks of WebKit also have their own versions to support)
Unlike other click-bait efforts that only speculated that perhaps Spartan was going to be WebKit-based, showing their own preference instead of any real understanding of the browser world, this one is filled with lots of great information. You should read it.
The first few comments, on the other hand, started off a mess (with many more on Twitter since the initial announcement). Two examples from the article:
So here was the opportunity to swallow their pride and join WebKit to make the internet a better place
…and they built *another* closed-source, proprietary rendering engine.
[Slow sarcastic clap]
« IE did shape the web in a positive way »
This made me laugh more than it should. You seem to forget why Internet Explorer has felt the need to change its name in the first place. And it’s not because it was «too good» or «too innovative»…
Many folks jumped in and corrected, down-voted, and generally balanced the insipid whining. Christian Heilmann, who has logged more years working for Firefox than most devs have logged using it, waded in to challengemany of theincorrect assertions.
Bruce Lawson, who happens to work for another browser vendor (Opera) noted all the things Internet Explorer did for the web in his five-year-old post In praise of Internet Explorer 6. It's also a cautionary tale about where reliance on a single rendering engine will take us.
What these two guys have in common, besides working for the competition, is that they have been on the web since its dawn. They've seen what happens when one browser gets too big (Internet Explorer) and how we spend the next decade-plus digging out from the mess.
How did we get into that mess? By people coding for one rendering engine.
Everyone who calls for WebKit in Internet Explorer is exactly the same kind of developer who would have coded to Internet Explorer 15 years ago (and probably happily displayed the best viewed in badge).
If you are that developer, then it will all be your fault when it happens again. When WebKit is no longer the hot engine. When Chrome loses its dominance. When Apple's market share falls to match the developing world. You will be to blame.
Screen shot from Microsoft's presentation on IE11 Enterprise Mode, showing what browsers are available on what versions of Windows. Note that the Venn-ish diagram has no IE11 intersection for Windows 8.
As of today, Windows XP has effectively reached its end of life. What I mean by that is that Microsoft will no longer be releasing security patches for Windows XP. Those of you waiting to deploy those XP exploits can run at the platform unopposed.
What's really annoying about this is that so many web-based applications were built to support the dominant browser(s) at the time — Internet Explorer 6 through 8. What that means is users on Internet Explorer 11 are being locked out of these online tools, making the transition away from Windows XP (which cannot have a version of IE greater than 8) a tough proposition for organizations.
Simply put, poor web development practices have created an environment where upgrading to the latest version of IE is directly at odds with keeping your productivity up (if it requires you to stay on an old version of IE). Complicate that by now making that old version of IE a vector for security breaches and compliance penalties/lawsuits.
But fear not! As long you have the hardware and licenses to run Windows 7 or Windows 8.1 (notice, not Windows 8), you can still use those Internet Explorer 8 web sites without being locked out (you're SOL if you need IE6).
With a week before Windows XP turns into a zombie, Microsoft released Enterprise Mode for Internet Explorer 11. After all, you only needed a week to get all that hardware in place and configured, right?
Enterprise Mode doesn't just emulate IE8, it masquerades as it. Some of the benefits of Enterprise Mode:
Enterprise Mode sends the IE8 user agent string to defeat misguided browser sniffers;
it mimics the responses IE8 sends to ActiveX controls, ideally allowing them to keep working;
it supports features removed from later versions of IE (CSS Expressions, woo hoo!);
pre-caching and pre-rendering are disabled to keep from confusing older applications;
IE8's Compatibility View is supported, so odds are many applications designed for IE7 will work.
Some web developers have panicked that now they'll have to support another browser or browser mode, but so far the evidence doesn't bear that out.
Enterprise Mode will be controlled by a central source, most likely corporate IT departments, and will only be enabled for sites that have been manually identified. Intranets and custom-built un-maintained web-based applications are an easy fit here. If an IT department deems it appropriate, it can also allows end users to decide to enable Enterprise Mode on a site-by-site basis.
Microsoft has been testing this in many industries and countries (though not China, the biggest culprit for old, and illegal, versions of Windows). Hopefully this will help speed users to upgrade to IE11, even if it doesn't provide motivation for organizations to upgrade their legacy IE8 applications.
With the demise of Windows XP (even though we know it's not suddenly gone today), Internet Explorer 6 is also at its end of life (because no supported platform can run it). We know that it won't go away completely, but it's still being celebrated at sites like IE6death.com.
There is a nifty tool at MQtest.io which gives you a breakdown of how your device reports features you might use for media queries. To use the tool's own explanation:
This test isn’t about what media queries your device can or cannot see (but it does show an 'unsupported' label if a device doesn‘t support something). Instead it shows you which dimensions your device will respond to when using ‘width=device-width,initial-scale=1.’
As one of the seemingly few owners of a Windows 8 tablet (specifically the Asus Vivo), I sometimes get asked to check sites to make sure that a developer's media queries work properly. It was testing my own site that led me to discover the prefixed styles that IE10 needs in Metro view (which lead to my surprisingly popular post, IE10, Metro, and Media Queries).
Armed with the features that MQtest.io can help identify along with a Win8 tablet, I figured perhaps others without a Win8 tablet could benefit from some screen shots showing the MQTest.io results in various configurations of Internet Explorer 10. Please bear in mind that the numbers are for my device, and probably will not match those you would get from a Microsoft Surface or another Win8 device. At the very least, however, these will show you what tests will run in Win8/IE10 and the types of values you can expect to see.
Screen shot of Internet Explorer 10 on Windows 8 in desktop mode, with the tablet turned horizontally (wider than it is tall).Screen shot of Internet Explorer 10 on Windows 8 in desktop mode, with the tablet turned vertically (taller than it is wide).Screen shot of Internet Explorer 10 on Windows 8 in Metro mode, with the tablet turned horizontally (wider than it is tall).Screen shot of Internet Explorer 10 on Windows 8 in Metro mode, with the tablet turned vertically (taller than it is wide).Screen shot of Internet Explorer 10 on Windows 8 in Snap Mode, with the browser in the narrow view.Screen shot of Internet Explorer 10 on Windows 8 in Snap Mode, with the browser in the wide view.
This post isn't proposing any solutions (although I do toss out a hack). This post is a rant that I hope helps influence browser makers.
Background
Much of my web work isn't for public facing web sites. Often it's for enterprise-level software that is deployed via the web and used in a web browser. I think any web developer who does anything beyond standard brochure-ware is ultimately in the same boat. Usually we need stylistic control over elements on the page that aren't typically considered exciting.
Once again I find myself working on a reporting feature for a large piece of software. Reports are typically grids (a table) made up of columns & rows with numbers, letters, icons, colors and so on. Clients are used to seeing these reports the same way they might see them in Excel, Crystal Reports, and similar tools.
These reports are formatted for quick visual scans to identify outliers and exceptions, so control over formatting is key to their effectiveness.
Example
Often these grids contain numbers of various lengths that include decimals. Often these decimal values aren't the same number of (significant) digits. Let me offer an example of wildly divergent numbers (I cannot show real client data):
Name
Number
Units
George
1,984.0
years
Arthur
42.000
?
Ray
451.0
degrees
Marie
13.51
g·cm−3
Isaac
6.67384
(× 10-11) m3 kg-1 s-2
Sergei
289.8001
billions of dollars
It's standard practice to align numbers to the right. The problem is that some numbers have decimals lengths that don't match other numbers, thereby throwing off the formatting and making the entire column harder to read than necessary. Note that the biggest number is the same length as the smallest number.
CSS to the Rescue
CSS3 has a solution. The property text-align has an option to solve our problem. It can accept a one character string as the character on which to align the text.
Not just a decimal, but a string. This is great news for languages that use a comma instead of a period for decimals. It's great news for very large or very small values where perhaps you want to align on the multiplication sign instead.
This style will allow me to align on the decimals in my example table: text-align: "." right; (the keyword after the string still keeps my numbers aligned to the right, after the decimal is factored in)
Browser Support
Now the question comes down to browser support. What browsers support it? None.
A Hack
To achieve the effect I want, I would have to split my numbers into two columns, one for the whole number and one for the decimal value. Like in this hack:
Name
Number
Units
George
1,984
.0
years
Arthur
42
.000
?
Ray
451
.0
degrees
Marie
13
.51
g·cm−3
Isaac
6
.67384
(× 10-11) m3 kg-1 s-2
Sergei
289
.8001
billions of dollars
This table isn't ideal. I have to clear out padding values, remove borders, and accept that my numbers are split. It is unnecessary work that could be avoided if the browser makers would just fully support an aspect of CSS3 that has been around for years and whose related styles already have seen support for even more years across prior CSS versions.
The extra styles, whether inline or with per-cell classes, also add to the overall page weight. HTML tables aren't exactly examples of slim mark-up to begin with, but this can bloat them even more.
This table is also an accessibility gotcha. Users with screen readers are used to a particular way tabular data is read, so this variation may not come across so clearly. Users who scale text may see odd baseline text alignment as text wrapping in other columns can throw off everything else.
It is likely that others who have needed to represent data with alignment on specific characters have just used images instead. That solution is far worse than even this hack, particularly from an accessibility perspective.
My Request to You
If you work for a browser maker, please bring this to someone's attention.
If you don't work for a browser maker, please share this (or your own examples) so that perhaps the browser makers will see there is a need, even if it's not as sexy as animations, transitions, WebGL, and so on.
Related
Even in the modern international web, the specification is sometimes too Anglo-centric, as in the case of the input type="number", which isn't as universal as hoped. You can read about the request to allow developers to set a pattern attribute on input type="number" to specify the thousand separator, decimal separator, decimal precision and if any special characters should be allowed.
There are also people calling for Mozilla to drop support for MathML, suggesting that people who don't use numbers in financial and scientific applications on a daily basis may not see the value in stronger support for number formatting.
The image on the left is IE10 in desktop view, on the right is IE10 in Metro view, both on the same device and at the same dimensions and screen resolution.
I worked pretty hard on our corporate site to test on as many devices and browsers as possible, trying to ensure that my media queries were solid and I was staying cutting edge without being bleeding edge. You might recall that I am already not a fan of testing in Internet Explorer emulation modes, but now I think I need to get the hardware to go along with my IE testing.
I recently picked up a Windows 8 tablet, making sure it had both the desktop and the (formerly-named) Metro interface. I set about testing the Algonquin Studios site in Internet Explorer 10 in both modes and was surprised to see that in the tablet / Metro mode my media queries were being mostly ignored (the site is built mobile first, so it honored the desktop queries). I took some screen captures and reached out to the Twitters for help.
This sounded familiar but I did some digging (now that I had some direction) and came across this note in a six-month-old MSDN article:
By default, Internet Explorer automatically scales content when the window is narrower than 1024px. This primarily includes the snapped state and portrait mode. If the @-ms-viewport rule is specified, it overrides default scaling.
In cases where scaling is not needed or desired, the device-width keyword can be used. This keyword signifies that the page is optimized to work well regardless of the dimensions of the window.
When using this keyword, make sure that the page continues to work well in a variety of window sizes, including the narrow snapped state and portrait modes.
My tablet's width is 768 pixels, so it definitely fell under the 1,024 pixels that trigger scaling. This note, however, doesn't provide any context for how this only affects IE10 in Metro mode, because the media queries clearly work fine when using IE10 in the desktop mode.
I excluded the zoom:1.0; from Roger's tweet, popped open my CSS file, and added @-ms-viewport { width: device-width; } right to the top of the file, outside of any media queries. I deployed it and all was well (I actually went through a full testing pass, test deploy, and the likes, but that part of the story isn't very interesting).
Perhaps everyone else already knows this and I am incredibly late to the game, but just in case there's someone who is stuck or doesn't have access to the right IE10 configuration, I hope this helps.
The lesson I learned here is that if I want to properly test Internet Explorer 10, I can't rely on a desktop installation on Windows 7 or Windows 8, I need to also test in the Metro interface and, ideally, on the appropriate hardware as well. Looking at my logs, I see more than a few users who have come to the site with an IE10/Win8 configuration who may very well have thought the site was not responsive.
For those interested, this screen capture shows my home page after deploying the CSS update:
IE10 in Metro view, after the CSS update. You can see that my media queries have fired.
Update: May 24, 2013
Thanks to Matt Stow's comment below (which demonstrated my clear lack of Google-fu), I now know of some resources online that have been down this path and also addressed the best approach to supporting Windows 8 Snap Mode (example of Snap Mode below if you are unfamiliar with this). It turns out that Windows Phone 8 has a bug which makes my solution inadequate, although there is a scripting fix in Matt Stow's article which you can layer on top of this. On to the links:
This screen shot shows the Snap Mode of Windows 8. As you can see, while playing my virtual accordion I decided that I absolutely had to also surf my company web site, which renders quite nicely thanks to the fix I implemented at the start of this article.
When I say "global," I don't necessarily mean the whole world, but really any aggregate pile of numbers for browsers that aren't culled from your own site or project.
With IE6 finally fading (which many developers will claim is a result of their IE6-blocking sites), the ire of developers has turned to Internet Explorer 7. Given that many web developers want to play with the new shiny (and not worry about supporting older browsers) or hate the extra work that sometimes comes with supporting older browsers, it's no surprise that disdain for IE7 is high.
It is with that experience that I think casually tweeting global stats and calls-to-action can be irresponsible without context, as this one on Friday:
Very surprised how many developers actively support IE7 despite it's miniscule usage now. Let's move on! twitter.com/paul_irish/sta…
Screen capture of Akamai chart with Safari, IE7 and IE10 highlighted.
The Akamai chart shows that IE7 is about on par with IE10 and even fares slightly better than Safari 6. The more discerning viewer might notice that Safari use goes up on weekends just a bit while IE7 use drops off for the same period, suggesting IE7 traffic might be coming from office workers.
Ignore Stats That Aren't Yours
A few people try to make the point that those numbers don't apply to their sites, some even try to make the point that this isn't about browser support at all:
@js_dev @paul_irish you're not supporting browsers, you're supporting customers. Job #1 is serving your customers.
As an example, I have a site I was working on last night that gets 7.3% of its traffic (over the last month) from IE7. That's about one in 14 users. I know I have to support users on IE7 because I look at the stats for the site, not because I look to Akamai, StatCounter, or anywhere else.
Here's the takeaway I want everyone to recognize: The only browser statistics that matter are those for the site you're supporting.
I feel so strongly about that point that I am going to quote myself just one sentence later:
The only browser statistics that matter are those for the site you're supporting.
This Applies to Other Stats
I've seen plenty of people discuss window sizes over the years and make generalizations about what sizes to support — even more common in the era of responsive web design. But global screen sizes are irrelevant. Instead, look at the numbers for the site you're supporting. Even better, look at the viewport size:
There has been a resurgence in discussion of late on print styles, but nobody seems to have any stats for how often users print pages. In the absence of raw data, developers talk about how they use sites and how their circle of contacts use sites. Instead, track it for your own sites and know when pages are being printed:
There are many other cases where developers look to global stats in lieu of tracking their own, but I haven't written tutorials for them. Now might be a great time to consider writing some of your own for the data points you want to capture.
While supporting your users, and by extension their browsers, is the best approach, it is possible to get so focused on browsers themselves that instead of cutting edge you end up doing the opposite (even if it takes time to become apparent). Take this example from the UK Department for Work & Pensions:
The service does not work properly with Macs or other Unix-based systems even though you may be able to input information.
You are likely to have problems if you use Internet Explorer 7, 8, 9 and 10, Windows Vista or a smartphone. […]
There is also a high risk that if you use browsers not listed below, including Chrome, Safari or Firefox, the service will not display all the questions you need to answer.
The supported list of browsers and operating systems are combinations of Microsoft Windows 98, Windows ME, Windows 2000, and Windows XP with the browsers Internet Explorer versions 5.0.1, 5.5 and 6.0, Netscape 7.2, Firefox 1.0.3, and Mozilla 1.7.7.
Why yes, Dominos, I'd love to tap again to get your real home page to order a pizza when I could have done it right here, below your over-sized app pitch that could be done in a tiny ribbon.
This may be old news to some of you, but I haven't found a place that collects this in one spot.
One of the most offensive experience I have when surfing a site on my mobile devices is being forced to click through an advertisement for the site's app in the iTunes store (even moreso when I am surfing on a non-iOS device). There is a fair number of sites I have tapped away from because of this (I also don't expect to be served the page I came to see, but instead shunted to the mobile home page).
If yours is one of those sites, whether promoting your entire user experience or just a product, there is a less offensive way to present your pitch to users on iOS and Windows Phone.
iOS 6
Safari on iOS 6 and later devices can promote your app with a standardized banner. Essentially you stuff a custom meta tag into your page that references your App Store ID. If the user already has the app installed, then the ad becomes a launcher instead.
Microsoft offers a similar feature for users of Windows 8 in non-desktop mode who are also using Internet Explorer. I have not tried it, so I cannot explain how this works as the user changes modes nor how it works with the "charms" feature of Windows 8.
This code is relatively simple as well, though it requires two meta tags and supports up to five:
In addition to Google Play, BlackBerry App World, I looked for similar features for the Firefox OS and Ubuntu Mobile stores. I know there are other mobile platforms out there for which I did not look.
If you know of other apps tores that offer similar features, please let me know so I can update this post.
Related
There are other places where custom meta tags are used to display targeted content. One example is used for Twitter Cards and another example is used with Google News. While you can build support for them, neither Twitter nor Google is going to use them unless you have been vetted in advance.
One of our spin-off companies, SWRemote, has an app available for iPads. There is value in promoting the app to visitors of the site but not in blocking their access to the site content with a splash page or an extra click, especially if they are not on iPads. The SWRemote web site is powered by QuantumCMS (yes, I am promoting our web content management system), which makes it about 30 seconds of effort to add the necessary meta tag to the site.
Screen shot of the QuantumCMS custom meta tag screen.
If you are already a client of ours on QuantumCMS, all you have to do is choose Site Configuration from the Settings menu and pop into the Marketing tab. This is the screen that allows you to add custom meta tags. Press the Advanced button and you are off to the races. In the Name field, for this example, I just entered “apple-itunes-app” and in the Content field I provided the custom ID for the app appended to “app-id=.” As soon as I hit Save the web site was showing the app bar to visitors:
Screen shots of the SWRemote site on an iPad3 both with the app installed and without it installed, showing how the bar changes its message.
Oddly, even though the app runs on the iPad Mini, which is running iOS6, the app bar never appeared on the site when viewed on the iPad Mini. On an iPhone 5, the app bar started to appear and then disappeared — probably as the device recognized that there is no iPhone version of the app.
If/when there is an app available for Windows Phone, the process to add this feature will be the same, allowing the site to promote both apps dependent on the audience. QuantumCMS helps make the process easier, with no need to code any changes to your site templates.
Update, March 8, 2013
What he said:
I think "Download our app!" is the new "Skip intro…"
Google has just announced that it may penalize sites that promote apps with those awful interstitials. Yet Google offers no solution (as you see above) for Android apps through the Google Play store. You can get more detail in my post "Google Needs to Provide Android App Interstitial Alternative."
Update: March 11, 2014
I told you above that you needed to get the app identifier and package family name to make the Windows app banner, but I neglected to tell you where to get that information. Some kind soul over at Adobe's forums provided instructions.
Update: August 31, 2014
I keep forgetting to link this: jQuery Smart Banner, which uses jQuery to stuff a Smart-Banner-like feature into your site for old iOS versions, Android and Windows. I have not tried, so I can offer no feedback on whether it works well (or at all).
When high contrast mode is enabled in the Windows OS, the sprite is not displayed (CSS background images are not displayed in high contrast mode).
This statement is made in a larger discussion of how to create appropriate fall-backs for designs that rely on CSS image sprites. He provides some handy scripts and techniques within the article.
Separately from this I saw a post yesterday on one of the Microsoft blogs titled -ms-high-contrast media feature that discusses a media query for Windows 8 and IE10 that will detect if the viewer is using high contrast mode (and which flavor).
The code is pretty simple and uses an -ms prefix to do its work:
@media screen and (-ms-high-contrast: active) {/* All high contrast styling rules */}
@media screen and (-ms-high-contrast: black-on-white) {
div { background-image: url('image-bw.png'); }
}
@media screen and (-ms-high-contrast: white-on-black) {
div { background-image: url('image-wb.png'); }
}
Clearly this isn't ready for prime time, and you'll still need to use techniques outlined in Faulkner's post, but it is a handy technique that I hope makes it into the spec and gets support from other operating systems and browsers.
Granted, web devs may still screw it up (as they have with accessibility and/or print styles for years now), but at least those worth their salt (and rates) will have another tool to better support users in various configurations.
In CSS Background Images and Accessibility by SSB Bart Group, the author makes the case that not relying on background images is the best approach for accessibility (offering alternative techniques to satisfy design requirements).
Currently, up to and including the jQuery 1.9 release (not out yet, but coming), jQuery actively supports the following browsers:
Internet Explorer 6+
Firefox: Current -1 version
Safari: Current -1 version
Opera: Current -1 version
Chrome: Current -1 version
According to jQuery's browser support page, any problem [in these browsers] should be considered and reported as a bug in jQuery.
As the jQuery team announced in its blog post, jQuery Core: Version 1.9 and Beyond, the 2.0 release (slated for early 2013) will drop support for Internet Explorer versions 6, 7 and 8. The 1.9 release will continue to support IE 6/7/8 and will even see parallel (to 2.0) development and bug fixes. There is even a code sample of conditional logic so developers can prompt browsers to load the appropriate jQuery library (based on IE browser, or not).
Readers have gotten a bit confused on this point, so much so that the jQuery team wrote a follow-up piece on Sunday, jQuery 1.9 and 2.0 — TL;DR Edition.
My concerns are two-fold. First, many web developers won't take the time to pay attention to the parallel track for 1.9 and 2.0 and may implement the new version as soon as it is available, penalizing users trapped on old versions of IE. Second, many web developers don't seem to know their sites' user base and may make ill-informed decisions to move up to the latest release (perhaps intentionally so), thereby penalizing users trapped on old versions of IE.
Looking at SitePoint's latest details on browser trends (Browser Trends July 2012: IE9 Strikes Back), and bearing in mind that every site on the web will likely have different numbers, we can see that IE 6/7/8 make up a combined 15.75% of users. In-your-head math tells you that for a site with a million users, that means 157,500 users will run into problems today if the site were upgraded to jQuery 2.0.
The browser numbers will likely change by early 2013, but perhaps not by much. If Microsoft's new forced updates work (The Skinny on IE's Update Policy) then this may all be a moot point.
Either way, site developers will still need to be smart enough to pay attention to their site statistics and respect those users who are trapped in a browser, instead of either forgetting about them or intentionally penalizing them.
As for why jQuery is making these changes, I understand both sides. Removing the bloat from the libraries by dropping IE 6/7/8 support should slim the files and reduce processing overhead. That's good for all non-IE users. The other side is nicely summed up in this tweet:
Yes, jQuery is bloated by IE fixes. But it's like a band-aid dropping support for wounds because the bleeding makes it difficult to stick
I like to think I'm pretty smart about web browsers, sporting four on my mobile phone and six on my desktop computer in regular day-to-day use. Heck, I even started the evolt.org browser archive back in 1999 with 80 unique browsers at the time (which I am pimping to the W3C Web History Community Group).
It's too early for me to review it, but I did run a quick check to see how it reports itself in the user agent string as compared to the browsers whose core rendering engines it is using. My results...
Trident
Internet Explorer version 9 reports itself as:
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Lunascape, when using the Trident rendering engine, reports itself as:
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2; InfoPath.3; Lunascape 6.7.1.25446)
Gecko
Firefox 12 reports itself as:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
When using the Gecko rendering engine, Lunascape reports itself as:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120410 Firefox/3.6.28 Lunascape/6.7.1.25446
Webkit
Chrome 19 reports itself as:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5
Safari 5.1.2 for Windows reports itself as:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7
Under the Webkit engine, Lunascape reports itself as:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.3 (KHTML, like Gecko) Lunascape/6.7.1.25446 Safari/535.3
Conclusions
It looks like Lunascape doesn't share the rendering engines for Gecko and Webkit with the browsers in which we've come to associate them.
Beyond that, I have no conclusions. I was just looking at the UA string and figured others might find it interesting and/or useful.
Every day I see examples of web developers allowing their ego to get in the way — trumpeting one browser over another, one technology over another, one methodology over another, and so on. These are typically not based on solid business or technical arguments. This week one stood out to me.
Paydirt
Earlier this week Paydirt proudly proclaimed We don't support Internet Explorer, and we're calling that a feature. The arguments speak more to the ease of the developers than its users. The author cites the difficulty trying to get sites to render pixel-perfect across various versions of various browsers, which demonstrates that he/she is missing the point about progressive enhancement. The writer also claims to be happier for it because skipping the dirty work of IE makes us very happy. Heck, I'd be happy to give up on some browsers, too, but that's not my job.
This proud proclamation comes early:
That's why we made a key decision at Paydirt: we don't support IE - at all - and we don't pretend to. You can't even sign up for Paydirt using IE.
Paydirt notes that it has received exactly zero requests for IE support, angry or otherwise. Given that the site targets graphic designers, developers and copywriters and shows the Macintosh UI in its software screen shots, it doesn't surprise me that only 1.63% of its traffic is from Internet Explorer. That low number of users is a far more compelling case to stop building support for any specific browser and instead to just rely on standards-based development.
However, had Paydirt done that nobody would have cared and there would be no press from it.
Microsoft
Rey Bango works for Microsoft promoting standards and IE's support for them. He's also a member of the jQuery Core Project Team, so he's no slouch on the code side. He tried to access Paydirt with Internet Explorer by adjusting IE's user agent string to get past a browser sniffer. His blog post Hey Paydirt: Your Site Works Just Fine in IE details some of the fun he had:
The signup was painless and I waded through the app with Chrome & IE side-by-side. As I went through, I didn't notice any differences in the functionality. Buttons worked as expected, data was being saved and even panels with fading functionality worked as expected.
He also found some vendor prefixes in the CSS, at least one of which was an -ms prefix. Not a big deal on its own, given how many developers leave code behind during updates, but it's clear that some of the shiny features were relying on browser-specific code that could have been achieved with standards-based markup.
What this response suggests instead is that Paydirt went out of its way to exclude IE. Instead of saving time by just supporting standards and ignoring IE issues, Paydirt spent time to exclude IE. That's not really a good way to argue that you are saving time by excluding a browser.
Some Guy (Bart van Zon)
I had decided that this little dust-up was over. And then today a link to this blog post came across my Twitter stream: Supporting IE Is Too Much Work.
It's a self-identified rant that nicely and succinctly summed up my thoughts (more succinctly than this post you might still be reading). The comments from developers complaining that it's too hard to test in Internet Explorer on a Mac seem to be what pushed him over the edge:
Seriously, if no slick way is a good reason not to test, you should be flipping burgers instead of developing. Your main job is development, not being a hipster. [emphasis added]
He notes that given the market share of Windows, not taking the necessary steps as a developer to set up a Windows/IE environment is unacceptable.
Last week Microsoft announced that it is planning to start upgrading users to the latest version of Internet Explorer that their computers can run (IE to Start Automatic Upgrades across Windows XP, Windows Vista, and Windows 7). Web developers for the most part were overjoyed with the notion that IE6, the bane of their existence, might finally be brushed aside.
But that's not what's going to happen.
Corporate
IE6 users in a corporate environment generally don't have a say in the browser they use. Typically if they have not been upgraded to a more recent version of Internet Explorer, it's for a reason. This reason can include anything from a customized version of the browser (yes, those exist) to an intranet/extranet application that was built to lean on the features of IE6 itself. When faced with the option of re-writing an entire application or just holding off on an upgrade, imagine which one is likely to win out (especially when weighed between the effort of the full rebuild or the effort of doing nothing). Back in March, ReadWriteWeb ran a poll with results showing that 29% of corporate users are still on IE6 with "no end in sight."
Microsoft makes Internet Explorer 8 and Internet Explorer 9 Automatic Update Blocker toolkits (for IE8 and for IE9) which allow enterprise environments to skip automatic installation recent upgrades. Since IE6 and IE7 aren't given their own opt-out toolkits and the process is still in the planning stages, it's hard to say how those two older versions will be addressed. It is likely, however, that corporate IT departments will err on the side of caution. It's already common practice for enterprises to decline to install updates and service packs because it may affect existing systems. These systems aren't necessarily built in-house, but are from vendors who themselves have not made any efforts to modify them in the years since IE7 came out (or have simply gone out of business). When an organization will not install Windows XP Service Pack 2 (late 2004), it is unlikely it is going to allow a browser upgrade.
Non-Corporate
There are other cases besides corporate environments where you may want to opt out — some assistive technology must be upgraded if the browser is upgraded. For example, upgrading to IE9 requires an upgrade to JAWS, Window-Eyes, Dragon Naturally Speaking and possibly other applications (Remarks on Internet Explorer 9 Accessibility and Compatibility with Assistive Technology). While this doesn't address IE6 specifically, each upgrade of IE has typically required other software updates for anything that relies on IE. These collateral effects sometimes make it cost prohibitive for an organization to upgrade even a free browser.
Microsoft's plan will affect users on Windows XP, Windows Vista, and Windows 7. Windows Vista and Windows 7 users aren't running IE6, so they're not going to contribute to any more IE6 market share drop. Some non-corporate users of Internet Explorer 6 are on genuinely old computers and aren't regularly updating their systems as it is. You may not see much of a drop there, if any. Couple this with the fact that Microsoft is not releasing recent versions of Internet Explorer for Windows XP, and those users will continue to languish on a permanently old browser, even if not IE6.
Asia
Microsoft's plan is also unlikely to address the Asian market, where China still sees IE6 running at a 28% installation base (versus 1.8% for Australia and 1.4% for Brazil, where Microsoft is rolling this plan out first). So many of those computers are running unlicensed copies of Windows XP, or are just older computers, that it is unlikely anyone will opt in for the automatic upgrades. While this may not affect most Western companies who don't do business in Asia, it is certainly inflating the numbers for IE6's installation base, and making international dreams for some companies seem a bit more daunting.
Conclusions
I feel like all I do is kill everyone's buzz whenever the coming demise of IE6 is promised. However, I've been killing that buzz for a decade now, so the odds are in my favor.
Microsoft's plan is a good one, and is no more than jumping on the bandwagon pulled by nearly all the other current browser makers. However, because Microsoft has a special place in the enterprise world and with its operating system dominance, I don't see this plan doing much to hasten the demise of IE6.
There seems to be no shortage of people making a comparison to Internet Explorer version 6, or IE6, as the simplest way to declare that something is an impediment to progress. Sometimes the criticism is levied with the understanding that at one point IE6 was the bees knees (In praise of Internet Explorer 6), but more and more people forget that and just treat it, and by extension the subject of the comparison, with derision.
Here are some examples with the comparison right in the title, blithely link-baiting the unsuspecting reader:
I'm not challenging the validity of these articles, some of them make some very good points and the comparison is apt. Having listened to non-tech people (the ones who use "HTML5" in conversation the way they used "DHTML") start to make these comparisons without any historic context, I think it's about time we as web developers came up with a new metaphor to flog. I kinda wish it was Netscape Navigator 2.
Remember Netscape Navigator 2, which brought us all sorts of innovations such as frames, cookie management, and JavaScript (nee LiveScript)?
People don't use Netscape Navigator 2 as an insult/comparison the same way because that browser didn't last more than 10 years in the wild (despite my best efforts), not to mention far too many people have never even heard of it now. IE6, on the other hand, has persisted thanks to too many developers targeting the browser instead of the standard, making corporate IT departments reluctant to move users to the next release. Let's not count the tie to the operating system and the inherent fear of upgrading from some sub-set of users.
Whatever your gripe with a technology, I think it's about time we only made the IE6 comparison when it is appropriate, not as a catch-all to something we don't like or that we think is making our job harder.
So let's start comparing things to Netscape Navigator 2 (Netscape 2, Navigator 2, NN2, NS2 and whatever other variants you want). Let's free IE6 from this burden and perhaps it will slip away into the night.
Amazon's long-awaited tablet/e-reader was formally announced today, and the conversations about whether or not it will compete the iPad are underway. I don't much care about that. I am far more interested in the web browser that it includes.
Amazon Silk is a new web browser, built on Webkit, and that is really the news of interest here. Add to that Amazon's super-proxy approach to help users get content more quickly and efficiently and you've now got a new pile of potential chaos as a web developer. It's far too early to tell how this will shake out, but in a client meeting today I already had to address it, so I think it warrants a little context for the current state of browsers so we can consider potential developer impact.
The 400+ comments raise some questions that tend toward a common theme — in the absence of a technical explanation, when can we get our hands on an emulator? Granted, there are plenty of comments about privacy, security, and some wild speculation, but the theme is clear.
As a web developer, I can tell you that we all feel overburdened with the assault of browsers we have out there already. We can champion the ideal of targeting the specs, not the browser, but when the clients call to complain about a rendering difference, not even a problem, on another browser it can get pretty draining. As Silk comes to market we'll need to account for it, its hardware configurations, and its coming release versions (within reason, of course).
For some context about the burden we already have, yesterday Google Chrome developer Paul Irish wrote that, only taking into consideration Internet Explorer for desktop, we're already on track to need to support 76 versions of just Internet Explorer (including version 8) through 2020. There are some broad assumptions in his article regarding how people will use the IE document modes, but the potential is still there. Add to that the new release schedule of many browsers (Firefox has gone from version 5 to 7 in ~90 days), and then pile on the browsers available for mobile devices, and we're already at well beyond the number of variations of browsers that we had to support even in the heyday of the browser wars.
But Silk isn't just a web browser — it's got a super-charged proxy server that will compress images, compile JavaScript into its own machine-readable format, and batch files into a singular, smaller download. While this is nothing new (Opera Mini has done this for some time on mobile devices), Amazon's implementation raises the hairs on the back of my neck when I think about all the years I've had to troubleshoot web applications because proxy servers are caching files, munging JavaScript, brutalizing images, and generally gutting the real-time features that the web had been moving toward more and more. I don't know if this will happen with Amazon Silk, but given my experience with Opera, proxy servers, and users in general, I am filled with apprehension.
Related
Opera responded to the Amazon Silk announcement with its own explanation of how its own "cloud-compression" technology works:
Earlier this week CBS News ran the above image on its site in the Tech Talk section (within the topic Wired for Women, which doesn't seem to have anything to do with women) under the article An infographic! If web browsers were wrestlers... As is common nowadays, any illustration with numbers and witty (or not-so-witty) accompanying images is being called an infographic, and this is no exception. I do think the title is a bit tongue-in-cheek and CBS knows that this image isn't exactly fact-based.
The firm CBS hired to develop the graphic ranked each browser by market share, innovation, flexibility and speed — all the important factors. I disagree, however, that these are the important factors. Innovation means different things to different users, for example. As a web developer, I might like new HTML5 support, but my dad might prefer bigger buttons and less clutter. I have a different set of factors that I think are far more important:
Performance: How well the browser can render a page without choking, whether by slowing down or introducing image artifacts, or just crashing.
Standards Support: With the constant revisions to the still-in-development CSS3 and HTML5 specifications, along with related specs, this is even more important given the moving targets.
Ease of Use: This includes accessibility and usability. Can my mom use the browser without having to call me? On top of that, how about a power user, how easy to use is it for that audience?
Install Base: This is more than just who has chosen to download it, but should include who is forced to use it by corporate policy, lack of technical knowledge, hardware limitations, or public access.
I found another image that I think more accurately reflects the state of the battle between browsers (it rightly ignores Rockmelt and portrays Internet Explorer appropriately):
Bit Rebels took an old illustration of browsers as celebrities, posted it, and claimed it as an infographic: If Web Browsers Were Celebrities [Infographic]. It may be time for a web-wide infographic intervention.
I try to stay up on accessibility gotchas and weird browser implementations, but I just discovered one that I suspect I should have already known.
Currently, up to and including the 
Every day I see examples of web developers allowing their ego to get in the way — trumpeting one browser over another, one technology over another, one methodology over another, and so on. These are typically not based on solid business or technical arguments. This week one stood out to me.
