Screen Shots of Win8/IE10 Media Query Values

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 que­ries your device can or cannot see (but it does show an 'unsupported' label if a device doesn‘t support something). In­stead it shows you which dimen­sions your de­vice will res­pond 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.

Read More

My Kingdom for Decimal Alignment on Numbers

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.

Read More

IE10, Metro, and Media Queries

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.

Roger Johansson was kind enough to help:

@aardrian You may need @-ms-viewport {width:device-width;zoom:1.0; }

— Roger Johansson (@rogerjohansson) May 22, 2013

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:

• IE10 Snap Mode and Responsive Design, OCtober 17, 2012 by Tim Kadlec.


• Windows Phone 8 and Device-Width, January 14, 2013 by Tim Kadlec.


• Responsive Design in IE10 on Windows Phone 8, January 6 2013 by Matt Stow.

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.

Update: October 15, 2013

Matt Stow reports that Microsoft has fixed the Windows Phone 8 viewport issue.

Read More

Don't Use Global Browser Stats

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…

— Paul Irish (@paul_irish) April 26, 2013

This tweet lead to the usual self-congratulatory responses of how it's a web developer's responsibility to force users to upgrade, old browser support is just a false assumption from the client (and maybe that client should be fired), money is being thrown at the wrong problem, IT departments are just jerks, and so on. While Paul clarifies in a follow-up tweet that he still thinks the content should be accessible, that point is lost as a tweet response instead of a tweet all his followers will see.

Competing Stats

Some responses were more thoughtful and based on a different source of global stats:

@paul_irish on the other hand, IE7 still has significant marketshare according to Akamai akamai.com/html/io/io_dat…

— David Storey (@dstorey) April 26, 2013

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.

— Nicholas C. Zakas (@slicknet) April 26, 2013

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:

• My Viewport Sizes

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:

• Tracking When Users Print Pages

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.

Related

• On Browser Support, by David Bushell, April 26, 2013.

My Previous Rants

• Let's Treat Old Browser Users Better, July 5, 2012


• Another Anti-IE Gimmick, June 14, 2012


• Exclusion Is a Feature Now, May 10, 2012


• Don't Blame Opera, Blame Devs, April 27, 2012


• The Return of “Best Viewed in…” March 4, 2012


• Don't Expect Microsoft's Auto-Update to Kill IE6, December 23, 2011


• Test in Lynx and Print, It's Your Job, December 12, 2011


• Everything Will Be the New IE6, December 8, 2011


• Selection Bias When Reviewing Browser Stats, March 13, 2011


• RIP IE6 (Not Really, But Here's to Hoping), March 4, 2010

Going the Wrong Way

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.

Read More

App Store Meta Tags

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.

The code is pretty simple:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

• app-id is required and references your app's identifier.


• affiliate-data is optional and uses your iTunes affiliate string.


• app-argument is also optional and can allow users who have your app installed to jump to a specific place in your app.

More details at Apple's developer site: Promoting Apps with Smart App Banners

Windows 8

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:

<meta name="msApplication-ID"content="microsoft.build.App"/>

<meta name="msApplication-PackageFamilyName"content="microsoft.build_8wekyb3d8bbwe"/>

• msApplication-ID is required and references your app's identifier.


• msApplication-PackageFamilyName is required and contains the package family name created by Visual Studio.


• msApplication-Arguments is optional and lets you pass arguments to your app.


• msApplication-MinVersion is optional and can direct users with an old version to the Windows Store.


• msApplication-OptOut< is optional and allows pages to opt out of installing the app, switching to the app, or both./li>
  

More details at Microsoft Developer Network: Connect your website to your Windows Store app (Windows)

Google Play, BlackBerry App World, Etc.

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.

Updated: January 29, 2013

I wrote a version of this post with an example at the Algonquin Studios blog. I'm pasting the example in here...

Real-World Example

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…"

— Jeffrey Veen (@veen) March 8, 2013

Update, April 24, 2013

There is a recap of recent rants over at .net Magazine in the article "Devs rally against mobile web doorslams."

Update: June 12, 2013

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."

Read More

CSS Background Images & High Contrast Mode

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.

In Steve Faulkner's post, Notes on accessible CSS image sprites, he tosses out a factoid that was new to me:

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.

Related

• Techniques for High-Contrast-Friendly Icons

Update: November 8, 2013

With coming support for the luminosity media query in CSS4, perhaps you can re-use some of your work for high contrast mode or vice versa: Responding to environmental lighting with CSS Media Queries Level 4

Read More

Changes to jQuery Browser Support

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

— Jake Archibald (@jaffathecake) June 29, 2012

Read More

Three Browsers in One: Lunascape

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).

