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.

My Presentation Slides: Making Your Site Printable

On Friday, May 17 I had the pleasure of speaking for the first time at Stir Trek, a one-day conference in Columbus, Ohio, that drew over 1,200 attendees (and I understand sold out in just a few minutes). Apparently the name is a reference to the MIX developer conference, for which they were unable to obtain license to use a variation on the name.

I also had the pleasure of presenting for the first time on best practices for making your web site printable, built from my own professional experience, my PrintShame site, and an article I wrote for .net Magazine, among other resources (also linked in the presentation).

With 40 great speakers across 8 different tracks, there was quite a lot on offer throughout the day. Considering the other presentations held at the same time as mine, I was thrilled to get any audience and more excited to see that those who attended saw value in the topic and asked great questions throughout.

As promised in the session, I have made my slides available online via SlideShare and embedded them here:

Well after the talk I got even more questions and feedback on the session, which I truly appreciated. Since there is no official survey for attendees to give feedback on a speaker, I am hoping any attendees will feel comfortable tweeting about it or leaving a comment here. So far I have gotten one great bit of feedback on Twitter:

Lest anyone think I'm just terminally negative, @aardrian had a REALLY GOOD talk on accessibility. And printability.

— David Longshore (@DavidLongshore) May 17, 2013

(I worked in some accessibility tips during my presentation.)

All other feedback is welcome (including if I was loud enough when the lavalier microphone failed).

While in Columbus I also had the pleasure of having a nice dinner (I arrived too late to make the speaker dinner), visiting the North Market, and, as part of the conference, getting to see a double feature of Iron Man 3 and Star Trek: Into Darkness. All around a good time which I look forward to repeating next year.

Balancing Act: Features, Budgets & Timelines at Web Standards Sherpa

As of today I am an author over at Web Standards Sherpa. I wrote an article discussing the process of juggling a no-budget, tight-timeframe web site for Buffalo Soccer Club while still trying to adhere to best practices. The article is titled "Balancing Act: Features, Budgets & Timelines."

I get a chance to talk about responsive design and even rant just a little bit about print styles (the article itself prints well, too). The article also has the nifty ReadSpeaker feature which means that the page can read the article aloud to you in a voice that is entirely unlike mine (at least it's a male voice by default).

Adrian offers insight into the decision process of building a new site for the Buffalo Soccer Club, a not-for-profit with little to no budget and a looming deadline. Read it…

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.

WWW Project Turns 20

Twenty years ago, on April 30 1993, CERN announced the World Wide Web project. While the web existed before then, this was the first time that HTML's specification was opened up to the general public, allowing anyone to learn how to mark up documents.

Eight days and twenty years ago, Mosaic 1.0 was released (you might recall I wrote up a little tribute). In the span of about a week, the first generally-available web browser and the first publicly-available HTML specification were both announced, all culminating in this very blog you are reading now (amiright?).

In honor of this, CERN has re-posted its web pages explaining the project.

CERN has created a companion site about the restoration of this first web site, where you can contribute and stay on top of ongoing progress to restore more of those early days of the CERN web environment. There is also an interview with Robert Cailliau as he reflects on the past 20 years. The BBC provides some coverage on its site, including some clips from its 20-year-old coverage. .net Magazine has an interview with Mark Boulton who has helped CERN with getting this site up.

I thought that it might be interesting to see those CERN pages using the web browser released at about the same time. Sadly, due to Mosaic 1.0 not supporting host headers, and due to the CERN site being overloaded today, I was forced to spider the pages and surf from local copies. Other than the address bar, however, these screen captures still load the same HTML.

NOTE: I plan to also show screen captures in a modern browser and a mobile browser, along with links to these pages so you can see them for yourself, but with the CERN site timing out, I'll have to add them later. There is a mirror available, however.

Screen Captures in Mosaic 1.0

You may click/tap/select each image to see a full-size version (800 × 700).

The World Wide Web project.

Technical Details.

HyperText Mark-up Language

Tags used in HTML

Hypertext Markup Language

Future plans for HTML

Screen Captures in Firefox 20

You may click/tap/select each image to see a full-size version (800 × 700).

The World Wide Web project.

Technical Details.

HyperText Mark-up Language

Tags used in HTML

Hypertext Markup Language

Future plans for HTML

Screen Captures in Chrome on a Nexus 7 tablet

You may click/tap/select each image to see a full-size version (800 × 1280).

The World Wide Web project.

Technical Details.

HyperText Mark-up Language

Tags used in HTML

Hypertext Markup Language

Future plans for HTML

NCSA Mosaic Turns 20

20 years ago today (yesterday), NCSA Mosaic 1.0 was released (read Marc Andreesson's announcement on www-talk). Mosaic was the browser that opened the web to the masses, making the web more interesting for people like me.

As a college student who used Usenet, FTP sites, struggled with WAIS, Archie and Veronica, and had fallen in love with the ease of Gopher, the web was still just out of arm's reach for me. With Mosaic came the ability to see pictures directly in the page content — a whole new world for someone used to accessing the internet via only dumb terminals up to that point.

I had forgotten all about it until I saw this tweet from @mattur:

NCSA Mosaic 1.0 released 20 years ago today: 1997.webhistory.org/www.lists/www-… #webhistory

— mattur (@mattur) April 21, 2013

With this post, I'm not bringing anything new to the Mosaic story (at least no more than you get from this three-year-old Wired article on Mosaic), but instead I am taking time to remember that while it may seem like an eternity in web years, it still feels like yesterday that I was downloading Mosaic and trying the web seemingly for the first time.

You can also re-live at least part of this experience.

Download a Copy of Mosaic 1.0

Back when I became an ecommerce developer, less than 4 years after the release of Mosaic, I started an archive of browsers so that I could test the applications I was building in more than just the client's favorite browser. As time wore on and my collection grew, I created the evolt.org browser archive so that everyone could have access to any browser.

If you want to run NCSA Mosaic 1.0 and relive the early days of the web (even though few pages will render at all), just grab a copy of Mosaic 1.0 from the archive and fire it up. It turns out you don't need Windows 3.1 to run the Windows version, it will run just fine (mostly) under Windows XP, or in my case a Windows XP virtual machine.

Mosaic Screen Shots

NCSA is kind enough to offer a screen shot of Mosaic 1.0 for Windows so that you can see how awesome it was:

Screen shot of Mosaic 1.0 from the NCSA web site.

Sadly, that page on the NCSA site doesn't exist anymore. Visiting it in Mosaic 1.0 today gives you a funny-looking page. The browser uses the Mosaic icon for missing images and the full text of the Google Analytics tracking code is displayed (so they'll never know I was here):

Screen shot of Mosaic 1.0 today while surfing the NCSA site.

Even spending a few minutes in Mosaic, unable to surf most sites, will give you some insight into the early days of the web. There was no text styling. If you as a site owner wanted to enforce fonts or colored text, you couldn't. However, as a user of Mosaic, it was very easy to specify the font styles for different block-level elements within a font menu.

Eagle-eyed readers might notice a "Header 7" option:

Note the ability to change font settings for block-level elements.

Related

If you find this kind of stuff interesting, the W3C has a Web History Community Group where you can help out with the challenge of archiving an incredibly fluid medium, and preserving a little bit of history in the process.

Yep, somebody made a page that tracks Mosaic logo sightings.

As John Allsopp points out, nobody responded to the original email announcing Mosaic 1.0, perhaps setting the tone for browser discussions for years to come:

@brucel @aardrian @evolt_org @mattur there seems to have been no reply on the thread!

— John Allsopp (@johnallsopp) April 22, 2013

Update: April 30, 2013

Just over a week later (from the launch of Mosaic and from the this post), CERN has re-posted its 20-year-old WWW Project site which helped provide everyone with an understanding of HTML so they could make their own sites. I have a write up, with screen captures in Mosaic 1.0, on my blog.

Chrome: Blink and You Missed the News

It's old news by this Thursday morning, but in case you had not heard, Google is forking WebKit to make its own rendering engine, Blink. Opera will be using the Blink fork of WebKit as its rendering engine.

A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn't offer my opinion, however.

I will format this the way I did when I provided my in-depth analysis of Opera's move to WebKit (away from Presto) less than two months ago.

So what does this really mean?

For Developers

Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.

Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.

If you aren't sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post "WebKit Will and Won't Be the New IE," where I provide a high-level overview of these variances.

For Users

At this point it doesn't mean a whole lot.

Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won't be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to "WebKit Will and Won't Be the New IE" for how poor testing can impact users, but that's not a function of the engines.

Because Apple only allows WebKit on iOS devices, and even then it restricts those browsers to a different JavaScript engine and thus a lesser experience, Chrome and Opera for iOS may still stay on WebKit. Over time as its harder to incorporate features from Blink back into the WebKit core, there may be feature divergence which may affect users.

That's just speculation on my part.

For Standards

For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.

With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto's wind-down (to be fair to Presto, it's expected to exist in the wild until 2020, but with no new feature development).

