Friday, May 24, 2013

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.

Wednesday, May 22, 2013

IE10, Metro, and Media Queries

IE10 in desktop view. IE10 in Metro view.
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:

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

Screen shot of Windows 8 Snap Mode in use.
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.

Update: July 31, 2014

In today's Twitter chat with IEDevChat, people are still asking why @-ms-viewport is needed.

As for reported issues with width: device-width, looks like we'll have to wait until Monday to know any more:

Sunday, May 19, 2013

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:

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

Tuesday, May 14, 2013

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

Balancing Act: Features, Budgets & Timelines
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…

Thursday, May 2, 2013

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:

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:

Akamai chart.
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:

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.

Related

My Previous Rants

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.