But then this tweet came through my timeline:

Turns out there is a three-engine WebKit/Gecko/Trident browser en.wikipedia.org/wiki/Lunascape Uh.

— Sylvain Galineau (@sgalineau) May 24, 2012

How did I miss this?

So I went to the Lunascape Wikipedia article, and then to the Lunascape English site and promptly downloaded it.

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.

Read More

Exclusion Is a Feature Now

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.

I completely agree.

Related

• Reaction to Paydirt's declaration at Hacker News.


• Reaction to Bart van Zon's piece at Hacker News.

I have a long history of ranting at lazy developer techniques:

• Don't Blame Opera, Blame Devs, April 27, 2012.


• Announcing PrintShame.com, April 9, 2012.


• The Return of “Best Viewed in…”, March 4, 2012.


• Browser Makers Caving to Vendor Prefix Misuse, February 9, 2012.


• Test in Lynx and Print, It's Your Job, December 12, 2011.


• Everything Will Be the New IE6, December 8, 2011.


• More Samples of Responsive Web Design ≠ Print, October 13, 2011.


• Print Styles Forgotten by Responsive Web Developers, October 3, 2011.


• Testing IE Versions via IE Compatibility Modes, June 6, 2011.


• Selection Bias When Reviewing Browser Stats, March 13, 2011, where I also spoof my IE UA so I can get into a site that blocks IE for no good reason.


• Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea, February 9, 2011.


• Google's Web Book May Not Help Those Who Need It Most, November 29, 2010.


• To Hell with Bad Editors, February 28, 2001.


• You Call That Web Site Testing? July 11, 2000.

Read More

Don't Expect Microsoft's Auto-Update to Kill IE6

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.

Related

• Internet Explorer to auto-update at .net Magazine.


• Web Developers Rejoice! Microsoft is Killing IE 6 and 7. at Reddit.


• Microsoft decides to automatically update Internet Explorer for everyone | Hacker News

Not really related, but this handy diagram shows where IE6 fits into the current world of the web:

Read More

Everything Will Be the New 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:

• Is Google Chrome the New IE6?, December 2, 2011.


• JVM 5 is the new IE 6, October 31, 2011.


• Browser Market Pollution: IE[x] is the new IE6, September 27th, 2011.


• iPad Is the New IE6, January 31, 2011.


• IE 8 is the new IE 6, October 11, 2010.


• The iPhone is the new Internet Explorer 6, says mobile developer, February 8, 2010.

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.

Somewhat Related on this Blog

• Microsoft Promoting the Death of IE6


• Enough about the Death of the Web

Read More

Amazon Silk, Yet Another Web Browser

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.

Amazon posted a video on its brand new blog to provide an overview of Silk (with an obligatory Geocities reference):

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:

• Amazon’s Silk Web Browser Adds New Twist to Old Idea at ars technica.


• Amazon Launches Silk Web Browser for Tablets at Mashable.


• Amazon Silk browser spins a faster mobile web, courtesy of cloud servers (video) at Engadget.


• Opera: Amazon's Silk Browser is Flattering, But Five Years Late at PCMag.


• Amazon's Silk Browser May Not Be Smooth When It Comes to Privacy at PCWorld.


• Amazon's Silk browser one-ups Opera's approach to the Web at InfoWorld.


• The Implications of Amazon's Silk Web Browser at ReadWriteWeb

Read More

Browsers as Wrestlers "Infographic"

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:

1. Performance: How well the browser can render a page without choking, whether by slowing down or introducing image artifacts, or just crashing.


2. 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.


3. 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?


4. 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.

CBS gave each browser a chance to respond/defend itself, specifically Firefox, Chrome, Internet Explorer, Opera, Rockmelt, and Safari. Opera even took it a step further and wrote up a response on its blog, Speed, Innovation, and Flexibility in the Ring.

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):

Credit for the above image goes to Galit Weisberg, from The Shoze Blog. Now go to TechCrunch and tell MG Siegler that he stole the image.

Update August 25, 2011

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.

Read More

Testing IE Versions via IE Compatibility Modes