I am hoping that this is a good thing for standards.

Blink won't be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.

Technical Aside

From Peter-Paul Koch:

Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.

Related

First some bits from The Twitters:

Let's bring back the Netscape engine and call it Spacer! RT @codepo8: After blink Microsoft might bring out a new engine called marquee

— Adrian Roselli (@aardrian) April 4, 2013

And *this* is how you fork a repo.

— Sylvain Galineau (@sgalineau) April 3, 2013

Can the new Blink logo be >_<?

— Mike Taylor (@miketaylr) April 3, 2013

And now to the related links:

• Blink: A rendering engine for the Chromium project, April 3, 2013.
• Developer FAQ, The Chromium Projects.
• Hello Blink, from Bruce Lawson (who clearly hates Morrissey doesn't care for most of Morrissey's solo work).
• Hello, Blink! from Paul Lewis
• Discussion on Hacker News about how Google controls WebKit.
• Well, err, that solves the WebKit monoculture problem, from Jake Archibald.
• Google Announces Blink, Its Own Rendering Engine For WebKit. at Read Write
• Blink from Robert O'Callahan.
• Discussion on Hacker News started from Apple's perspective.
• Google going its own way, forking WebKit rendering engine at ars technica.
• Just One WebKit from James Socol.
• Why What You’re Reading About Blink Is Probably Wrong from Alex Russel.
• Blink. Chrome’s new rendering engine from Eric Bidelman.
• [webkit-dev] Cleaning House thread at the WebKit mailing list in the wake of the Blink news, along with the announcement on the list.
• A Short Translation from Bullshit to English of Selected Portions of the Google Chrome Blink Developer FAQ from Rob Isaac.
• Blink from Peter-Paul Koch.
• Another first by Opera! from WebKit Memes.
• Thoughts on Blink from Krzysztof Kowalczyk.
• Welcoming Blink, Chromium’s new open source rendering engine from Peter Beverloo.

There's this one from 2010 by Haavard Moen that I thought worth highlighting: "Dear Google: Please fork WebKit."

Update, 5:35pm

A video Q&A from Google Developers about Blink (time markers available on the Chromium blog).