This past week I have encountered people asking about testing for Internet Explorer browser versions in real life, on Twitter, via email, and spray-painted under a bridge (along with the phrase I don't want the world, I just want your half). I have seen response after response directing web developers to simply use the different browser modes in Internet Explorer 9 for browser testing, in particular addressing those who are using Macs and do not want to install multiple versions of Windows for each browser instance.

I whipped up some HTML and CSS of the most basic (and invalid) sort to run my installations of Internet Explorer through the paces. Historically I have found subtle differences between the emulation modes and how the original version of a browser (specifically IE) might render a page. This time out I simply found the emulation mode testing process so confusing that I suspect many developers who rely on this method are doing it incorrectly.

Four Versions of Internet Explorer

These images represent screen shots from Internet Explorer versions 6, 7, 8 and 9 — the full install version of each, using default settings, no emulators. For the most part we can see differences between IE6, IE7 and IE8, while the differences between IE8 and IE9 are negligible.

Internet Explorer 6

Internet Explorer 7

Internet Explorer 8

Internet Explorer 9

You can see that IE6 has trouble with the 24-bit transparent PNG files, and both IE6 and IE7 apply the padding to the wrapper element differently than IE8 and IE9 do. IE6 is also not setting the height of the element that is the green box, but from IE7 onward the height declaration is honored.

Internet Explorer 9 as an Emulator

The problem is that once you install IE9 you are kind of stuck. Unless you are willing to spin up a virtual machine for the last few versions of IE you want to test (and I still recommend you at least see how IE6 will munge your pages), you have to rely on emulators. Many developers think that IE9 will allow them to see how older versions of the browser saw pages, and to some extent it will. The confusing part is that not only is there a Browser Mode setting, there is also a Document Mode setting. Using combinations of those two settings, I generated the following screen shots:

Internet Explorer 9. Browser Mode: IE7. Document Mode: IE7.

Internet Explorer 9. Browser Mode: IE8. Document Mode: IE7.

Internet Explorer 9. Browser Mode: IE8. Document Mode: IE8.

But those aren't all the modes. You can also run the browser in the following slightly confusing modes. You might notice that "Quirks Mode" most closely resembles the rendering in IE6 above, without the issues displaying PNG files. This is as close as you can get to testing IE6, and even that doesn't do justice to some of the rendering issues of that rather old browser.

Internet Explorer 9: Quirks Mode.

Internet Explorer 9: IE9 Standards Document Mode

Assuming you simply toggle the "Compatibility Mode" in IE9, which of all the above combinations do you think you'll get? Or better yet, how do you think your page will render? This experiment shows that it most closely resembles the rendering used for its IE7 browser and document modes. I would have expected it to use IE8, or at least some clear indication of which browser version it is trying to emulate. This example alone shows that even a quick cross-browser test in IE9 to test older versions of IE may provide unexpected results.

Internet Explorer 9: Compatibility Mode.

Even if you understand all the document and browser modes available in the IE developer tools, that doesn't mean your web staff, client, or random web savvy user will. The best way to truly test how a site renders in older versions of a browser is not by running emulators, but by running the versions of those browsers themselves.

If you still insist on going down the path of testing using emulators, you should take a few minutes to read the Microsoft article, Testing sites with Browser Mode vs. Doc Mode. The article outlines what each of those settings means and how it adjusts the rendering of the page.

The article makes an assumption, however, that as a developer you will want to serve up different doctypes and meta tags based on how the browser reports itself in the user agent string as defined by the Browser Mode. This image illustrates that:

If you do have a site that adjusts itself based on the browser, given the extra steps to configure the browser, test and compare differences, it's still probably easier and definitely fool-proof to use the specific version of IE that you want to test. This way you don't have to worry about incorrectly read UA strings or mis-selected settings in your browser emulator.

Conclusion

Suck it up and install some virtual machines to get each version of Internet Explorer for testing.

Update: February 4, 2013

Microsoft has made virtual machines with old IE versions available to developers at its Modern.IE site. There really is no excuse now to claim you can't test in older versions of Internet Explorer.

Update: March 14, 2013

Typekit points out the dangers of cross-browser testing with IE9′s Browser Modes when it comes to font rendering. Typekit comes to the same conclusion as I do: Instead, you should test with real installed copies of IE7 and IE8[.]

Update: March 15, 2013

Found this post on Stack Overflow, dated just a couple months before I wrote this post: How well does IE7/8 mode in IE9 compare to actually running IE7/8? Many specific issues there.

Read More