Generated Content by David Storey

IE11: what we know and what we can speculate

Fri, 05 Apr 2013 13:56:00 -0700

A build of Windows–codenamed Windows Blue–was leaked onto the internet recently. What does this tell us about what is coming in IE11?

First a disclaimer: the information in this post all comes from public sources. I have not run the leaked build myself, and although I am helping Microsoft with the userAgents community, I have no inside knowledge of current or future plans for IE11. This post is a distillation of these various posts, and my personal opinion or speculation.

A new identity

The first news about IE11 was that it has a new user agent string:

Mozilla/5.0 (IE 11.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko

There are two significant changes to this string:

MSIE has been replaced by IE
A like Gecko token has been added

The former is clearly to avoid getting the code branch designed for IE when sites use browser sniffing (a practice that causes untold damage). These are almost certainly designed for older versions of IE, such as those that don’t support addEventListener or other standards-based features. IE is saying it no longer wants legacy IE code. It wants standards-based code.

The latter has caused some confusion. It was reported that IE is pretending to be Firefox. This is only partially true. It is correct that Gecko is the name of Firefox’s rendering engine, but like gecko was the token added by WebKit. The reason why WebKit added it, and now also IE, is sites often didn’t say “do you want the IE-specific code or the standards-based code?” They often instead said: “Are you IE or are you Gecko?” It is not a question of if you support the standard, but if you are called Gecko. Even though WebKit is widely popular (as is IE), these sites and practices still persist, so the token is still needed. IE is basically taking a page out of WebKit’s playbook, which is asking for the Gecko branch. What IE will not get with this string is the sites specifically sniffing out WebKit. I suspect it doesn’t want these, as these code paths probably often include WebKit specific code or prefixes. Especially on mobile sites. Pretending to be Gecko gives less risk of vendor specific code, as it is not a reliable way to detect just Gecko-based browsers due to WebKit making the same move.

Changing the UA string is not the only way current builds of IE11 are cloaking their identity. The appName property now returns Netscape rather than Microsoft Internet Explorer. WebKit and Gecko already do this. IE and Opera/Presto were there only ones that didn’t identify as Netscape, but as the latter is switching to Blink, everyone is now Netscape.

Finally on the identity front, IE11 is now cloaking support for document.all. If you use feature detection to detect support for this feature, IE, like Firefox, WebKit, and Opera, will say false. Why? Isn’t object detection the holy grail? Yes, but, developers were ::drumroll:: using object detection to browser sniff. What? While working on Opera compatibility, I’d often (more times than I can count) see code like this:

var isIE = null;
if (document.all) {
 isIE = true;
}

if (isIE) {
  // do some crazy IE specific stuff with ActiveX, or filters or so on
} else {
  // use standards based code
}

Now all of a sudden, if you support document.all, you are obviously IE and want to use totally non-related code. Cloaking support for document.all avoids this.

The other possibility is to remove support entirely, but sites would often use it without testing for support, and not have an alternative path, leaving sites broken. Cloaking generally gives you the best of both worlds, and is now an ubiquitous practice amongst browser vendors.

Update: IE11 now cloaks support for the ActiveXObject object, almost certainly for the same reasons as already outlined.

You have to bear in mind that all these changes happened in a leaked build of IE11. It could be that the developers are just experimenting to see if the identity changes break more than they fix. It should not be held as gospel that these changes will make it into the final version of IE11.

There is one key significance to all this. Microsoft is telling the world; IE has grown up, it is standards compliant and is capable of supporting the standards branch on sites. We no longer want the IE code paths. I’m inclined to agree. IE10 is a huge step forward, and IE11 probably will be able to go toe to toe with the competition in terms of standards support.

ES6 support

A few features from ECMAScript 6 (the next version of JavaScript) appear in the leaked builds:

proto

The __proto__ property was non-standard, and looks really ugly to my eyes. It references the prototype of the object. The spec represents this as [[Prototype]], but there was no standards-based way to access this. ES6 changes this by standardising __proto__.

IE11 now supports this feature, along with Firefox, WebKit and Opera.

WeakMap

A WeakMap is a key/value pair map, where the key is an object, and if there is no longer a reference to the key object, it will be available to be garbage collected. Due to this behaviour, WeakMap keys are not enumerable. One specific use case for WeakMaps is to keep references to DOM nodes. When a DOM node is deleted from the document, it can be garbage collected and thus automatically removed from the map. This can reduce memory requirements.

Support for WeakMap is included in IE11, Firefox, and behind a flag in Chrome.

Update: Set

Support for Set objects has appeared in the latest leak. A Set holds a collection of values, but unlike data structures like an Array, a Set can not contain duplicates. For an excellent look into Set objects, check out Nicholas Zakas’ blog post ECMAScript 6 collections, Part 1: Sets.

Support for Set includes IE11, Firefox, and Chrome (behind a flag).

Update: Proprietary Mozilla APIs

Along with __proto__ which was until it was recently standardised, was a proprietary Mozilla invention, IE11 has added support for __defineGetter__ in the latest leaked build. This is a legacy feature, which has been standardised as Object.defineProperty in ES5. Why add a legacy feature when there is a standard that replaces it? One reason: compatibility. There is a bunch of code out there that uses __defineGetter__ without a non-legacy IE fallback. One of the reasons Opera added __defineGetter__ is that some frameworks and sites (Atlas being one I remember) would use it to add functionality.

In the case of Atlas it implemented everything using legacy IE API, and the “standards” based path was basically a polyfill for Firefox using __defineGetter__ to implement those APIs. If you didn’t support it, you just received a broken site. Now, that was a pretty backwards was to develop, but the feature was (and probably still is) used extensively. I suppose the IE team are seeing similar issues to the Opera team did, especially now they’re changing the UA string and cloaking support for legacy IE features.

WebGL

If there was ever a poster child that trolls and haters would use to claim IE is still not a modern browser, it would be WebGL. I’m personally not convinced it is the most important feature for the average web developer, as it is a complex technology to learn and use, and the average web site generally doesn’t need 3D graphics.

On the other hand, where WebGL is useful, it is often critical. Games are an obvious example. With the recent announcement by Mozilla and Epic of porting the Unreal 3 engine to JavaScript with asm.js, the Web’s credibility as a gaming platform is only going to increase. It is going to become more important that Microsoft has a solution in this space.

The good news is that implementation of WebGL in IE11 is underway. It has to be enabled with a registry tweak, which isn’t all that surprising considered its unfinished state. There was initial confusion that it only supports IESL shaders (from DirectX), rather than the GLSL format defined in the spec (which has its roots in OpenGL). Fortunately that is not the case, and it is possible to get WebGL demos running, even at this stage.

However, it is important not to get ahead of ourselves. Until it appears in an official build it does not mean it is certain to land in IE11. Anything from the feature not being complete on time to security concerns could mean it is not included or disabled by default. I remember at Opera that WebGL was initially turned off as it was possible to blue screen of death Windows by visiting a page with WebGL content (I think due to issues with shaders). Safari also currently has WebGL disabled by default. However, if Microsoft are implementing WebGL, I’d be very surprised if the plan isn’t to include it.

Networking

The currently leaked build of IE11 has evidence for SDPY support, although it is not currently functioning. As such you should be especially careful about assumptions it will appear in any final build of IE11.

SPDY is a networking protocol originally proposed by Google, built on top of HTTP. Its main goal is to speed up page loading by reducing latency, compressing headers, and reducing the number of connections per client. While it is not a standard, it is being used as the starting point for a future HTTP 2.0 standard from the IETF.

SPDY is supported by Opera, Firefox, and Chrome, and looks like it will be coming to IE11.

DOM and JavaScript APIs

Mutation Observers

Traditionally if you wanted to monitor DOM changes you would listen for DOM Mutation Events. It is widely acknowledged that the design of Mutation Events is flawed, due to inherent performance issues. Because of these problems, Mutation Events are now deprecated.

As the functionality of Mutation Events is important, there is a glaring need for a replacement. Step up DOM4 Mutation Observers! IE11 includes this feature, joining Chrome, Safari 6, and Firefox. Opera will inherit support once it switches to Blink.

Full Screen API

Sometimes it is desirable to make a web page cover the entire screen, hiding the browser chrome. Playing videos is probably the most common use case, but gaming would be a close second. The Full Screen API enables this functionality.

IE11 looks like it is implementing this spec, with the requestFullscreen method currently supported in leaked builds. it is prefixed with the ms prefix. Presumably the rest of the spec will be implemented in future builds. The spec is also supported unprefixed in Opera, and prefixed in Safari, Chrome, and Firefox. Firefox currently supports and older draft according to caniuse.com, as does Safari 5.1 and Chrome 15–19.

Update: CSS

Flexbox syntax update

The good news is that Flexbox in IE11 has been updated to the latest version (and most likely final) version of the spec. The Flexbox syntax changed just before IE10 was released, so it supports an outdated syntax. I was hit by the same issue when writing the flexbox section of SmashingBook 3. The new syntax is currently supported by Opera 12.1, Chrome (prefixed), and is coming to Firefox in version 21. Safari (and current Firefox) still supports a version of the spec older than the IE10 version.

CSS Level 4 Selectors?

There is preliminary support for CSS Level 4 Selectors in the latest leaked builds, but they are currently non-functional, and I don’t know which are included. I’m looking forward to seeing an update to François blog post to see what they are.

No browser to my knowledge has extensive support of the new CSS Level 4 selectors, except those moved in from CSS 3 Basic UI. The spec itself is relatively immature.

transform-style: preserve-3d?

According to François Remy’s post referenced above, there is also preliminary support for transform-style in the latest IE11 build, but preserve-3d does not work yet. Presumably the plan is to have this supported (to the relief of authors of sexy demos everywhere) by the time IE11 ships.

What’s next?

Your guess is as good as mine at this stage. I can say what I’d like to see however. Adding support for transform-style: preserve-3d makes sense to round out 3D capabilities (Update: looks like this is underway). I’d love to see support for @supports from CSS Conditional Rules, as the sooner it is implemented cross-browser, the more useful it becomes. When I worked at Motorola, I pushed for this to be implemented by the WebKit team there, and it has now landed in WebKit. It is also supported in Firefox behind a flag, and in Opera 12.1. Support for border-image would also be nice. Additional codecs such as WebM would be great, but I’m not holding my breath.

As WeakMap has been implemented from ES6, I’d not be totally shocked if more of that spec is implemented. Especially considering TypeScript prototypes some up and coming features (Update: Set is now also supported). Similarly, MS’ CU-RTC-Web prototypes at least hints something could be implemented. As does the Device Orientation prototype. This would be very nice for mobile and tablets. I guess we’ll find out more at //Build/ in San Francisco.

When?

There is no definitive public release date, but we do know from executive interviews that Windows Blue will be released by the end of the year, and there will be a preview by the end of June. Presumably IE11 will be part of that release.

Thanks to François Remy and Rafael Rivera for digging into the leaked build and releasing some of its secrets. And again to François for further updates on later builds.

Vertical text with CSS 3 Writing Modes

Thu, 14 Mar 2013 17:55:00 -0700

Languages with latin-based writing systems such as English are typically written left to right, and from top to bottom. However, there is a whole different world of writing modes out there. CSS3 Writing Modes allows you to use these in your web sites. Read on to find out what you can, and can not use right now.

Introduction to writing modes

If you’re from anywhere outside of East Asia or the Middle East, it is likely that the writing mode your are most intimately familiar with is those that go from the left edge of the page to the right (line direction), and from the top of the page to the bottom (block direction). Examples of scripts that use this writing system include Latin (e.g. English, French, Spanish, etc.), Greek, Cyrillic (Russian, Ukrainian, Bulgarian, etc.), and Brahmic scripts such as Devanagari, Thai, Tibetan, and so on.

In the Middle-East (as well as North Africa, and Pakistan), the Arabic script is common, while in Israel the Hebrew script is used. Both of these scripts are written from right to left, rather than left to right as in Latin. What they do have in common with Latin scripts is that the lines progress down the page. If you look at a site set in Hebrew or Arabic, they tend to look like a mirror image of what one might expect if you come from a country that uses the Latin alphabet.

Things get a bit more complex when you look at CJK (Chinese, Japanese, and Korean), traditional Mongolian and other languages that can be written in vertical orientation. The key word is can. If you look at almost any Chinese or Japanese web site, you may notice that it is most likely written from left to right and top to bottom, just like Latin languages. While this is prevalent on the web, traditionally—and still in many printed publications—these languages were written with a line direction from top to the bottom of the page, and a block direction that goes from the right hand side of the page, to the left. Mongolian on the other hand uses the same top to bottom orientation, but the block direction goes from left to right.

I suspect one of the reasons why vertical text isn’t so prevalent on the web is that there hasn’t been high quality support for it in web browsers, and operating systems and applications in general. I would also guess there could be usability issues with scrolling. Vertical scrolling has traditionally been easier than horizontal scrolling, and you don’t want to keep scrolling up and down the page for each line. Multi-column layout on the web has similar scrolling issues. I’m mainly guessing though, as I’m not much more than a rookie in terms of when and how to use vertical rather than horizontal text in East Asian languages.

How to apply writing modes on the Web

In actual fact, we’ve been able to use vertical text longer than you might think. IE 5.5 added support for this feature, and support was upgraded in IE8. At the basic level, the support problem was that of other browsers. Things are a bit different now, as WebKit also has support. I suspect this is due to the demands of ePub for e-books, where WebKit is popular, and vertical text for the Japanese market is a key feature.

writing-mode

The property you need to use is writing-mode. The specification includes three values. While WebKit supports these values, IE support predates the latest version of the spec, and instead uses the values that were used in an older version and originate from SVG 1.1. While this isn’t ideal, they map well and work more or less in the same way.

IE supports the writing-mode property with the -ms -prefix (IE 8+) and without (since IE 5.5 when prefixes were not common), while WebKit requires the usual -webkit- prefix.

horizontal-tb

The horizontal-tb value is used for horizontal scripts with a block direction that goes from top to bottom. This is the default value, so you probably don’t need to specify it, unless you’re overriding a previously set value.

You’ll notice that the horizontal part of the keyword doesn’t specify the direction of the line of text. This can be set (if it hasn’t been already) by the good old direction property. Left to right uses the ltr keyword, and right to left uses the rtl keyword.

For IE there are two different values. Instead of using the direction property to specify the line direction, it is specified in the writing-mode value. left to right, top to bottom uses the value lr-tb, while right to left, top to bottom uses rl-tb.

Here is an example setting left to right, top to bottom text. I’ve included all prefixes, so it will also work if IE updates it’s syntax or Firefox adds support:


-ms-writing-mode: lr-tb;
-webkit-writing-mode: horizontal-tb;
-moz-writing-mode: horizontal-tb;
-ms-writing-mode: horizontal-tb;				
writing-mode: horizontal-tb;

While for right to left, top to bottom, the following code is needed:


-ms-writing-mode: rl-tb;
-webkit-writing-mode: horizontal-tb;
-moz-writing-mode: horizontal-tb;
-ms-writing-mode: horizontal-tb;
writing-mode: horizontal-tb;

direction: rtl; /* not specified as part of writing-mode property in standard syntax */

vertical-rl

This is where things get fun. The vertical-rl keyword is used to make the line direction switch in vertical mode, with a block progression from right to left. This is the value you will want to use for vertical layout in CJK languages. You do not need a direction property here as there are no known languages that uses bottom to top lines (unless you’re mixing scripts, such as embedding Arabic inside CJK text, but that is a whole different story).

IE supports this using the older tb-rl value:


-ms-writing-mode: tb-rl; 
-webkit-writing-mode: vertical-rl;
-moz-writing-mode: vertical-rl;
-ms-writing-mode: vertical-rl;
writing-mode: vertical-rl;

vertical-lr

If you want to use vertical Mongolian text, you’ll want to use the vertical-lr value, or tb-lr for IE. Lines go from top to bottom like CJK languages, but they flow from the left to the right of the page.


-ms-writing-mode: tb-lr;
-webkit-writing-mode: vertical-lr;
-moz-writing-mode: vertical-lr;
-ms-writing-mode: vertical-lr;
writing-mode: vertical-lr;

Writing-mode demos

You can see all four of these writing modes in action (if you’re using a modern version of IE or WebKit-based browser) in my writing modes demo. I’ve used English text in each example, but you should get the basic idea. The right to left example may be confusing though, as the text (except final punctuation and list markers) looks left to right, but right aligned. The reason is that when using Latin characters inside right to left text, they keep their left to right orientation. This is known as bi-directional text, or Bidi, but that is a discussion for another day).

Although vertical layout is primarily for languages that are naturally displayed in this orientation, Latin-based languages can also sometimes be used vertically. Usually due to lack of available space, or for stylistic reasons. Think of the spine of a book, labels on the 𝑦 axis of a graph, or those fancy vertical signs you see run down the side of theatres and other such establishments. In all but the latter case, each glyph is usually rotated 90° clockwise along with the line, so that it is displayed on its side, rather than its natural orientation. That is the default behaviour when using latin characters in vertical text using CSS.

I’ve made a demo taking advantage of this behaviour, where I’ve rotated text in a table header to save horizontal space. View the writing-mode property support demo in WebKit or IE to see this in action.

One thing you should be aware of with the previous demo is that I had to add a span (or another element) inside the th for the vertical orientation to apply in WebKit. In IE this was not needed, but the header cell didn’t resize after rotation, leaving white space. I suspect it is a bug in both browsers, but with the way tables work, it is anyone’s guess (or at least, someone smarter than me about such things). The spec mentions that writing-mode does not apply to table rows, row groups, columns and column groups, but does not mention individual table cells. Adding an element inside the cell works in both browsers however, so this technique is viable if you don’t mind an extra element.

Finally I’ve made a vertical text demo using Japanese text. Here you can see the vertical text writing mode used for it’s main intended purpose. Check out the Japanese vertical text demo in IE or Chrome.

The rules for vertical Japanese text are far more complex than I could ever hope to understand while working on this post, so there may be a number of issues that would look wrong to native eyes. After checking with Tomomi Imura, one such issue is with how the latin digits are rotated. In Japanese vertical layouts, these digits often keep their horizontal orientation, but with special rules, such as centring the glyph (central baseline in CSS terminology) rather than using the alphabetic baseline (the left edge of the line in top to bottom, right to left text). If two digits are found together, they are often combined side by side as if they were one glyph (know as tate-chu-yoko). While latin digits often keep their horizontal orientation, alphabetic glyphs can be rotated (as is the default) or keep their horizontal orientation. I’ve no idea what the rules are here, or if it is entirely stylistic. The main thing I have noticed is that runs of uppercase Latin characters are often set in the horizontal orientation, while lowercase characters are often in the sideways orientation. The next section will cover what we can and can’t do to correct these issues.

Changing the orientation of glyphs in vertical text

If you want to keep glyphs from scripts such as latin from rotating when in vertical mode, you can use the text-orientation property, with a value of upright:


-ms-writing-mode: tb-rl; /* old syntax. IE */
-webkit-writing-mode: vertical-rl;
-moz-writing-mode: vertical-rl;
-ms-writing-mode: vertical-rl;
writing-mode: vertical-rl; /* new syntax */
			
-webkit-text-orientation: upright;
-moz-text-orientation: upright;
-ms-text-orientation: upright;
text-orientation: upright;

This is currently only supported in WebKit browsers. You can check it out by viewing an updated version of the previous Japanese demo, using text-orientation: upright.

This property applies to all glyphs, but as Japanese characters are already in the horizontal orientation, you will only see a difference with the Latin characters.

As you may want to keep some non-Japanese characters in the default sideways orientation, it may be best to add spans around the glyphs you want to keep upright.

The eagle-eyed among you might notice an issue in WebKit browsers. While the digits are kept horizontal, they are still aligned to the alphabetic baseline, rather than centred to the central baseline. Chrome is also slightly clipping the text. Every glyph is also rotated, which is incorrect. Glyphs such as hyphens (-), and brackets and braces ({}()<>) should be left sideways, otherwise they look very odd.

While this is where support stops for this property in Safari, Chrome also supports the sideways and sideways-right keywords. The sideways-right value rotates the glyphs 90° clockwise when using vertical layout. This is the same as what is applied by default to horizontal scripts such as Latin. It will however also rotate glyphs that are usually displayed horizontally in vertical layout, which will probably look odd to anyone that can read those languages.

The currently unsupported sideways-left keyword rotates the glyphs 90° anti-clockwise. The text line is also rotated 180° as if the text is read bottom to top, instead of top to bottom. Think of how labels on the left hand side of the 𝑦 axis of a graph are often displayed.

Combining glyphs side-by-side in vertical text

While in vertical text glyphs progress down the page, rather than side by side, sometimes you may want to have two (or maybe more?) glyphs side by side, such as the aforementioned case where two digits are combined.

For that particular use case, we can use the following rule:


text-combine-horizontal: digits 2;

The digits 2 value (actually the 2 can be omitted, as it is the default), says that if two digits (U+0030–U+0039) or less are found in a row, combine them in the space used for 1 character (a width of 1em). Unfortunately, while this would solve our problem, it is not currently supported anywhere, to my knowledge.

The all keyword works the same way, but tries to apply it to the entire textual contents of the element. You can imagine that if you apply this to an element with more than a few characters, it is likely to not be able to do that. The spec says that it must try to fit the contents into 1em, but can use any method to do so. So I’m not exactly sure what would happen if the contents don’t fit. Craziness is my best guess.

The final value is none, which is the default. It is easy to imagine what this does (nothing, except default back to nothing if the element was previously doing something).

Some unexpected things to take into account when using vertical text

If you expect everything to work as if you just rotated the element and its children 90° using CSS transform rotate, then there are a number of things you should be aware about.

Height, width, and the box model

If you rotate an element 90° clockwise with a transform, the width of the element looks as if it is the height (width now goes from top to the bottom of the screen). With vertical text however, the width and height remain the physical width and height. That is, if you specify the width and height, the text lines will rotate when specifying vertical text, but the width and height of the element will stay the same.

Similarly, margin/border/padding-top will remain the physical top of the element, rather than the right side when an element is rotated 90° clockwise. A key difference here is margin collapsing. As text flows across the page, margin-left collapses instead of margin-bottom when using vertical-rl, and the right margin collapses when using vertical-lr.

The positioning properties such as top, right, bottom, and left also still refer to the physical edge of the element’s margin box. The top property still refers to the top edge, rather than switching to the physical right edge.

Text-align, vertical-align, text-decoration and floats

While the box model doesn’t rotate, text-align, vertical-align, text-decoration and floats do. Left aligned text will become top aligned, right aligned text will be bottom aligned. As you may have guessed by now, float: left will float the element to the physical top, while float: right will float to the physical bottom.

Vertical-align: top will align to the physical right of the cell when using vertical-rl and the physical left of the cell when using vertical-lr. Similarly, the underline value of text-decoration will be drawn along the physical left edge of the line box using vertical-rl and the physical right side when using vertical-lr.

Due to the above, the vertical-align property is unfortunately named, as are the left and right values of text-align and float. For text-align, two new abstract keywords have been defined, named start and end. The start value is the equivalent of left and end is the equivalent of right (except when using the right to left line direction (e.g. Arabic or Hebrew), where start is right, and end is left). This makes their use less confusing, as they always apply to the start and end of the line box, no matter what orientation is being used. These are currently only supported by WebKit and Gecko. Similarly the abstract values for top and bottom are over and under respectively.

All of this might be easier to understand with a diagram, so here you go:

Abstract and physical dimensions and directions

Flow relative directions

The following diagrams show the mapping between the flow relative abstract (yellow) and physical (green) directions, as well as the dimensions of the element. The physical directions always stay the same, while the logical directions change depending on writing mode, direction and text orientation.

horizontal-tb ltr (left to right, top to bottom)

horizontal-tb rtl (right to left, top to bottom)

vertical-rl (top to bottom, right to left)

vertical-lr (top to bottom, left to right)

Line relative directions

The following diagrams show the line relative physical (blue) and abstract (yellow) directions. You will notice that the physical line-relative directions do change when the text orientation is flipped from sideways-right to sideways-left.

horizontal-tb (top: ltr, bottom: rtl)

vertical-lr and vertical-rl

text-orientation: sideways-right, direction: ltr
text-orientation: sideways-right, direction: rtl
text-orientation: sideways-left, direction: ltr
text-orientation: sideways-left, direction: rtl

Finer grained control of hyphenation with CSS4 Text

Wed, 06 Mar 2013 17:54:56 -0800

CSS3 Text provides the ability to apply hyphenation to text, via the hyphens property. While this is all well and good, it doesn’t provide the fine grain control you may require to get professional results. For this, let me introduce to you CSS4 Text.

Applying bog standard hyphens

Many of you are probably aware of the hyphens property, and what it is used for. It has long been considered a bad practice to justify text on the Web due to the rivers it tends to leave between words. Hyphenation largely solves or reduces this problem. It is also easy to apply:

p {
    text-align: justify;
    			    			
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    -ms-hyphens: auto;
    hyphens: auto;
}

Also, remember to set the language (using the lang or xml:lang attribute, so that the browser knows which hyphenation rules to use.

You can also use the manual value, which will hyphenate words only when you specify it, using the soft hyphen (), or regular hyphen.

Browser support is mixed. Firefox, Internet Explorer 10, and Safari support hyphenation, while Chrome and Opera don’t. Chalk one up for the differences between WebKit browsers list.

Problems with hyphenation

While hyphenation reduces the rivers flowing through your text, they lead to a different issue. That of ladders. In typography, ladders are when more than two hyphens appear in a row at the end of a line. It becomes visually distracting, and makes the text harder to read. Especially when using short line lengths, such as with multi-column layout.

Applying more control with CSS4 Text

The CSS4 Text specification (warning: work in progress) provides a number of ways you can optimise how hyphens are applied. While they are no substitute for manually typesetting and hyphenating your text, it does provide you with much more fine grained control, and can improve the readability of your justified and hyphenated text.

Limiting the number of hyphens in a row using hyphenate-limit-lines

The hyphenate-limit-lines property allows you to specify the maximum number of lines in a row that a word will be hyphenated. The general rule of thumb is that two consecutive lines is the ideal maximum:

hyphenate-limit-lines: 2;

This property is currently supported by IE10 and Safari, using the -ms- and -webkit- prefix respectively.

You can check out my hyphenate-limit-lines demo to see this in action. You will need to use one of the aforementioned browsers to see any difference between the two blocks of text. If you do not see three or more hyphens in a row for the first example, you can resize the width of the browser window. You should see that the second example never has more than two hyphens in a row.

Limiting the word length, and number of characters before and after the hyphen.

You usually don’t want shorter words to be hyphenated as it makes them harder to read. Similarly, you often don’t want too few characters left on a line before the hyphen or pushed to the next line after the hyphen. I don’t think there is a hard and fast rule for the ideal limits, and it is more based on what looks best for your content. I’ve seen a six character word limit, with three character minimum before the break, and two after, recommend. I’ve seen good results with this, but your milage may vary.

You can set these limits with the hyphenate-limit-chars property. It takes three space separated values. If all are set, the first is the minimum character limit for the word before hyphenation, the second is the minimum characters before the hyphenation break, and the last is the minimum characters after the hyphenation break. If the last value is missing, it is set to the same as the second. If only one value is supplied, the last two are set to auto. If the auto keyword is used (or implied), the user agent picks the best fit based on the current layout.

The following example sets a six character word limit, with three characters before the hyphenation break and two after:

hyphenate-limit-chars: 6 3 2;

Support is currently limited to IE10 only, using the -ms- prefix.

You can see this in action in IE10 in my hyphenate-limit-chars example. Again, resize the width of the window to see how each example behaves differently. I have manually underlined the words in the second example that have the potential to be hyphenated (six characters or more). They will not always hyphenate, as it may not be possible to apply the hyphenation break in a position that will leave enough characters before or after the break.

Setting the hyphenation zone

When using hyphenation, there is a specific zone that a word needs to fall in at the end of a line before it is considered for hyphenation. With the hyphenate-limit-zone property, you can manually specify the width of this zone.

Whether or not a word falls into the boundary is calculated before justification is applied (i.e. as if text-align: left was applied when using left to right languages). If a word falls into the hyphenation zone, no hyphenation will be applied on that line. If the last word on the line falls outside the zone, the word on the next line is brought up to the current line and hyphenated (unless any other hyphenation limits prevent it from doing so).

The hyphenation zone is specified using a length value or a percentage. In the following example it is set to 40px:

hyphenate-limit-zone: 40px;

Support is currently limited to IE10. Open the following hyphenate-limit-zone example in this browser to see it in action. I’ve hi-lighted where the zone would be in each example. In the first, third and fifth examples, no hyphenation zone is set, but it shows clearly which words would fall in or out of the zone before justification and hyphenation are applied.

Other, unsupported features

There are a couple of additional properties, that are not supported in any browsers currently.

The first is hyphenate-character. This accepts a string that specifies the character used to hyphenate. For example, the regular hyphen character (which is the default so doesn’t need specifying) can be set using:

hyphenate-character: "\2010";

I’m not sure why you would want to set a character other than the default one used by the language in question, but I guess there could be some use case if you’re getting creative.

The other unsupported property is hyphenate-limit-last. This specifies if hyphenation is applied on the last line of an element, column, page, or spread. The none keyword applies no restriction, the always keyword does not apply hyphenation on the last line of all the aforementioned cases. The spread keyword doesn’t apply hyphenation to the last line before a spread break, page restricts this to spread breaks and page breaks, while the column keyword restricts it to spread, page and column breaks.

hyphenate-limit-last: column;

Tying it all together

While each of the examples shown only use one of the hyphenate-limit-* properties, they can be combined to apply greater control. Unless you’re an hyphenation expert (I’m not), you can often get the bed results by experimenting with the various properties to suit you specific content. Different styling such as line lengths, justification, columns, word spacing, letter spacing, text size, etc. can have a big difference on how the text is hyphenated, and how much massaging you need to apply. Just remember not to go overboard with restricting hyphenation, or you’ll end up with the original problem you were using hyphenation to avoid; the large rivers of white space between words.

Get help faster, by reporting better issues

Wed, 27 Feb 2013 15:27:00 -0800

I have been spending quite a bit of time recently helping out with compatibility issues on sites such as StackOverflow and the MSDN forums. It is often difficult to give helpful advice, as the reporter doesn’t give sufficient details to debug the problem. Instead of repeatedly typing the same message in each thread, I’ve distilled some points here, that may guide you when reporting your web development woes. Taking some time to stop and think, and put yourself in the shoes of the person that will read your report, will help you create better reports, and you’ll receive faster and better quality feedback.

Avoid common issues

A few quick checks can spot the low hanging fruit that you may have overlooked:

Check the error console of your browser’s developer tool. Especially if it is a JavaScript issue.
Validate your HTML and CSS. Lint your JavaScript. It just takes a mismatched end tag, or missing semi-colon to wreak all sorts of havoc.
Problem in IE? Check the F12 tool to make sure your page is using the latest document mode. IE can default to using an earlier version of the engine.

Sharing your problem

If you are still having issues, it is time to look for help. Follow the next few steps to improve your chances of getting helpful feedback.

Step 1: Give a way to run the code you are having problems with

If you don’t give people a way to run your code, it can be very difficult to find the issue you are experiencing. An inline code snippet in the post often doesn’t help, as the issue may not even relate to that code, and it is not possible to experiment with the code to try out different theories.

At worst case, link to the actual page you are developing. If you really want to be helpful, make a reduced test case, which only includes the minimum amount of code that still exhibits the problem. For example, if the issue is with your login form, you can probably remove all the HTML around it and the CSS that doesn’t apply.

There are a number of online tools such as JSFiddle that allow you to host small snippets of code. If possible use one of these. This allows us to edit the code and link back to the result. Popular tools include:

Step 2: Concisely explain the issue you are having

No need to tell a story about what you ate for breakfast. Include the following details:

Short description of the issue. Keep it as short as a tweet if possible
Steps to reproduce the issue. Even if obvious to you
Result you are expecting
Actual result you are seeing
A screenshot if the issue is visual
The browser(s), version(s), and operating system (if applicable) where you’re seeing the issue
Any other essential supporting information

Step 3: There is no step 3

Sit back, relax, and wait for a reply. If you work out the issue before anyone replies, report back your findings. It saves someone wasting their time dealing with your issue, and will help anyone else that runs into the same problem as you.

Stumbled across a browser bug?

Often it isn’t your fault. It’s the browser. If this is the case, remember to report the bug with the browser vendor(s) in question. If they don’t know about the bug, they can’t fix it. Luckily, if you followed the steps above, most of the work has already been done, and you can copy and paste your excellent report into the bug tracking system of the browser vendor in question. But, remember to search first to see if the same issue has been reported.

Lea Verou has an excellent article on how to report browser bugs.

Here are the location of the bug trackers:

Internet Explorer
Opera (Note: Opera will soon be switching to WebKit)
Firefox
WebKit (Chrome and Safari)
V8, for issues with JS support in Chrome

Hey -o-, let’s go!

Wed, 13 Feb 2013 16:05:00 -0800

So the news we were all dreading came to pass. Opera will drop Presto, in favour of WebKit. Four becomes Three. Only one browser engine remains where the dominant contributions come from an independent vendor who don’t have a vested interest in a large native ecosystem. What does this mean for Opera, and the Web at large?

I Fought the Law, and the Law Won

This move is Opera throwing in the towel. It is saying “WebKit has become too dominant (specifically on mobile), and we can’t compete”. Think about that for a second. It isn’t viable to have an independently developed browser engine in 2013. No matter that you have some of the best developers in the industry, and great industry influence.

While many will say Opera’s influence is negligible, think back to the biggest changes in the history of the Web over the last few years. Moving from HTML to CSS based layouts? Opera was perhaps the first to have a useable CSS engine. Håkon (father of CSS, and Opera CTO) often says it was the reason he started to believe a browser could be made in Norway, not just the USA, and joined Opera. AJAX? Opera reverse engineered this from MS’ ActiveX based approach and were the spec editors through Anne van Kesteren. HTML5? Started at Opera with Ian Hickson and others. Responsive web design? Media Queries came from Opera, and were implemented for years before showing up in other browsers. What about native video on the Web? Opera again.

Should I Stay or Should I Go?

But why did it come to this? What pushed Opera over the edge, and made it decide to become a bit part player in the increasingly crowded WebKit fraternity, rather than be in control of its own destiny with its own engine? I think it is clear from previous moves from Opera. It had to change its user agent string to hide the true version due to sites not working when moving to a two digit version number. Faulty browser sniffing. It had to add support for -webkit- properties. Browser engine mono-culture on mobile (and even desktop in some cutting edge sites). I could go on.

I have first hand knowledge of browser compatibility work inside Opera, and it was always like being a salmon swimming against the tide. That we have standards is a bit of a fallacy. Devs used to code for only IE, then Firefox came along, and you had a IE path and a standards path. Except the standards path was basically a Firefox path, bugs and all. So you had to emulate Firefox. Or if the standards path worked, you had to beg the developer to give it to Opera, as they browser sniffed anyway. Then WebKit became the apple of the developer’s eye, and there becomes a proliferation of -webkit- only prefixes without fallback or regard for other browsers. Opera just wasn’t big enough in the right markets to weigh on developers minds. Unless it did something that was perceived to be wrong, then it was suddenly important.

Faced with that situation you can continue to swim against the tide, or say screw it and join the path of least resistance. I’m sorry to say, but we’ve all failed the Web, as this is WebKit not Web Standards. That is just the market reality.

Opera had to do what was best for their users (and shareholders), and let’s face it, except for the power users–of which Opera has many–the user has no idea what engine the browser is using, and shouldn’t need to care. Most will be none the wiser after the switch. Except less of their sites will block them from using it, and more of the shoddily built sites (of which most top sites are in one way or another) will just start working. Yey ~~standards~~ WebKit!

Armageddon time

Opera failed, I failed in my dev rel and web compatibility role. Influential developers failed to fully comprehend or care about the situation. The W3C failed. Other non-WebKit vendors failed. There is no point in pointing fingers. We all failed in some capacity. We all need to do better, starting today.

Death or Glory?

So what does this mean for Opera? Is it bad for Opera? Not necessarily. I think it could be very good for them. Even though they have over 300 million users, there is a lot of user churn. I guess we’ll finally find out if those not sticking around was because of compatibility issues or because of the product itself. There are no longer any excuses to hide behind. And some argue Opera is becoming an ad company rather than a browser vendor anyway.

On the other hand, its influence may wane somewhat. People in Opera used to often not count a browser as a browser if it was only a shell around another engine. Opera on iOS will certainly be this. On other platforms it remains to be seen if Opera will more passively just use Chromium and focus its efforts on value added features, or if it will actively add standards features with as much gusto as it does with Presto. Will WebKit give Opera the respect it deserves, or will it be like other vendors that struggle to get its patches into trunk?

What happens if Opera wants to go in a different direction to Google and Apple? It can create its own fork, but then it starts to become less compatible over time. It doesn’t have the influence of a Google to get away with that, and it removes the reasons to move to WebKit in the first place.

Four horsemen

What does it mean for the Web? We used to have a multitude of engines on the web. Hands up who remembers the iCab engine? Assimilated into WebKit. UC Web? Ditto. NetFront. You guessed it. BlackBerry, OmniWeb, the list seems almost endless. We ended up with four major engines, and now we have three.

Competition breeds innovation. You can trace the performance race back to the early stated goals of WebKit to always improve performance. What wasn’t shown on the Keynote slides was that Opera used to be leagues ahead in terms of performance at the time. WebKit and Apple used it as the standard which to beat. I have fond memories of the ACID tests and the friendly rivalry between WebKit and Opera on who would pass it first. People thought of this as browser grandstanding. But it motivated browser developers to work that little bit harder to fix complex bugs, improve rendering, and speed up the browser. As quickly as possible. When developers smelt victory they’d spend extra hours in the office getting that extra 1%. It was kind of like the olympics for browser geeks. Competition driving standards compliance. If WebKit wins out in the end, where will be the competition? Who gets their patch landed before another one?

There can even be competition between alternative proposals for solving a particular issue. This can cause comptibility issues, but can also lead to better APIs overall. Will there be less incentives if everyone ends up working on the same engine? That is hard to tell.

Three card trick

But, currently we’re down to three, not one. We have to hope that Mozilla and IE stick to their guns. Because right now the W3C requires two interoperable implementations for something to become a standard. That now becomes two thirds of implementations. If we lose another engine, one effectively has veto power. WebKit effectively has that now anyway on mobile, where once Opera switches over the Opera Mini backend to WebKit, it is rounding errors away from complete domination.

Gates of the West

Developers often claimed WebKit was the only relevant engine on mobile already. But it never was. With Opera Mini holding the top spot for a long time, and still being hugely dominant in countries such as India and Russia, this was just a wealthy western web viewpoint rather than a global viewpoint. True, for their use case no other engine might have mattered (except the lock in they were creating to create friction against change in the future, just like the IE6 days…), but there were many developers in the world where this was not the case. Could any developer in Russia or India only develop for iPhone and Android? I doubt it.

But this western viewpoint caused a multitude of issues for Opera, that effectively blocked its influence in developing markets to spread westwards, and down under. And, thus the play you see unfold today.

Last gang in town

So now, the torch is passed to Mozilla and Microsoft, as on the 13th day Opera become the Judas in the battle to avoid mobile monoculture. Microsoft becoming a saviour of the Web? It looked unlikely during the ~~dark ages~~ IE6 years, but they might just have become our best hope. They have the resources to put up a fight for feature parity with WebKit, and mobile OS marketshare with Windows Phone, plus Windows 8 puts the spanner in the works, as any desktop can become a touch platform. I know I’ll be cheering them on.

Mozilla were very late to the mobile party, and that is reflected in its tiny mobile market share. It may have needed Opera to stay strong more that it would care to admit. I was always disappointed Opera and Mozilla couldn’t co-operate more, and the trolling that came from certain corners. They both have shared goals for the most part. I think Mozilla saw web compatibility as an Opera problem, until it entered the mobile world and got hit with it themselves. The same mistake can’t happen twice. Mozilla and Microsoft really need to get talking on how to combat the WebKit threat. Especially now it can move even faster forward if Opera developers also contribute to the engine codebase. We can’t afford only one superpower, with the W3C relegated to the role of the UN.

I really worry for what this move means for the W3C long term.

I’m so bored with the USA

But, back to Opera again. Are there any hidden meanings in the announcement today? Could Opera be primed for a take over? A number of people lost their jobs (I’ve no idea how many, but a big chunk of my old team, and there are a lot of new faces on the Opera Alumni Facebook group). A move like this was always going to have human tragedy. Could they be “cutting the fat” before a takeover? There have been so many rumours over the years, but the former CEO never wanted to sell. Now the company is run by a sales guy.

WebKit developers are in major short supply. I remember the difficulty we had attracting and keeping WebKit talent at Motorola, and how hard Adobe are looking for developers. Opera (if they don’t eventually lay them off) have a large number of very talented browser engine developers, who know the specs inside out, and are in many cases on W3C working groups. These are transferable skills to the world of WebKit. If Opera gets any sort of influence in the WebKit community, they may just become a more valuable takeover target, and surely more bang for your buck than an Instagram.

Many people speculate about Facebook. Adobe could perhaps be an option. My dark horse prediction is Yandex.

Rudi can’t fail

We need to learn from the mistakes of the past. The Web is too important to stagnate again or to be held ransom to the politics and design goals of one single code base and project. The TAG at the W3C have just had a fresh injection of elected talent. Let’s not hand the keys to the WebKit project maintainers instead. Nothing against them at all; they’re great people. Just, diversity of opinion is one of the things that make the web great. And it is not just for people like us, that can afford shiny new iPhones. It is for the farmer in Africa, the factory worker in Bangladesh, the growing middle-class in China. Everybody. Diversity in the standards process tends to help with keeping these goals in mind.

Here Today, Gone Tomorrow

As well as a reduction in the gene pool of web rendering engines, there is a very human sadness with this move. I’ve no idea how many people lost their livelihoods with the move, but at least a bunch of my old team in Opera DevRel and people in the standards team. I hope people that wished Opera would go away and become bankrupt are happy with that news.

I’m not even sure the DevRel team I founded and helped to build still exists. In many ways it was like my baby, that I stepped away from to watch it grow up. It was, I believe, the first developer relations team focused on web technology. I fondly remember Andy Budd saying at @Media that he wished other vendors would take an active interest in the concerns of developers like Opera did (or words to that effect). The CEO of YouTube said something similar when working with them on Opera compatibility, before it became a Google concern.

We hired some amazing people, who were foremost web people, not marketeers or from other platforms. We understood the web, cared for the web, and fought for the web. We had a diversity in the team that would make a conference organiser green with envy. Not just male and female (although at one time we had more female dev rel in North America than male), but, a rainbow of races, creeds, social backgrounds, religions, what have you. It was like the United Nations, without the arguments, and much more inappropriate humour. It was a global second family (as was Opera at a whole), but I’m glad to say, every single one was hired because they were the best person for the job, not because of what was between their legs, or any other physical characteristic. I hope those that left today find a job in the web, as they’ll be missed otherwise.

We might not have ultimately succeeded in keeping the web open, but there will be a lasting influence. Every browser vendor now has its own developer relations team. Something we perhaps can‘t claim credit for, but at least influenced in a meaningful way. Many of those in Opera and the other vendor‘s DevRel teams have become active in improving the health of the web community, and members of working groups defining the standards we use every day. If that is my lasting legacy on the web, then it is at least something.

I Believe In Miracles

The best that can come of this? Maybe Opera will eventually open up the Presto codebase. Let it enjoy its twilight years in the sun. I don’t suspect it can survive without corporate backing, but there is a lot to learn from.

Predictions for the Web in 2013

Thu, 03 Jan 2013 15:23:00 -0800

2012 was a bumper year for the Web. Lets get our crystal ball out and look what we could have in store for us in 2013, in terms of the browser and platform wars.

The desktop browser market

Chrome spent much of 2012 eating marketshare from IE and Firefox. Indeed, the only browser to grow except for Chrome was the other WebKit browser, Safari. However its ~2% marketshare gain was mostly due to Safari on iPad’s growth rather than the desktop browser.

Towards the end of the year, Microsoft released Windows 8 with IE10. As IE10 comes out on Windows 7, and Windows 8 starts to build marketshare, Microsoft will hope it reverse their losses to Chrome. Can they do it? It’s hard to say, but it’s clear that IE10 is Microsoft’s best browser in quite some time. It’s CSS, HTML and ECMAScript support is finally competitive with the competition. It has a WebGL sized hole in its standard support (but how many average web pages use 3D graphics?) and doesn’t support some of the more experimental APIs, but the gap that grew from IE putting its tools down for 5 years has almost closed.

The gap between IE releases have been getting shorter since IE8 came out. If they can reduce that to around a year or less, and keep their current pace of development, could we have a mighty war on our hands between IE and Chrome for marketshare and standards compliance supremacy before the end of the year? It would certainly make things more interesting. Competition breeds innovation, but with Apple and Google using the same engine, not much competition has been happening between those great rivals. Microsoft could really put a cat amongst the pigeons, and break any potential WebKit dominance on the desktop. I strongly believe that engine diversity is good for the Web, so I’ll be hoping for a IE and Firefox comeback in 2013.

One prediction that I hope doesn’t come true is the demise of Opera in the desktop market. In the last year, Opera dropped from 1.98% to only 1.26%. In the early days of January it is down further to 1.16%. Is it in danger of dropping out the top 5 browsers? I’m not sure if Opera is actually losing users, or whether the market is just growing faster than it is.

Prediction: IE11 and Chrome 1,234 (~approx.) going toe to toe by the end of 2013?

Mobile platform wars: the race for third

Forget about the titanic battle for first place in the mobile market. iOS and Android will go at it tooth and nail through 2013, but the latter already has the marketshare battle sewn up globally, as it extends its reach downwards into the more price sensitive markets that Apple chooses not to compete in. The main contest between those two will be who comes out on top in the premium markets, where there is more profit–rather than marketshare–on the line.

The more interesting battle in my mind in 2013 is the looming battle for 3rd place, and thus relevancy, in the smartphone market. For some contestants their entire futures as an independent entity rest on not only wrestling 3rd place out of the hands of their rivals, but building on that platform to get closer to iOS and Android than the rest of the chasing pack. A weak 3rd place won’t be good enough to get developer attention. I suspect these platforms will need to at least get into the double digit market share, or have something else to offer developers to remain in the race. Manoeuvring into third place by the end of 2013 will likely be a key springboard to building out the victor’s ecosystem however.

Who are the likely contestants in this battle? Currently Nokia’s two operating systems; S40 and Symbian are the only two platforms under iOS and Android that are around the 10–15% mark. The latter is a legacy platform that will only drop in popularity as users upgrade their phones. S40 is a feature phone OS, which will presumably stick around a while longer on the low end, but is not part of the app-centric smartphone battle.

The core battle will likely be between Windows Phone 8 and BlackBerry 10. It’s an interesting contest, as BlackBerry still has an edge in terms of marketshare (mostly due to its strong position in the UK and Canada), but it’s influence is fading fast. RIM will need to try to convert those loyal holdouts to BB10. In reality, Windows Phone has the head star,t as BlackBerry is moving to a whole new platform, which is still not on the market. Nokia have an even bigger legacy user base, that can be a key asset if they work out how to get Windows Phone at a price point to attract those users to upgrade and switch to Microsoft’s newer platform. Both Nokia and RIM will need to move fast though, before Android eats up that potential source of new users.

Windows Phone’s market success has never really justified the column inches written about it, but there are signs that it will prove the naysayers wrong. In Europe it is currently the 3rd most popular platform in key markets such as France, Italy, Germany, Ireland, Switzerland, Austria, Belgium, and the entire Nordics region. Despite an overall marketshare lead over Windows Phone in Europe, BlackBerry is only more popular in the UK and Portugal. Furthermore Windows Phone has had a large uptick in the last few months, so it looks like momentum is on its side. Microsoft will hope that it can repeat the success it is having in Nokia’s home market of Finland in other markets.

I do hope Windows Phone does well, as we desperately need a successful platform with a none-webKit browser as default. It is also a brave step from Microsoft to focus on design, and not just produce a carbon copy of Apple’s OS (and those before it such as UIQ and PalmOS). My biggest disappointment of 2012 was that Windows Phone 8 didn’t ship with support for native HTML apps in much the same way as Windows 8 did. I think that was a mistake, especially when you consider the similarities between the platforms and the cross pollination it would have allowed. I think it will be coming in 2013 though. Microsoft would be crazy not to. Imagine if the first popular web based mobile operating system ends up being Trident based rather than WebKit? No one would have predicted that a few years ago, but it is well within the realms of possibility.

Windows Phone and BlackBerry 10 are not the only contestants though. Firefox OS will likely make its bow in 2013, and also Ubuntu phone. I believe the latter also ships with a Gecko based browser and HTML app platform. I consider these platforms to be the black horses of the race. Both are from strong and well respected open source friendly companies, but neither have a great deal of experience or history of success in the mobile space. Mozilla have little experience writing operating systems or dealing with OEMs and Operators (the latter of which is one of Opera’s strong suites, and partially why they do so well in the mobile browser wars), while Canonical have a ton of OS experience, but are not exactly known as a web powerhouse (although they do have some people such as Yaili and Stuart who are very much involved in the community).

I do worry that both may be spreading themselves a little thin, and their solutions may be a little late, considering the huge resources available to Apple, Google and Microsoft, and the fact they won’t be standing still waiting for the competition to catch up. Especially considering they are both Gecko based, I would have liked to have seen what a combined effort from Mozilla and Canonical could have looked like. Mozilla would have been able to lend their world class experience in producing a browser, Web APIs, web developer tools, and their influence in the developer and standards communities to Canonical experience writing operating systems and services. They are probably the two biggest names in consumer focused open source software, so people in the developer community at least would sit up and notice. Instead, I fear that both will eat into each other’s potential marketshare, as they go after the same audience and the same developers. They will also potentially fragment the Gecko ecosystem, unless they manage to ship comparable versions.

The final realistic competitor is Tizen from Intel and Samsung. It remains to be seen if Samsung will go all in, or if it will mainly be used as a bargaining chip against Google. Tizen sits atop a pile of caucuses of now abandoned mobile operating systems, such as Bada from Samsung (which was getting some traction in emerging markets), and Meego, Maemo, Moblin, Harmattan and probably half a dozen others I’m forgetting. Whether it is successful where Nokia, Intel and Samsung failed before is anyone’s guess. Its one true advantage is that if Samsung is truly committed to the project, it has the reach and marketing budget to make a fist of it. What it doesn’t have is a strong history making great software, and a strong developer community. If they want “HTML5” developers to develop for the platform, it better start reaching out to them and be involved in the community, starting yesterday.

One of the threads that run through most of these platforms is the support for HTML apps. This is potentially great news for developers, as it allows a way to get apps onto each platform with less work than porting to various different native toolkits. Unfortunately, I expect that rather than work together for the common good, they’ll all have their own system and device APIs and manifest formats. The W3C DAP and Widgets specs have not taken off so far with the larger players, and I don’t really expect this to change in 2013, unless there is a change of attitudes. WebRTC looks like it will be adopted in some form or other (Microsoft have a rival proposal), but that was specced outside of DAP. I’ve not seen the same interest in the various DAP specs such as calendar and contacts APIs. With the two leading WebKit vendors having their own non-Web-based OS’, this is a space where Microsoft, Mozilla and Opera working together could strengthen each other’s hand against the market leaders. In an ideal world, we could just write code once for the non-UI part of the app, but this isn’t the case right now.

Prediction: Windows Phone is slowly starting to gain momentum. With its head start over the other platforms, and Microsoft’s resources, 2013 will be the year it breaks into 3rd place, and starts to put some air between it and the chasing pack. I also predict they’ll come out with JavaScript apps at some point, either in 2013 or early 2014.

Web on TV?

Web on TV has been the next frontier of the web since, well, before web on tablets became the next frontier. I don’t expect things to shake up too much this year. Apple TV could throw a spanner in the works and reinvent the field if it finally comes out with apps, a browser, and a new control method.

The main battle that is brewing is between the console makers and the companion box platforms such as Google TV and Apple TV. In many ways they are converging. Consoles are getting more media centre functionality, and the mobile platforms that the TV boxes evolved from are getting stronger gaming platforms. I suspect the consoles will get better at streaming media and apps faster than the companion boxes get at having top games available, considering many seem to be platform exclusives.

I own a Samsung Smart TV, and rarely use the browser. The main problem is the control method. It takes longer to type in a URL than it does to go to the other room and find my laptop. It has voice and hand gesture support, but I can’t get either to work. Whoever can solve the input dilemma has a good crack at making a browser that people actually use to surf the web. Microsoft may hold some aces up their sleeve with both SmartGlass and Kinect. Using a smartphone or tablet as an input device just makes sense. It will be interesting to see what the next XBox and Playstation come out with. If they are not released until the Christmas season, it won’t be until 2014 that any effects are seen.

It’s not just the control scheme that is the issue though. The other is the content itself. There is certain content that is more suited to accessing on the TV than others. The obvious one is games, where you benefit from having a large display and space for multiple players. Anything which is social in nature can benefit from using the TV, such as streaming music and videos, video conferencing, photo slideshows and so on. My TV doesn’t have an HBO app, so I thought I could access their TV shows via the browser. It seemed like the ideal use case. Unfortunately their site blocks the browser. I had a similar issue with Comcast’s Xfinity site. Some shows do not allow you to beam them to the TV, so I thought I could stream them via the browser. There was no blocking this time, but the stream requires Silverlight, which the TV doesn’t support. These kind of compatibility issues, plus lack of optimisation for the 10 foot viewing experience, puts barriers in front of what would be a fantastic use of a TV browser.

There is also the case of trying to get to the content as quickly as possible. In the days of Teletext, you just pressed one button to access the service, and the content was tied to the channel you were on. Launching the browser would also benefit from this one button access.

The one key advantage a TV browser could have over using a tablet or laptop however, is if it is contextually aware. That is that it could access the video stream you are accessing, and feed related content to the browser or app. This could be anything from having a portal for the channel you are on, to allowing you to access the web site of the product that is being advertised (now, that is the advertiser’s holy grail), get information about the TV show being broadcast, allow you to vote or interact with game shows, and so on. If this was done right, you’d have access with one click, rather than having to search for the content if you were using a desktop or mobile browser. You wouldn’t necessarily access this content on the TV itself. The TV could pass it to a companion device, much like SmartGlass or the Wii U. There is already an industry standard called HbbTV to allow you to access the broadcast stream, but this has only seen any kind of adoption in Europe, and I doubt it will get any kind of mass market adoption this year. It is one to look out for though.

Prediction: Still looking for the web on TV holy grail in 2013, but watch out for what the consoles do going into 2014.

Public service announcement: time to update your CSS3

Fri, 14 Dec 2012 17:56:00 -0800

If you use experimental CSS on your sites, demos, articles or tools, there is a certain amount of maintenance required to keep on top of changes. With a number of recent changes in the browser world, now is the time to revisit and update your code. Read on to find out what may need updating.

Reorder your prefixes

There is no specific order that you should place your prefixed properties. However, a commonly recommended method is to place them in alphabetical order, with the prefixless version last. This would make the order: moz, ms, o, webkit, then prefixless.

Opera recently added support for -webkit- prefixes for a limited number of CSS properties. This is needed as a number of developers choose to only include the webkit prefix, or don’t include the opera prefix. As both the -o- prefix and -webkit- prefixes are counted as the same specificity, order wins out and the webkit prefix will be used if both are specified. You probably want the o prefix to be used for Opera, especially if you have to override something, so a useful suggestion is to order them in oder of the length of the prefix, like so:

-webkit-property
-moz-property
-ms-property
-o-property
property

This also has the benefit that it looks relatively neat, and its easy to spot if you have missed one once you are used to using this scheme. Each property gets one character shorter, except the initial webkit prefix.

This is one of the least critical updates to make in this post, but can prove to be useful.

Remove redundant prefixes

A number of commonly used CSS3 properties have been available without prefix for quite a while now, such as border-radius. In the recent past quite a few CSS specs have reached the stage where it is now considered ok for browser vendors to remove the prefixes. This includes Transforms, Transitions, Animations, Multi-Column Layout, Flexbox, and Image Values (primarily gradients). Different browsers are at a different state in the march towards removing prefixes, but some are ready to be removed, depending on how far back you have to support older browsers.

box-sizing

Internet Explorer and Opera have supported box-sizing without prefix since they were implemented, so the only prefixes you need to consider are for Gecko and WebKit based browsers. Firefox still needs to use the -moz- prefix to this day, but you can drop the WebKit prefix if you don’t need to support:

Chrome 9 and below (~0.30% marketshare)
Safari 5 and below (~0.74% marketshare)
Android 3 browser and below (> 60% active Android devices)
Safari on iOS 4.3 and below
BlackBerry 7 browser and below

Recommended usage:

-webkit-box-sizing: value;  /*evaluate removing as Android users upgrade */
-moz-box-sizing: value;
box-sizing: value;

box-shadow

The situation with box-shadow is almost exactly as for box-sizing in the previous section, except Firefox only needed its prefix in versions 3.5 and 3.6. Together, these current account for 0.77% marketshare.

Recommended usage:

-webkit-box-shadow: value;  /*evaluate removing as Android users upgrade or box-shadow usage is not critical */
box-shadow: value;

I would personally remove -webkit-box-shadow as it is not usually a critical piece of styling, unlike box-sizing, which could break layout.

border-radius

As with the previous two properties, Opera and Internet Explorer have supported border-radius without prefix since implementation. You can drop the -webkit- and -moz- prefixes if you do not need to support the following:

Firefox 3.6 and below (~0.95% marketshare)
Chrome 4 and below (~0.05% marketshare)
Safari 4 and below (~0.12% marketshare)
Android 2.1 and below (~3% active Android devices)
Safari on iOS 3.2 and below

Recommended usage:

border-radius: value;

The newer specs

The bad news is that you still need to use -webkit- in modern versions of WebKit for all of the specs in this section. The good news is that you do not need prefixes for gradients, transitions, transforms and animations starting from:

Internet Explorer 10
Opera 12.1
Firefox 16

In addition, prefixes have never been needed for all the specs above (except 2D transforms) in IE. 3D transforms are not implemented in Opera, but it is safe to assume it will be directly implemented without prefix.

I’d recommend to use the -webkit-, -moz-, -o- and the unprefixed version (taking into account the notes below for gradients), with the exception of keeping the -ms- prefix for 2d transforms and dropping the -o- prefix for 3d transforms. You may be able to consider removing the Firefox and Opera prefixes in the relatively near future, as users are upgrading at a fast clip, and these browsers don’t have the problem of the near glacial speed that Android devices update their OS.

Multi-column layout was implemented without prefixes in IE and Opera. Prefixes are still needed in Firefox and all versions of WebKit.

Flexbox has a storied history (see later in this post) and thus needs multiple different syntaxes and prefixes, but is supported by modern versions of all browsers. It is implemented without prefix in Opera 12.1.

Add Prefixless properties

As the specs mentioned are now ready to be implemented without prefix, it is also time for web developers to add the prefixless version to their code. In theory, these properties should not change now they have reached this strange, and there is general consensus in the CSS working group.

There are two schools of thought between developers. The first is to include the prefixless version when writing the original CSS. If you are in this school, you will just need to remove any redundant prefixes, but make sure you check the next section, as there have been breaking changes. The other school of thought is to not include the prefixless version. If you’re in this school, you’ll have to add all of these now. You’ll also need to check the next section to see how to do this.

Update to the new syntax

This is perhaps the most critical part of your spring clean. Especially if you are a tools developer, or have tutorials with a lot of foot traffic.

It is probably well known by web developers that border-radius changed to an alternative syntax from the original found in Firefox 2. It is probably also known that a similar thing happened with gradients, replacing the original Safari proposal. What is less known, and is certainly less updated in the wild, is that the syntax for gradients has changed again. Unless you changed your gradient code relatively recently, you’ll likely have a bunch of outdated code that needs to be updated.

New gradient syntax

Fortunately the new gradient syntax is easy to update to, and you only really need to make the update to the unprefixed version. You can keep all the prefixed properties with the old syntax. All of the latest browsers support this new syntax, with the exception of WebKit. Its true, WebKit is lagging IE!

The general rule is that if you use a direction keyword it needs to be reversed and be preceded by the to keyword. Thus:

background:  -prefix-linear-gradient(left, white, black);

Becomes:

background:  linear-gradient(to right, white, black);

If you use an angle, the starting point of the gradient line has shifted. Previously 0deg started at the East position. Angles increased in an anticlockwise direction, such that 90deg started at the North position. With the unprefixed syntax the gradient line for 0deg starts at the North position and the angle increases clockwise. The formula for switching from the old the new degree value is abs(oldDegValue − 450) mod 360.

For radial gradients the position keyword or length now needs to be preceded by the at keyword:

background: -prefix-radial-gradient(center, white, black);

Becomes:

background: radial-gradient(at center, white, black);

The cover and contain gradient size keywords are no longer supported. The cover keyword should be switched to farthest-corner and contain to closest-side.

Finally, if you specify a gradient position and a shape or size, the position should be specified last, thus:

-prefix-radial-gradient(center, 50px 25px, white, black);

Becomes:

-radial-gradient(50px 25px at center, white, black);

New flexbox syntax

The Flexbox syntax has changed more times than I can count. Fortunately, there is likely to be less content out there using the old syntax as there is with gradients, due to the fact the site will likely break if flexbox isn’t supported.

Currently, only Opera supports the new syntax without prefix. Chrome supports the new syntax with prefix since Chrome 21, Firefox is due to support the new syntax unprefixed in Firefox 20, but currently only supports the old syntax. IE supports a slightly older syntax, but not the same one as the older WebKit and Firefox implementations. Safari currently only supports the old syntax. To get the best cross platform compatibility you will need to include:

The latest syntax unprefixed: display: flex and friends. (Opera, Firefox 20, and probably Chrome in the near future)
The latest syntax with -webkit- prefix: display: -webkit-flex and friends (Chrome 21). You may want to drop this and rely on old syntax until WebKit goes prefixless
The old new syntax with -ms- prefix: display: -ms-flexbox and friends (IE10)
The old syntax with -moz- and -webkit- prefixes: display: -webkit-box (WebKit), display: -moz-box (Firefox

The spec is too involved to include a comparison tacked onto the end of this post, but you can read about how to spot the difference and see some demos of the old old and new new syntax on CSS Tricks. Chris does not include a demo of the old new (or is it new old) syntax, so you can look at Microsoft’s Flexbox documentation to find out more. I may do a full blog post on this in the near future if I find time.

Marketshare stats are taken from StatCounter for the month of December 2012. Active Android version stats are from Google’s official platform versions dashboard.

Mobile first: the revolution is well under way

Sun, 11 Nov 2012 21:34:00 -0800

A little over a year ago, I wrote a post about how countries in Africa were at the foothills of a mobile web revolution. Nigeria had just started seeing more web traffic on mobile devices than traditional desktop, and more countries were on course to follow that lead. This post looks at what progress has been made since then, and what the trends look like going forward.

Africa, millions of mobiles blossom

Nowhere more so than Africa, a real mobile revolution is underway. Since that post in September, the mobile market share vs desktop share in Nigeria has grown to over 70%. As then, the mobile share in many countries rises on weekends and drops during the week. Checking the stats today (11th November, a Sunday), each of the African countries mentioned in the previous post have a larger mobile share than desktop, except Tanzania (which has over 40% mobile share). A number of other African countries have also surpassed the 50% mark for mobile market share. It would be possible to travel from the Niger Delta on the west coast of Africa, to the horn of Africa on the east coast, without passing through a country where people surf more on desktop than a mobile phone.

The following map highlights those countries that are over one third and one half mobile traffic:

Mobile vs Desktop marketshare in Africa (Source: StatCounter)

Today was a particularly good day for mobile traffic, and many countries do drop below 50% mobile share on week days, but it shows the general trend, and progress since last September. The following table highlights this progression:

Country	Population	Mobile share: 11th November, 2012	Mobile share: 11th September, 2011
Nigeria	166,629,000	72%	54%
Ethiopia	84,320,987	59%	39%
Congo, DRC	69,575,000	45%	17%
Tanzania	43,188,000	43%	24%
Kenya	38,610,097	51%	34%
Uganda	32,939,800	43%	13%
Sudan	30,894,000	51%	30%
Ghana	24,658,823	38%	21%
Mozambique	23,700,715	38%	15%
Niger	16,274,738	55%	25%
Malawi	15,883,000	67%	35%
Mali	14,528,662	76%	5%
Zambia	13,092,666	60%	30%
Zimbabwe	13,014,000	76%	45%
Chad	11,274,106	93%	61%
Somalia	9,797,000	61%	13%
Sierra Leone	6,126,000	87%	20%
Liberia	4,245,000	40%	3%
Lesotho	2,217,000	51%	17%
Swaziland	1,220,000	43%	36%

Asia Pacific: a mobile giant has awoken

Back when I wrote the original post, no countries in Asia had more mobile traffic than desktop traffic. It was however clear that countries in South Asian were going along the same path as Africa. Fast forward over a year, and India has perhaps became one of the most important mobile web markets in the world. It is now consistently has more than 50% mobile traffic, and has became the country with the most Opera Mini users. With its vast population, it has a lot of room for growth.

Mobile vs desktop in Asia Pacific

The rest of Asia/Pacific hasn’t advanced as far as Africa, with only Turkmenistan, East Timor, and Papua New Guinea having more mobile traffic than desktop. However, it should’t be too long before Bangladesh (32%) and a number of the central asian countries progress to a mobile first future.

The rest of the world

In comparison, only Cost Rica in the Americas (16%), and the United Kingdom in Europe (19%) have over 15% mobile marketshare.

Smartphones or dumb?

Almost without exception, the top two mobile operating systems in those countries with higher mobile traffic were Nokia Series 40 and Nokia Symbian/S60. The exceptions are Mali and Papua New Guinea where the top OS is unknown (this usually means a proxy browser, which is likely running on a feature phone), and Turkmenistan, where Android has its sole victory.

Nokia Series 40 is firmly a feature phone OS, while Symbian is strictly a smartphone operating system, but the capabilities of phones running it are far from what many of us in the west would consider a smartphone. Many S60 phones don’t even use touch screens, unless they are of relatively recent vintage.

Full browsers or proxy?

Considering the operating systems in use, it is probably no surprise that proxy browsers dominate this landscape. Opera Mini is the most popular browser in all of these countries except Turkmenistan (Android) and Mali, where Nokia is the largest browser. It is not clear if it is Nokia’s Gecko based proxy browser or the full WebKit browser that rules the roost however. Considering the break down of OS, I expect a combination of both.

Looking ahead

It seems a long way off before the west posts the same sort of mobile to desktop ratio that Africa is exhibiting. If it ever does at all. Expect to see further mobile gains in Africa, especially in non-French speaking Sub-Saharan countries. Over in Asia, it seems like much of South, South East and Central Asia are poised to become mobile first countries by the end of next year. South Korea could be the exception in the industrialised world. It is currently sitting on 27%, well above that of neighbouring countries in East Asia, the US and the EU. Whichever way things pan out, it should be an interesting year for mobile web developers.

Flip Ahead and Fast Forward. Providing hints to detect the next page

Sun, 28 Oct 2012 20:09:00 -0700

Internet Explorer 10 introduced a new featured called Flip Ahead. This makes a best guess at detecting the next page, article, post, thread, product or so on. When the user performs a forward swipe gesture (or presses the forward button on a mouse) it loads the detected page. If this sounds familiar to you, you’ve probably heard about or used Opera’s Fast Forward feature. This is roughly the same concept (although Opera bundles in other things, such as logging in), and can be activated using a mouse gesture, or pressing the space bar when reaching the end of the page.

Both implementations use heuristics to detect the next page. For Opera they are defined in the fastforward.ini file. The location of this file can be found by enteringopera:config#UserPrefs|FastForwardConfigurationinto the Opera url field. I’m unsure of the exact heuristics employed by IE. Browsing history data is reported back to Microsoft to improve Flip Ahead, so I expect the heuristics will evolve time goes on. As the feature “phones home’ it is opt-in and thus disabled by default.

Provide hints to Flip Ahead and Fast Forward with rel-next

While both implementations can apply some advanced heuristics to detect the next page, the browser is basically guessing what is the most appropriate page. As a page author, you can directly give hints to the browser on what page you’d like to load when the Flip Ahead or Fast Forward action is performed. Make sure to specify a page that makes sense, otherwise you will confuse the user. Examples include the second page of an article if you use pagination, the next article on your blog, next page of search results, or the next image in a slideshow.

The best way to specify the next page is to use a link element in the head with rel="next":

<head>
    …
    <link rel="next" href="/page/2" />
</head>

This is the only approach I could find that works in IE (with limited testing in the Microsoft store) and has a number of advantages in Opera: it is the heuristic with the highest weighting, it uses standard markup that can lead to other benefits, and it is language independent. Other heuristics in Opera include looking for link text such as “more” or “next”. As each language uses different link text, the browser will only detect words for the languages it knows about.

In Opera, if you rely on link text within the page, the last occurrence of the term with the highest ranking wins. Due to this, you have to be careful not to introduce a new link with similar link text later in the document. This can be a major problem as the next page can be hijacked if you accept user generated content (such as comments on this blog). Links with rel="nofollow" are not ignored, so these links are considered when calculating which link should be the next page. Using a link element with rel="next" mitigates this risk.

I will update this post if I find out other ways to trigger Flip Ahead in IE. When spoofing as IE10 touch, the new MSN provides a rel-next link, but Bing does not, so I assume there are more heuristics. Their next page link uses “next” as the link text, but this doesn’t seem to be detected when I tried in a test file.

Other benefits of using rel-next

HTML4, and later HTML5 define rel=”next” as a valid sequential link type. This indicates the next logical document in sequence. As such, browser and search engine providers have adopted it to bring additional benefits.

SEO benefits

Google and other search engines support rel=”next” and rel=”prev” links. Adding these hints will allow the search engine to return more appropriate results, such as the first page of a multi-page article or the first image in a slideshow.

Prefetching in Firefox

If you have chosen the next page link wisely, it is likely that the user will want to visit that page. Possibly even more likely when the browser supports a method such as Flip Ahead to automatically detect it.

Firefox (and other Gecko based browsers) support a feature known as prefetching, which uses rel=”next” as a hint to load that resource in the background. The advantage of this is that if the correct page is prefetched, the loading time for that page will be reduced. As well as rel=”next”, you can also use rel=”prefetch” to prefetch a resource. The main difference is that rel=”prefetch” can be used on any type of resource, while rel=”next” should only be used for the next page, as it contains other semantics beyond being a prefetching hint.

Chrome supports something called prerendering which goes a step further and actually renders the page in the background after fetching it. This can be triggered using rel=”prerender” on the link element, and doesn’t support rel=”next” as far as I’m aware.

Wrap up

So there you have it. One little link element with rel=”next” and you get a whole host of benefits across three different browsers and the leading search engines. Just remember to choose the next link wisely, as it can degrade the experience if your site does something unpredictable.

Device screen resolutions ordered by OS

Tue, 23 Oct 2012 22:43:00 -0700

Its often a chore to track down what screen resolutions are supported by the various operating systems and devices that are commonly used on the Web. Vendor sites and developer guidelines are often helpful, but it means hunting down information across many sites and documents. Sites like GSM Arena are great, but it often means checking devices one at a time, and useful information for web developers are lost amongst the densely packed information that is of limited concern to us. As I was researching this information anyway, and I’m a bit of a data nerd, I thought I may as well catalogue the information on my blog for easy access at a later date. If the information is of use to anyone else, then all the better.

I’ve grouped the data by operating system, version, and device type, as I wanted to see what resolutions needed to be supported to broadly cover a particular OS. Not surprisingly, some of the more closed operating systems have tighter control and consistency potentially making them easier to support, while more open operating systems have a plethora of different resolutions and aspect ratios.

As Android is particularly varied, and impossible to predict which devices get updated to a subsequent version of the OS, I’ve kept all versions grouped together. The exception is Cupcake and below, as Android only supported one resolution at that time, making classification easy.

I only included operating systems (and versions) that are currently popular on the Web, or I suspect will be in the future. For feature phones, I used the information I gathered from Opera Mini stats to figure out what devices are still popular. I ignored desktop operating systems, as they are too varied to cover without spending longer than I wanted to on this study.

Other information I’m considering adding includes pixel density (but this varies widely as many devices have the same resolution but different physical sized displays), and the device pixel ratio (although this can vary depending on the browser used).

Without further ado, here is the data:

Smartphones

iOS: iPhone and iPod Touch

Name	Resolution (px)	Aspect Ratio
HVGA	480×320	3:2
DVGA	960×640	3:2
Unknown	1136×640	16:9

Android

Cupcake and below

Name	Resolution (px)	Aspect Ratio
HVGA	480×320	3:2

Donut and above

Name	Resolution (px)	Aspect Ratio
QVGA	320×240	4:3
WQVGA	400×240	15:9
HVGA	480×320	3:2
nHD	640×360	16:9
VGA	640×480	4:3
WVGA	800×480	15:9
FWVGA	854×480	16:9
qHD	960×540	16:9
DVGA	960×640	3:2
HD 720p	1280×720	16:9
XGA	1024×768	4:3
WXGA	1280×768	15:9
WXGA	1280×800	16:10
HD 1080p	1920×1080	16:9

Windows Phone

Microsoft specifies the resolutions that are support for each version of Windows Phone. This ensures consistency between devices.

Windows Phone 7

Name	Resolution (px)	Aspect Ratio
WVGA	800×480	15:9

Windows Phone 8

Name	Resolution (px)	Aspect Ratio
WVGA	800×480	15:9
HD 720p	1280×720	16:9
WXGA	1280×768	15:9

Symbian

S60, 2nd Edition

Name	Resolution (px)	Aspect Ratio
Unknown	208×176	13:11

S60, 3rd Edition

Name	Resolution (px)	Aspect Ratio
QVGA	320×240	4:3

S60, 5th edition to Nokia Belle (neé Symbian Belle)

Name	Resolution (px)	Aspect Ratio
nHD	640×360	16:9

BlackBerry OS

BlackBerry 5

Name	Resolution (px)	Aspect Ratio
QVGA	320×240	4:3
HVGA	480×320	3:2
Unknown	480×360	4:3

BlackBerry 6

Name	Resolution (px)	Aspect Ratio
QVGA	320×240	4:3
Unknown	400×360	10:9
Unknown	480×360	4:3

BlackBerry 7

Name	Resolution (px)	Aspect Ratio
QVGA	320×240	4:3
Unknown	480×360	4:3
VGA	640×480	4:3
WVGA	800×480	15:9

BlackBerry 10

Name	Resolution (px)	Aspect Ratio
Unknown	720×720	1:1
720p	1280x720	16:9
WXGA	1280x768	15:9

Note: The 1:1 display is the standard size for all keyboard BlackBerry 10 devices. 720p is the standard size for all BlackBerry 10 touch devices. WXGA is a one off resolution for the BlackBerry Z10 and the developer device.

MeeGo: Harmattan

The only smartphone released commercially with MeeGo was the Nokia N9 with the Harmattan variant.

Name	Resolution (px)	Aspect Ratio
FWVGA	854×480	16:9

Maemo

All versions

Name	Resolution (px)	Aspect Ratio
WVGA	800×480	15:9

Note: Not all Maemo devices are phones, and they’re not particularly popular (outside of a blip in Finland), but the Nokia site made it easy to find the information, so why not?

Firefox OS

Name	Resolution (px)	Aspect Ratio
HVGA	480×320	3:2
qHD	960×540	16:9

Note: The higher end Geeksphone Peak developer preview phone supports a qHD display, while the lower end, and currently announced consumer devices from ZTE and Alcatel support HVGA. Specs from OEMs such as Sony and LG have yet to be announced. This section will be updated when the information is available.

Feature phones

I’ve only included feature phones that have names and are relatively well known, as it is much easier to research data that way. Bada and later versions of Series 40 could be considered low end smartphone operating systems, and are sometimes marketed as such. I’ve kept them separate from smartphones as they are usually aimed at a very different market segment.

Nokia OS/Asha Platform

Series 40, 3rd Edition to Developer Platform 1.x

Name	Resolution (px)	Aspect Ratio
Unknown	160×128	5:4
QVGA	320×240	4:3
HVGA	480×320	3:2

Note: the HVGA resolution was only found on one device; the Nokia 6260. This has a higher resolution than any subsequent Series 40 devices.

Series 40, Developer Platform 2

Name	Resolution (px)	Aspect Ratio
WQVGA	400×240	15:9

Asha Software Platform 1.0

Name	Resolution (px)	Aspect Ratio
QVGA	320×240	4:3

Note: the Asha software platform is yet another rebranding of the S40/Nokia OS platform. It has the same APIs as Developer Platform 2, with additional localisation (JSR-238) and platform APIs. Web Apps use the Gecko engine.

Bada

Bada 1.x

Name	Resolution (px)	Aspect Ratio
WQVGA	400×240	15:9
WVGA	800×480	15:9

Bada 2

Name	Resolution (px)	Aspect Ratio
HVGA	480×320	3:2
WVGA	800×480	15:9

Tablets

iOS: iPad

Name	Resolution (px)	Aspect Ratio
XGA	1024×768	4:3
QXGA	2048×1536	4:3

Android and derivatives

The NOOK and Kindle tablets are also included in this list. Each model shares a common resolution with an already included standard Android tablet.

Name	Resolution (px)	Aspect Ratio
WSVGA	1024×600	17:10
XGA	1024×768	4:3
WXGA	1280×800	16:10
WXGA+	1440×900	16:10
WUXGA	1920×1200	16:10
WQXGA	2560×1600	16:10

Windows RT

All Windows RT tablets currently have a WXGA display. This is the minimum specified by Microsoft. Future tablets may have higher resolution displays.

Name	Resolution (px)	Aspect Ratio
WXGA	1366×768	16:9

Note: Windows RT includes a “Snap Mode” feature. This displays an app or web page in a sidebar, pinned to one side of the screen. The snapped view takes up 320px, the splitter control takes up 22px, and the remainder for the fill view (the regular web page). On current Windows RT machines, this leaves 1,046×768 for the main web page.

To optimise your site/app to work in the snapped view, you must use the @viewport CSS AtRule.

BlackBerry Tablet OS

Name	Resolution (px)	Aspect Ratio
WSVGA	1024×600	16:9

E ink eBook readers

eBook readers are not particularly popular for surfing the Web, but I thought it would be fun to include them. They all share common resolutions, so are grouped together.

Name	Resolution (px)	Aspect Ratio
SVGA	800×600	4:3
XGA	1024×768	4:3
Unknown	1200×824	150:103

TV

TVs share a set of standardised resolutions, so all platforms are grouped together. I should include SD resolutions at a later date, as the Wii does not support HD.

Name	Resolution (px)	Aspect Ratio
HD 720p	1280×720	16:9
HD 1080p	1920×1080	16:9

Public service announcement: You (probably) don’t need to escape quotes in strings

Thu, 18 Oct 2012 16:36:00 -0700

When reading a programming book or online reference, you will invariably see something like the following when describing how to include quotes within strings:


// use single quote (or apostrophe) character for JS strings, double quotes for quotes
var quotedString = 'This is a string "with a quote" inside it';

// otherwise use the backslash character (\) to escape quotes and apostrophes
var anotherString = "This is a string with an escaped \"quote\" inside it";

While this is useful advice for teaching escape sequences–which you will probably need when including HTML, CSS or other languages inside strings–you don’t need to do it when including English text.

Its ok if you don’t know this, as we’re getting into the realms of typographic geekery that the average developer or programming book author doesn’t delve into, but let me explain.

A little history

The quotation marks we often see inside strings and all over the web today are commonly called straight (or ambidextrous) quotes. They are ” (U+0022 - quotation mark) and ’ (U+0027 apostrophe) respectfully. Their unicode name doesn’t help the confusion one bit.

Back in ye olde days when we had beautiful typography, and all was well in the world, quotes were nice and curvy. We opened quotes with a single ( ‘ ) or double ( “ ) left quotation mark and closed it with a single ( ’ ) or double ( ” ) right quotation mark.

When the typewriter was invented, space for all the mechanics needed for the keys was limited. Instead of taking up four keys, plus addition ones for prime ( ′ , used for feet, arc-minutes and minutes), double prime ( ″ , used for inches, arc-seconds and seconds), ditto (〃) and so on, generic straight quotes were added instead.

Typewriters are long gone, but then came the problem of the ASCII character set. It had limited space for characters due to the primitive storage and memory requirements at the time, so it too only included the straight quote marks.

We have since outgrown typewriters and ASCII, with Unicode prevalent on most computers (and devices) today. So lets set our quotes free of this legacy restriction and allow them to flaunt their curves.

Unescaped quotes in strings

Now armed with the knowledge of the correct quotes to use, we can include them in our strings without fear of escapes. It even saves two characters per quote:


var curvyQ = "This is a string with “correct unescaped quotes”.";
var apostToo = 'Don’t use straight quotes, and avoid needing to escape.';

As can be seen above, apostrophes have the same issue and solution, with the right single quote mark used instead of the straight quote. Actually there are multiple apostrophes such as ( ʼ ) Letter apostrophe, U+02BC, but you most likely don’t need to know about those.

Typing these fancy quotes

Word processors with smart quotes turned on will swap out straight quotes for curvy quotes, but they sometimes get it wrong, can be plain annoying when you want straight quotes (such as when typing code), and few developers likely code in MS Word or OpenOffice.

Fortunately, on the Mac at least, they are easy to type by hand. On a US keyboard they are alt-[ (left double quote), shift-alt-[ (right double quote), alt-] (left single quote) and shift-alt-] (right double quote). For other keyboard layouts your milage may very, but the keyboard viewer menu item will help you to find them.

It looks like it is a whole lot more difficult to type them on Windows, unless things have changed since that article, and my last experience on that OS. But, you can always set up your own shortcuts.

If you don’t want to type them by hand, you can use the unicode escapes or HTML entities, but I find this makes the source code less elegant and harder to read.

What about the `q` element

All kinds of developers get this quote thing wrong, including browser developers. If you include the q element in your HTML, Firefox and Chrome will use the correct quote marks, but Safari and Opera use straight quotes.

Fortunately you can use CSS to correct this:

q, q:lang(en) { quotes:"“" "”" "‘" "’"; }

Bear in mind that different language use different quote marks (Including British English, but it just reverses the nesting order between single and double quotes), so if you have a multi-lingual site you may want to look up the other quote marks and make use of the lang pseudo-class.

When you do need to escape quotes?

As far as I’m aware, the only time you actually need to use straight quotes is when programming, such as for surrounding attribute values in HTML (and then only when the value has a space), strings in JavaScript, and so on, but not in written language.

Realigned.

Fri, 12 Oct 2012 19:06:00 -0700

It has been just over a year since I moved from my old blog at My.Opera.com to the Tumblr blog you’re reading now. In that time I persevered with a slightly modified built-in theme, that wasn’t really designed for long form blogging. As things broke, I fixed them, but the code was getting messy, and the Disqus integration was acting all kinds of weird.

I knew that with my kind of experience with web technology, I should really have a theme of my own, that fit my particular needs. As I was laid off recently, there is no time like the present to give the blog a complete overhaul. What you see now is the result of that labour.

The redesign

The initial seeds of the idea for the blog theme came around a month ago. I designed the website for the Montage and Ninja projects at Motorola, while the project was in stealth mode, and so I was limited in the amount of developer outreach I could do. For that project I used a lot of noise textures. As time went on I got more and more jaded with seeing these kind of effects all over the Web. I knew when I got around to redesigning my own blog, I wanted to go as much towards the minimalist stripped down aesthetic as possible. I wanted to keep just the amount of detail that was needed to get the design across. Above all else, I wanted something original.

In many ways it is ironic. I‘ve been talking about CSS3 for years, all the way back to the early years of CSS3.info and my work with Opera even before that. In those days we longed to be able to move away from square corners, and be able to lift the design with shadows and graphical flourishes. Now that we are finally at the stage where many of the CSS properties that allow us to achieve those effects have got prefixless in the major browsers, here I am designing a theme that almost requires none of that. Indeed, this blog design could easily have been done ten years ago with almost the same lack of images.

Colour palette

After deciding on the stripped back look, the next thing I wanted to do was play with colour. Its my weakest point as a (pretend) designer. I know next to nothing about colour theory. Well, actually, my weakest point is that I’ve no idea how to use Photoshop (or any tools of its ilk), and actually prefer to code up in CSS. So choosing colours was going to be a challenge to get me out of my comfort zone. I made it a no-no that I could just fall back to the neutral tones and strong photographic imagery I usually rely on in my designs.

Orange was a colour that kept coming into my head. Its a colour that cropped up in a photo I used in a demo recently, and I’ve seen it used with striking effect in print design. I knew I wanted to try moving in this direction when looking at images of the classic Gulf Ford GT40. As a sucker for retro styling, I thought “This is it!”. And so the foundations were in place for the other other accent colour was also in place. The blue and orange just worked so well together, without being too trendy. In the end I rejected that blue after trying over and over to get something legible in place, and I put the design on hold. I ended up with a different blue by chance when playing around while bored on a flight back from London after a trip to the Netherlands.

The blue was most likely unconsciously inspired by KLM even though I was flying United at the time. In any case, the whole colour scheme looks fairly dutch, and I was remising at the time how bad United’s design is now it has merged with Continental and dropped the Saul Bass Tulip (Dutch again!) logo. It was partly this disappointment of the state of design around me compared to European airlines that inspired me to start working on my design again.

Typography

The typography in this design actually came last, which is unusual for me. It is often the first thing I do. I still consider this design a prototype, and have a lot of work to get the ratio between different headings and sections correct, and the whole vertical rhythm sorted out. I went for the safe option here, after the daring colours, and plucked for Helvetica Neue. I may revisit this in the future when I’ve lived in the design some more.

For the main headings, menu, and logo, I wanted to try something else, and went with the free (and bizarrely named) Ostrich Sans font from League of Moveable Type. The logo uses the light font, an the headings use the black variant.

Layout

The layout is where I did follow a trend, and went for a mobile first, responsive design. Well, not exactly mobile first, as I designed around how the design looks at specific widths rather than to common mobile sizes.

I wanted to keep the side bar I had in the current design to keep a link to the past, but increased the size to give the design some balance at larger widths. I actually looked at work from print designers such as Jan Tschichold to get inspiration here, although didn’t stick to the golden section any more than as an initial inspiration for the margin sizes. You can see s crop of the initial design on my Dribbble account. The main change in the final design is the logo placement, and the tags.

I knew the sidebar would become problematic at smaller sizes, so I first did a narrow design with the logo and menu across the top of the page. This more or less stayed unchanged in the final design.

Design process

While I’d love to say I designed in the browser, I actually built the design sketches in Keynote. Although I’m happier working in code than tools like Photoshop, I love using Keynote to quickly experiment placing and deleting elements on the page. I find it is incredibly easy to use and just powerful enough to be able to implement a lot of ideas, without being too complex to get in the way. The restrictions it has also places some boundaries that allow me to focus rather than play around too long with all kinds of crazy ideas.

While Keynote is great for initial experiments and layout (except the restricted canvas size), I find text styling and layout much harder than in CSS and the effects such as shadows render differently. So, after the initial exploration phase, I usually move over to a text editor to code up and finish off the design.

The recode

The coding aspect of this design is perhaps less interesting. It took about as long as the design (approximately 1 day, with another half day for nips, tucks, bug fixes, adjustments for mobile, and procrastination. Old content also has to be updated to fit the new heading structure, and add hooks for Prism integration for the code snippets, but that is a job for another day.

CSS

As mentioned, there is very little visual effects, so there are not too many techniques to learn or be inspired by. I actually did use some CSS3 for the text and layout, as I used the rem unit and box-sizing (my only prefix) to make measurements easier to calculate, and hyphens for the text. Other than that, I used Media Queries to make the design responsive.

I’ve mainly tested the layout on desktop browsers, and still have some work to do to ensure that mobile and tablet browsers get the right layout, and don’t break when zooming. I have some bugs to iron out here. I also need to add a fallback to the rem unit so that it works better in Opera Mini.

I also need to fix the web fonts in Firefox, which suffers from cross origin restrictions.

HTML template

The HTML is perhaps more modern, using HTML5 structural elements, rather than just using the doctype and pulling out the buzzword. I based the template off the original theme as a starting point, but more or less ripped it all out, except for the parts around Tumblr integration and the non-text post types that I’ve not looked into yet.

The logo

The logo is done in SVG. Most of the time was spent wrestling with Inkscape so that I could change the font glyphs to paths rather than use another web font. Design tools insert a lot of non-optimal markup, so I cleaned it up somewhat by hand. I’ll leave cleaning the paths to another day. Probably by running it through Scour.

The complete picture

I think I’m happy with how it turned out in the end. Using orange as the background colour for the text was something I worried about doing, and I still am to some extent. How much will the colour distract the reader from the actual content? I need to live with it some more to really know, but the issue is less than I initially feared when floating the idea. I also worried about black text on orange giving a dirty feel (as the orange couldn’t be too vibrant), but the freshness of the blue on white in the sidebar adds a freshness that overcomes that issue.

Will I stick with it? Who knows, but I’ll give it a try, iterating as I go, and see what people think.

See your site like the rest of the world does. On the Nokia X2-01

Wed, 12 Sep 2012 19:41:00 -0700

In our world of ever increasing high resolution displays, multi-core, multi gigahertz processors, 4G networks and touch enabled experiences, it is often easy to forget how the rest of the world lives.

Beyond the latest iPhones, and Android devices, there are a multitude of devices out there, enabling the next billion to experience the World Wide Web for the first time. Move away from the wealthy few of the industrialised world, and a whole different picture emerges. One that might be familiar to those of you who were pioneers on the mobile web; before the iPhone came out and changed our mobile experience forever.

Entering long URLs and form data on a keypad designed for entering phone number and typing txt messages, not for writing novels, navigating with arrow keys instead directly touching the object on the screen. Running out of memory on large pages, or simply getting lost as the page layout was too complex for the tiny screen you were using.

The browsers have gotten better since then, but surprisingly many of the devices used in the developing world haven’t significantly. Sure, the raw horsepower may have gone up, and more memory means less of those dreaded out of memory errors. But, key attributes that web developers care about, such as screen size and resolution, and input method are still stuck in the previous era.

These restrictions are an everyday reality for those that are not as lucky as we are, with our super computers in our pockets. If you care about keeping the World in WWW, and ensuring the content you create is accessible to all, then it will be a reality for you as well.

Lack of access to online information is only increasing the digital divide. However rudimentary their devices may be, being able to access information on their mobile phone is as empowering for them as it has been for us, if not more so. As Bruce Lawson wrote in his great post on the Opera DevRel team blog Comparison between Indian states shows that a 10% increase in mobile phone penetration rate leads to a 1.2% increase in GDP. Having access to information helps people help themselves. The video in Bruce’s post helps put a face to some of those people, and a window into the joy they experience when being able to access the Web.

If you publish information on the Web, I can’t encourage you enough to try design your site with these devices in mind. No, they don’t need to look the same; you don’t need every wizz bang transition, or rounded corner, but having clear navigable access to the content of your site at small screen sizes and via keypad input is invaluable.

If you use Media Queries, add tests to make sure the layout doesn’t break down at small sizes. If you have a separate site, make sure it still works when the screen size is even smaller that you may have tested already.

To make it clear I’m talking here about sites with informational content. Its a whole different challenge for JavaScript heavy apps meant to compete with native apps. Although there is demand for these kind of sites in the developing world, with Facebook the number 1 site across much of the globe, it will require much more than a bit of extra testing and attention to details to get these sites working on basic phones.

What is the average phone used by the rest of the world?

Great you should ask, as I’ve just spent the last few days poring over the facts, and collating all the details I could find. Details are quite hard to get a hold of, with even StatCounter (which is good about breaking down its data per country) only breaking down per screen resolution. Fortunately, as Opera Mini is a proxy browser–and is the most popular browser in much of the developing world–it has reams of data on what devices access the Web through its servers. Opera publishes this data through its State of the Mobile Web series. Sadly, Opera are much less forthcoming with the data that is useful to us than it used to be, but there is still a lot of useful info that we can dig out.

I couldn’t focus on every country in the world, as that would have simply taken too much time, so I narrowed down the study to the BRIC and Next 11 nations. These are 15 countries that Goldman Sachs identified as having a high potential for becoming the world’s largest economies in the 21st century. They also happen to all be countries where Opera Mini has a strong market share or user base, meaning that the Mini data will be highly relevant to the countries as a whole. I made one exception to this list, replacing South Korea with South Africa. The reason for this is that I feel like South Korea is much more like a developed nation these days, especially when considering mobile and internet access, and Opera Mini doesn‘t have such a relevant market share there. South Africa seemed like a good replacement, as it is one of the strongest African economies, and has always been a leading Opera Mini country.

The full list of countries (with population in parenthesis) includes:

China (1,347,350,000)
India (1,210,193,422)
Indonesia (237,641,326)
Brazil (193,946,886)
Pakistan (180,646,000)
Nigeria (166,629,000)
Bangladesh (152,518,015)
Russia (143,142,000)
Mexico (112,336,538)
Philippines (92,337,852)
Vietnam (87,840,000)
Egypt (82,540,000)
Iran (75,149,669)
Turkey (74,724,269)
South Africa (50,586,757)

The list includes 8 of the 10 most populous countries in the world, the most populous countries in Asia (China), Europe (Russia), and South America (Brazil), and the second most populous in North America (Mexico).

For each country, I looked at the top 10 devices used by Opera Mini users, and categorised them by attributes that are of interest for web developers. Sadly, Opera doesn’t have information on the top devices outside of Africa, Asia and Latin America for 2012, but I collected previous year’s information where available.

To check that the data from the leading developing nations was a valid representation of the region as a whole, I cross-referenced the data with the top 10 devices in each of the other countries in Africa, Latin America, and the Asia/Pacific region.

There are a huge number of different devices, but in general many fall into similar categories based on screen resolution and input method.

Screen size and resolution

There were 8 resolutions over the top ten phones in each of the studied countries. Two of these were the same resolution, just flipped between portrait and landscape orientation. Three were only found in Latin America, two of which cover the range between top end feature phones and bottom end smart phones.

QVGA Landscape (320×240)

All of the phones using landscape QVGA had 2.4 inch displays, giving around 167 ppi pixel density. This resolution has a 4:3 aspect ratio.

Phones with the resolution included the Nokia X2 01, Nokia C3, Nokia Asha 200, Nokia E63, Alcatel OT-808, Alcatel OT-800, Alcatel OT-802, Samsung Ch@t 335 (S3350), and the BlackBerry Curve 8520.

QVGA Portrait (240×320)

The phones in this category ranged from 2.0 inches (200 ppi) to 2.6 inches (154 ppi). The exception was the Samsung S3850, which has a 3.2 inch screen (125 ppi), and the Samsung Galaxy Y S5360 with a 3 inch screen (133 ppi).

Phones with this resolution include the Nokia Asha 303, Nokia 2700C, Nokia 2730C, Nokia 5130, Nokia X2 00, Nokia 6300, Nokia C2 01, Nokia N73, Nokia 3208c, Nokia 5000, Nokia 7020, Sony Ericsson K800, Samsung Galaxy Y S5360, and Samsung S3850.

Approximately QQVGA (128 x 160)

These phone are 8 pixels wider than the standard 120x160 resolution, but this is a common size with older feature phones. All Nokia phones with this resolution have a 1.8 inch display, giving them a pixel density of 114ppi. The one Samsung device has a larger display, coming in at 2 inches and a pixel density of only 102 ppi. Luckily this was the smallest resolution in the study.

The phones using this resolution included the Nokia C1, Nokia 2690, Nokia C2 00, Nokia 2330c, Nokia 2220 slide, and Samsung E250.

nHD (640×360)

nHD seems to be a resolution unique to Nokia, used in its touch based S60 phones. These phones have an aspect ratio of 16:9, and 3.2 inch displays. This brings the pixel density in at around 229 ppi.

These were the closest we got to smartphones in the study. Two devices used this resolution; the Nokia 5233 and Nokia 5230. In the screenshot below the screen looks a lot bigger than it would in real life.

176×208

I couldn’t find the name for this resolution, but it is the common resolution for old non-touch S60 devices. These would have been considered smart phones back in the day. All phones with this resolution used 2.1 inch displays, with a pixel density of around 130 ppi.

The resolution was used on the N70 and N72. These phones seem to be dying out as time goes by.

220×176

This doesn’t seem to be a named resolution, but is common in lower end feature phones from various manufacturers. It is usually found in landscape oriented 2 inch displays, with a pixel density of around 141 ppi. This was the resolution used in the iPod Color.

This resolution can be found in the Motorola MOTOKEY Mini EX108 and EX109. Both of which are variations of the same phone and are only found in the top 10 in Brazil.

WQVGA (400×240)

WQVGA screens are usually 3 inch portrait touch screens found in higher end feature phones. They have an aspect ratio of 4:3, and a pixel density of around 155 ppi.

Phones with this resolution include the LG GM360 Viewty Snap and Samsung Star TV (S5233T), which have only made the top 10 in Mexico.

It is also found in top of the range feature phones that have not made the top 10 lists yet, such as the latest Nokia Asha Touch devices, and a number of Samsung Bada devices (usually with a slightly bigger 3.2 inch display).

HVGA (480×320)

This is the resolution made famous by the first 3 generations of the iPhone, so most web developers have an intimate knowledge of how to design for it. These days it has trickled down to lower end smart phones. It is often found in a 3.5 inch capacitive touch configuration.

Only one device was found with this resolution in the top 10 of the 15 countries studied, and it was not the iPhone. It was the Samsung Galaxy Ace S5830, which was 4th most popular in Mexico, and also popular throughout Latin America.

Input method

If the most common resolution of 320×240 or 240×320 wasn’t music to your ears, the news is worse on the input front. The good news was that the input method largely corresponded to the resolution and orientation, so we can group large amounts of devices in classes.

Numeric keypads

Phones with numeric keypads included:

All Portrait QVGA (except Samsung S3850 and Nokia Asha 303)
All 128x160
All 176x208

QWERTY keypads

All landscape QVGA devices had QWERTY keypads. These were the type located under the display, as commonly seen on a BlackBerry device. The Nokia Asha 303 has a QWERTY keypad under a portrait QVGA display.

Resistive touch screens

All the nHD devices have resistive touch screens, as do both the WQVGA devices in this study. The Nokia 3208C (QVGA portrait display) also has a resistive touch screen in addition to a numeric keypad. This is a China only model.

Capacitive touch screens

This is the type of display we now come to expect, and usually design our mobile experiences around. Unfortunately this was only found in three devices; the Samsung Galaxy Ace S5830, the portrait QVGA Samsung S3850 and Nokia Asha 303. The latter also has a QWERTY keypad under the display. Newer WQVGA devices–which have yet to make the top 10 list–may include capacitive displays.

Operating Systems

This information is not hugely useful for web developers, but can be interesting to classify the devices.

Nokia OS (S40)

This was the most common OS by far. This is considered a feature phone OS, and apps are quite often developed using Java. Opera Mini for example is a Java app on S40.

All QVGA (of either orientation) phones from Nokia were S40 devices except the E63 and N73. I also believe that the 128x160 phones are S40, but they could be S30.

Symbian (S60)

The 176x208 devices use Symbian 8.1, the N73 and E73 use Symbian 9.1 and 9.2 respectively, and the nHD touch screen devices use Symbian 9.4.

Other

The Sony Ericsson, Alcatel, LG and Samsung phones used their own feature phone OS rather than any named smart phone operating systems.

Outside of Symbian, only two of the devices used what are now commonly considered smart phone OS; one Android device (Samsung Galaxy Ace), and one Blackberry (BlackBerry Curve 8520). Both are lower-end devices.

Data

The area where most phones diverged was their data capabilities, although Class 32 GPRS and EDGE is the most common. All except two of the portrait QVGA and one of the Landscape QVGA phones from Nokia supported this. Ironically the Nokia Asha 200 is the newest phone and has slower data capabilities.

The other phones supported everything from class 12 GPRS and EDGE to class 10 GPRS and no EDGE.

Only one phone (the Nokia C3) supported WiFi (b/g), so don’t expect this if you’re targeting developing countries. All the data coming down the pipe the users are paying for, unless they’re on some sort of unlimited plan or have free minutes (or find a hack for Opera Mini, such as has happened in Nigeria and Mexico in the past).

In conclusion

Popular phones in the developing world can currently be largely grouped into the following categories (ignoring the older symbian devices):

Portrait keypad

Numeric keypad with QVGA portrait display, Class 32 GPRS/EDGE, no Wifi, and Nokia S40 OS. Data access potentially slower.

Numeric keypad with 128x160 display. Widely varying data access speeds, at most 2G. No WiFi. Nokia S40 OS.

Portrait QWERTY

QWERTY keypad in a portrait phone. QVGA landscape display, Class 32 GPRS/EDGE, no Wifi, and Nokia S40 OS. Data access potentially slower. Newer devices and Blackberries may have WiFi.

Portrait full screen

nHD display with resistive touch screen. Class 32 GPRS/EDGE, no WiFi and Symbian 9.4 OS

The most popular devices

It is difficult to tell which device is the most popular, as there has been no global figure since November 2011. At that time, the most popular phone was the Nokia 5130 XpressMusic. This is a Portrait QVGA (240×320) device. Six of the top ten were in this configuration, one was a landscape QVGA device, and three were 128x160 devices.

Things change slowly in the feature phone world, but I suspect things have moved a bit, with slightly newer phones starting to become popular.

We can only use countries in Asia, Africa, and Latin America to judge which phones are the most popular this year, but the Nokia X2 01 (a landscape QVGA device) tied with the venerable Nokia 5130 XpressMusic with two countries where it was the most popular. These were India and Indonesia (1st and 3rd largest Opera Mini countries respectively) for the X2 01, and China and South Africa for the Nokia 5130. Other major countries where the X2 01 is the most popular phone include Kenya, Ghana and Zimbabwe, while the 5130 is most popular in Egypt and Tanzania. As a newer phone, the X2 01 is certainly on the rise, but how popular it is in countries such as Russia will go a long way deciding which ends up on the top of the pile.

The C3 beat both of them out with three countries where it is the most popular; Mexico, Brazil, and the Philippines, but these countries are lower ranked in terms of Opera Mini users than those where the 5130 and X2 01 are the most popular. It is certainly a strong contender for the title of top device.

Nokia X2 01 - Landscape QVGA

The Nokia X2 01 can be considered one of the more modern replacements for the XpressMusic (the X series stands for Xpress). This particular device was released in January 2011 and is moving up the rankings.

Asian, Latin American and African countries where it is the most popular:

Angola
Botswana
Gabon
Ghana
Kenya
Mauritania
Zimbabwe
India
Laos
Cambodia
Indonesia

Other rankings (in 15 countries studied):

Brazil, Nigeria, South Africa
Vietnam
Bangladesh
Philippines

As a relatively new phone, it didn’t feature in any of the top ten last year.

Nokia 3150 XpressMusic

The Nokia 3150 XpressMusic has been the number one phone for at least the last two years. It was released back in February 2009. It is starting to drop in the rankings in a number of top countries.

Asian, Latin American and African countries where it is the most popular:

Benin
Burundi
Egypt
Lesotho
Libya
Malawi
Mozambique
Namibia
Seychelles
South Africa
Swaziland
Tanzania
China
Nepal
Myanmar (Burma)
Thailand

Other rankings (in 15 countries studied):

Bangladesh, Vietnam
Indonesia, Phillipines
India
Nigeria

In the countries where there is currently no data for this year, the 3150 XpressMusic was the leading device in Pakistan, 2nd in Iran and Turkey, and 3rd in Russia.

Nokia C3 00

The Nokia C3 00 is a landscape QVGA device, in much the same vein as the X2 01, except it does include WiFi. It was released in June 2010. It has the largest number of countries where it is the most popular in Asia/Pacific, Latin America and Africa, including three of the fifteen countries studied. It is the dominant phone by far in Latin America.

Asian, Latin American and African countries where it is the most popular:

Mexico
Guatemala
Honduras
Nicaragua
Panama
Dominican Republic
Colombia
Brazil
Ecuador
Bolivia
Paraguay
Chile
Argentina
Malaysia
Singapore
Brunei
Philippines
Timor-Leste
American Samoa
Australia
New Zealand
Algeria
Morocco
Senegal
Gambia
Guinea-Bissau
Eritrea
Djibouti
DRC
Comoros
São Tomé and Príncipe

Other rankings (in 15 countries studied):

Indonesia
Egypt
Nigeria, South Africa
Vietnam, Bangladesh

In the countries where there is no data for this year, the Nokia C3 was 1st in Turkey, and 4th in Pakistan.

Nokia 2700 classic

The Nokia 2700 classic is a portrait QVGA device is similar to the 5130 XpressMusic in characteristics. It has been the second most popular phone for two years, originally being released back in July 2009. It is most popular in two of the countries studied; Bangladesh and Vietnam, and also most popular in two of the top 10 african countries; Ethiopia and Sudan. It also has a strong showing in 2nd and 3rd in a number of major countries.

Asian, Latin American and African countries where it is the most popular:

Chad
Ethiopia
Liberia
Sudan
Tunisia
Mongolia
Bangladesh
Vietnam

Other rankings (in 15 countries studied):

China, Egypt
India, Nigeria, South Africa
Indonesia
Phillipines

In the countries with no data for this year, the Nokia 2700 classic was the leading device in Russia, 2nd in Pakistan, 3rd in Turkey, and 6th in Iran last year.

Nokia C1

This is where the groans might come in. The Nokia C1 is a 128 x 160 device, which importantly is the most popular phone in Nigeria. Although this is the only country it is the most popular, Nigeria has the most users of any African country.

Curiously the C1 was only 4th last year, with the three phones above it all being QVGA portrait phones. I’m not sure why this is, unless the proliferation of the mobile web in Nigeria means that more users are getting online that can only afford even more basic phones.

Other rankings (in 15 countries studied):

India, Egypt
Bangladesh
Philippines, South Africa
Vietnam
Indonesia

In the countries where there was no data for this year, the C1 was 5th in Pakistan, and 10th in Turkey.

Alcatel: An honourable mention

While this list is hugely dominated by Nokia, Alcatel’s influence is slowly starting to grow under the radar. Less well know than Samsung or Sony, or even Chinese brands like Huawei, a number of its phones (still feature phones, not Android) were the top phones in Africa and Latin America, and broke the top ten in some Asia/Pacific markets, and Mexico. It was particularly popular in Western Africa:

African and Latin American countries with Alcatel as the most popular phone:

Alcatel OT-606 Chat (portrait QVGA keypad phone, with slide out landscape QWERTY keyboard.)

Cameroon
Côte d’Ivoire
Equatorial Guinea
Madagascar
Republic of the Congo
Togo
Peru
Uruguay
Venezuela

Alcatel OT-800 (landscape QVGA screen with QWERTY keypad)

Central African Rep.
Niger
Belize

Alcatel OT-808 (landscape QVGA screen with QWERTY keypad)

Guinea

Alcatel OT-710 (portrait QVGA with resistive touchscreen)

Papua New Guinea

Alcatel seems to be beating the inevitable onslaught of the Android army in Africa at least, and is perhaps the first credible challenger to Nokia’s feature phone crown in the developing world. Its OT-710 is the only phone in the study with a touch screen that is the most popular phone in a country.

Most popular type of phone

There are three types of phones you have to support if you want to cover most of your bases in the developing world, and they’re all keypad based-non-touch devices.

3rd group: 128x160 keypad devices

The 128x160 phones are perhaps slowly on the way out, but the recent popularity of the C1 in Nigeria, and the fact that the number 2 phone in India is another 128x160 device in the Nokia 2690, means that they will be around for a while.

Models in top 10 of 15 countries studied: Nokia C1, Nokia 2690, Nokia C2 00, Nokia 2330c, Nokia 2220 slide, Samsung E250

Leading phone in: Nigeria (C1).

2nd group: QVGA portrait keypad devices

These are likely the largest by number, with 15 phones in this category, 5 countries where they are number 1, 4 at number 2, and 6 at number 3. The two most popular phones for the last two years have been in this category.

Models in top 10 of 15 countries studied: Nokia 2700C, Nokia 2730C, Nokia 5130 XpressMusic, Nokia Asha 303, Nokia X2 00, Nokia 6300, Nokia C2 01, Nokia N73, Nokia 3208c, Nokia 5000, Nokia 7020, Sony Ericsson K800, Samsung Galaxy Y S5360, and Samsung S3850.

Leading phone in: China (5130 XpressMusic), Bangladesh (2700c), Egypt (5130 XpressMusic), South Africa (5130 XpressMusic), and Vietnam (2700c),

1st group: landscape QVGA QWERTY devices

Portrait devices with a landscape oriented screen and a QWERTY keypad seem to be the new en vouge devices in a number of the countries studied. Perhaps not the most popular type of device yet, but they are becoming increasingly important, and are dominant in Latin America. The landscape screen gives slightly more width to play with when laying out pages. A very precious commodity at these screen sizes. The keyboards will also make data entry easier than the traditional number pads. These phones were number 1 in 3 countries, 3 at number 2, and 1 at number 3.

Models in top 10 of 15 countries studied: Nokia X2 01, Nokia C3, Nokia Asha 200, Nokia E63, Alcatel OT-808, Alcatel OT-800, Alcatel OT-802, Samsung Ch@t 335 (S3350), and the BlackBerry Curve 8520.

Leading phone in: India (X2 01), Indonesia (X2 01), Philippines (C3), Mexico (C3), and Brazil (C3)

Conclusions

The good news is there is only two different resolutions (plus one different orientation) to cover most of the bases in the developing countries studied. Plus another two resolutions if you want to cover all the bases including the more exotic devices. The bad news is that none of the most popular device types support touch, nor do they support WiFi (except the C3), so data is as much at a premium as pixels.

My advice would be to try to get hold of both a Nokia X2-01 (or C3 00, which has WiFi) and a 5130 XpressMusic, plus perhaps a Nokia C1. That will cover all three main bases. They’re more or less cheap as chips compared to the devices we usually target.

If you can’t get hold of a device, one trick is to download the Opera Mobile emulator and set profiles up for these screen sizes and pixel densities. It will give you a good idea of the layout of your site on these small displays, but is far from perfect, as these devices usually support Opera Mini rather than Opera Mobile. THe former is much less capible, but unfortunately doesn’t have a downloadable, resizable emulator on the site. If you have Java, you can try the online Opera Mini simulator, but the resolution is fixed and uses the touch UI by default.

If you are practicing responsive web design and already use media queries, you likely have the infrastructure in place to support these screen sizes. You might just need to add an extra breakpoint or two for smaller sizes. if your site is already keyboard accessible, then it is likely you won’t have too many issues with keypad navigation. The size of your assets could be a major concern, but the proxies used by Opera Mini, UC Web and the Nokia browser will go some ways to mitigate this.

The future

Phones that didn’t feature heavily here were Nokia’s new Asha line of feature phones. Only two Asha phones featured in the top 10: The Asha 303 (ninth in Mexico) and the Asha 200 featured (back in tenth in Nigeria). The latter of which had even worse specs than the other devices in its class. One reason for them not featuring is their relative newness. Another is that Nokia is pushing its own proxy browser with these new devices, so the users might stick with the default browser. It will be interesting to see if this browser eats away at Opera’s dominant position in the developing countries, or if users that buy these phones still use Opera.

The main exciting thing about these devices is that the three top of the line devices are full touch S40 devices, in the Asha 311, Asha 306, and Asha 305. If the pricing is right, these could potentially be the game changers that give the developing world the revolution in user experience on the web that touch has already brought to ourselves in the west.

They’ll not hold a candle to the iPhone, but they won’t have to. It is a totally different market and they‘ll be a fraction of the price. They have the potential to democratise touch for the rest of the world. It may take another generation however, before touch devices reach the mid-range of feature phones rather than the top end, before they really take off enmass.

The interesting billion dollar question is, will it be touch dropping down to feature phones such as the Nokia S40 devices, or Android devices dropping in price enough to be viable market leaders in the the developing world. That will be an interesting battle.

The other variable is if Nokia and Microsoft can get Windows Phone at a price point where they replace their fleet of feature phones. That could be a major win for their platform in a market Nokia knows all about. Whichever platform wins, it should be a win for web developers and users over the current situation of limited devices.

Stop press. I wrote the bulk of this post last night, and since then the iPhone 5 has been announced. I couldn’t help but notice that the iPod Nano’s screen resolution is 240x432; the same width and a fraction taller than many of the devices in this study. Its a shame that device doesn’t have WiFi and a web browser, as the clamour for developers to get their sites working on that display would have been a great help in improving the experiences of users of these phones.

Update: Opera has released data for Latin America covering August 2012. I’ve updated this post to reflect that. On the whole Latin America is similar but more advanced than Asia/Pacific and Africa. The most popular device is the C3 00 QVGA portrait device, which is similar in capabilities to the X2 01 but also includes WiFi. Latin America has less reliance on Nokia than Asia and Africa–with Alcatel particularly strong–but it is still the most popular brand with Opera Mini users.

We have started to see higher end WGVGA feature phones and lower end HVGA smart phones break the top ten in Latin America. I would expect this trend to proliferate in the text year and spread to the other regions. It will be interesting to see if this happens with Samsung and LG (or Alcatel) as seen in Latin America so far, or if the Nokia Asha Touch line becomes more popular instead. It will also be interesting to see if this happens with smart phone OS like Android or Windows Phone, or with souped up feature phones like S40, Bada, or other platforms. Indeed, Samsung’s higher end feature phone to make this list was its own un-named feature phone, rather than its more open, closer to a smart phone Bada OS.

The data I used to compile this post will be included in the following Google spreadsheet.

Montage and Ninja are here

Tue, 17 Jul 2012 01:56:00 -0700

After leaving Opera last year, I hopped over the Atlantic to join Motorola Mobility in the Bay Area, to work on a top secret project. Many people asked Why Motorola? and What are you working on at a mobile company?. Well, finally, we revealed our project to the world last week.

Motorola had put together a team of top engineers from companies such as Apple, Adobe, Nokia, Opera, and others. The team is also scattered with people you might recognise for their contributions to the Web community, such as Simurai, Brandon Jones, Kris Kowal, Román Cortés, Jon Reid, and more. If you’re a member of the Flex, Flash or WebObjects communities, you’ll also recognise a number of familiar faces.

After a lot of hard work and much drinking of coffee, last week we released a MVC JavaScript framework called Montage, and a visual authoring tool called Ninja. Both have been released for free under a BSD licence on Github. we also released a number of smaller tools such as Screening, which is an automated testing tool (supporting WebDriver) for Montage apps. As a strong believer in eating our own dog food, both Ninja and Screening were built using Montage.

Montage framework

The Montage framework is designed with modern web technologies, such as ES5, HTML5, and CSS3. As such we made the trade-off of jettisoning support for legacy browsers that do not support features such as object.create. The advantage is that we can remove the cruft and use a modern architecture. We will however support any browser that does support the standards we rely on. Montage is still work in progress, and as such browser support is improving as the framework matures.

As well as the modern technologies built into the browser, we use various parts of CommonJS including Promises, Modules, and package.json. We also take advantage of Node.JS.

The main aim of Montage is to help developers be able to develop native quality applications using web technologies, as quickly and easily as possible. As such we support components using HTML5 templates, Two way data binding (to both objects and components) , serialization, extended event handling, an optimised component draw cycle (for efficiently repainting when updating the DOM), keyboard shortcut handling, gestures and composers, data converters, and much more.

I personally love how montage components use regular HTML, CSS, and JavaScript, so a designer can build the UI for an app or component using the technologies they likely already know, which the developer can then hook up to the controller and model layers. We use each technology for what it was designed for, rather than shoehorning everything into JavaScript. I also really love data bindings, as I can hook up a component to update the data in the model (or vice versa) or another component, without having to write any JavaScript in many cases. It just requires some configuration in the JSON serialisation file. Of course you can also use the JS API if you should so wish.

While Montage is far from done, we have had the advantage of building a number of real world apps using Montage, such as Ninja, so we’ve been able to see what works and what needed improved or optimised. This has allowed us to rapidly improve the framework as we go. We’re really looking forward to having designers and developers in the community use Montage, and collecting your feedback. As we’re open source, we’d also love to see your bug reports, and maybe even a pull request or two. If you build anything using Montage, be sure to let us know!

Ninja authoring

The Ninja authoring tool is currently in alpha. It is packaged as a Chrome extension. As I mentioned previously, it was written using the Montage framework.

What really excites me about Ninja is that as a member of the SVG community, we were always hoping that a tool such as Flash would come out for SVG. There were plenty of great apps for creating static SVG, but not much for dynamic SVG. Now with Ninja we have a tool that is potentially as powerful as tools like Flash but for developing apps and pages using web standards rather than swf. If we do this right, we could have a revolutionary tool on our hands. And the team building Ninja is second to none in their experience building such tools.

Ninja has a number of visual tools such as a pen, brush, canvas and WebGL drawing, 3D rotate and translate, colour panel, materials panel, animation, and so on, as well a code view, visual data binding, component panels, and a lot more.

For a good overview of what Ninja is capable of, check out these Ninja videos, or see the release notes.

I expect that Ninja will be a great tool for designers moving to HTML from the Flash world, as well as those that want to be able to visually design their app or site, while still working in the browser and having access to the source. I look forward to seeing how you put the tool to use.

How you can get involved

Montage and Ninja are new and still under active development. We’d love to get your feedback on what’s hot and what’s not, and what can be improved. If you develop anything with their project then be sure to let us know. We have a forum on the Tetsubo site, and you can find the Montage team on IRC at #montage on freenode.net. Feel free to file bugs on GitHub.

If you’d like to meet up in person, we’re having our first Montage meetup in the Bay Area on 2nd August, organised by Tom Ortega.

Creating an angled split feature area with CSS transforms

Tue, 03 Jul 2012 00:02:00 -0700

For an upcoming project I’m working on, I needed to have a feature area that showcased two things equally. The easy option would have been to show them in boxes, either side by side or one on top of the other. I decided instead to try my hand at a comic book look, where the cells are split diagonally. I also wanted to have a hover effect, so that each cell grew bigger or smaller depending on which cell was hovered.

CSS has traditionally not been good at things that are not square (or rounded with border-radius), but it is possible with minimal extra markup. I was speaking to Simurai and he suggested using skew to skew the box, then skew the contents back again. That idea worked and formed the basis of the technique, along with a bunch of other fiddling.

The final result

The final result looks like so:

And when hovering the first box this happens:

Conversely, hovering on the second box makes the first one smaller.

Try out the split feature demo to see it in action.

How it works

The main tricks are to place two divs (or elements of your choice) on top of each other. The first div requires a wrapper element, but the second does not. The wrapper is skewed at the angle you desire, and the child div is skewed back so that the content isn’t slanted. The child is then set to a width smaller that the first div and the overflow is hidden.

The HTML

<div class="box sunrise"><!-- contents --></div>
<div class="slider">
    <div class="box sunset"><!-- contents --></div>
</div>

The CSS

The two boxes are sized the same and decorated:

.box { 
    width: 880px;
    height: 330px;
    border-radius: .5em;
}

The box with the sunrise image is set to use position: absolute to remove it from the flow, so that the sunset box is placed on top of it. It is also styled with a box-shadow and a background image.

.sunrise {
    position: absolute;  /* remove from flow so sunset is placed on top */

    background:  url(sunrise.jpg) no-repeat;
    box-shadow: 0 0 10px rgba(0, 0, 0, .7);
}

The wrapper element around the sunset box is skewed by the required amount, and a transition is set up. An initial width is set and the overflow is hidden, so that only half the contents of the sunset div is shown.

.slider {
    /* set initial width */
    width: 520px;
           
    /* hide the content that overflows (to allow second box to show through) */
   overflow: hidden;
   display: inline-block;
           
    /* skew container so that it has angled edge, and set up transition */
   transform: skewX(-20deg);
   transition: width 1.2s ease-in-out;
}

The sunset div is skewed back by the negation of the angle the parent was skewed, so the contents are straight rather than skewed at an angle. A background image is also set like the sunrise box. As the parent has a skew applied, we need to set a left margin to move the contents and the background image away from the left edge. Otherwise it will be clipped out by the hidden overflow.

.sunset {
    /* skew back by negative of parent’s skew so contents is upright */
    transform: skewX(20deg);
    margin-left: 76px; /* give margin to push content away from left slanted edge */
   background: url(sunset-elephant.jpg) no-repeat;
   pointer-events: auto;    /* allow pointer events for the box */
}

Due to applying a left margin above, there will be a space on the left side. This can be removed by setting a negative left margin of the same value on the wrapper. We can also set pointer-events to none so that the hidden part doesn’t cause the hover to fire. We also need to remember to set the pointer-events back on the sunset div, so the visible part can still be hovered (see above).

.slider {
    …
    /* give negative margin to remove gap caused by left hand skew */
    margin-left: -76px;
           
   /* hide pointer events for unseen content */
   pointer-events: none;
}

Now all this is set up, the only thing left is to apply the hover. As the transitions have already been set up, we just need to change the width when hovering. As the second box (sunrise) is actually first in source order, we can use am adjacent sibling combinator to make the sunset div smaller when the sunrise div is hovered.

/* make first box bigger on hover, and smaller when hover second box */
.slider:hover {
    width: 760px;
}
        
.sunrise:hover + .slider { 
    width: 250px;
}

That is more or less all there is to it. I’m sure there are probably ways with less markup or CSS, but this way works for what I need it for. The main drawbacks is the need for a wrapper div (can probably get away without it, depending on what content you have in the boxes) and the edge is not anti-aliased in the browsers I‘ve tested (Opera is particularly funky, but the strips make a unique effect).

If you didn’t try it out before, check out the demo. Alternatively, try out the demo and view the source on Dabblet.

box-sizing: border-box; the results are in

Mon, 02 Jul 2012 00:29:00 -0700

A week has passed since I created a poll on the use of box-sizing: border-box. In that time 256 people filled out the survey. The results so far are as follows:

Use `box-sizing: border-box`?	Yes	No
Currently personal project	71%	29%
Future personal project	88%	12%
Future team project	85%	15%
Future public project	60%	40%

In the table above, a team project is one which the developers are known to the person making the decision, such as developers in the same company or a group of friends with which you can work closely. A public project is one which developers could be anyone that you may not be able to personally communicate the usage, such as an open source project or a public API.

Although not a conclusive sample size, the signs are that developers are comfortable with and use (or are planning to use) the border box model, and are happy to use it in team projects. It surprises me a little how many developers actually already use it. The number of developers in favour of using the border box model in pubic project with potentially unknown developers drops, but is still 20% higher than those that wouldn’t. If these results signify anything, don’t be surprised if you see more projects spring up using the box model formally known as broken.

Although developers are largely in favour of using box-sizing: border-box, a sizeable number have mentioned that they’d only use it where needed, rather than blanket applying it across the whole document with the universal selector. A few mentioned it can break jQuery plug-ins, so that may limit adoption on jQuery-based sites. While a few others mentioned they would use it if its use was documented, such as with KSS comments (always a good practice when working with teams, or even solo projects if you’re going to have to maintain your code).

I will leave the poll open for now, in the hope of collecting a larger sample. As the results have largely stayed 60–40 in favour of the old IE box model throughout the life of the poll, I don’t expect the result to change significantly however.

Sizing Boxes (Back to the Future)

Sun, 24 Jun 2012 21:16:00 -0700

The way we are building web sites is fundamentally changing. The XHTML (Strict if we took pride in our work) has given way to the more loose HTML5. Image slicing and dicing, and wrapper divs are starting to be replaced with lean (perhaps semantic if we’re lucky) HTML and CSS3 effects such as border-radius, box-shadow and gradients. Elastic layouts have metamorphosed into responsive design with Media Queries. JavaScript–no longer considered a toy–has earned its place at the table, forming a triumvirate with HTML and CSS. We may be at the cusp of a real tool for layout with flexbox. Perhaps even the venerable em unit will fall out of favour, replaced with the more predictable rem, and flexible vh and vw units.

As we stand in the foothills of the third major era of the open web (the age of tables and spacer gifs now all but a distant memory), our tools and processes are even growing up to start to resemble those of traditional programmers, with build scripts, preprocessors, linters (squint and it could resemble a compiler), automated testing, and version control.

But, it is something a bit more humble that I want to talk about today, which may also change how we write sites in its own little way. That is the CSS box-sizing property.

Those of you who were around in the bad old days with remember the broken box model that IE used, rather than the standard W3C model. In this model the border and padding were counted as part of the width and height of the box. While in the W3C model the padding and border were added to the width and height to get the final dimensions of the box. In the IE model the width represented the total width of the box, while in the W3C model it represented the width of the content box (that is the box that contains the content of the element). To get IE to play nice, we had to use Tantek’s box model hack.

The CSS box-sizing property has existed for quite some time, and gives us a way to switch between the standard model (with box-sizing: content-box) and the old IE model (box-sizing: border-box). There has been a spark of interest recently in using this oft forgotten property, caused by Paul Irish’s * { box-sizing: border-box } FTW.

Time to switch to border-box?

If you want to get right to the action then please spend a few moments to take my poll on box-sizing, otherwise read on.

The standard will never switch to using border-box by default, as too much content would break, but is it time to switch to using this for all elements in our own projects using the universal selector, as Paul advocates? Its something I’ve been giving a bit of thought to recently.

If it was just for my own personal projects, or on projects with a small team where I know the developers and can communicate it clearly, I think I would plump for it. But for use in a style guide meant to be used by many developers, and open source project, or demos that might be seen by many people I’ve never even interacted with, I’m still on the fence.

The pros and cons

There are certainly a number of well known developers in the pro camp. Paul Irish is certainly a fan. He sums up the frustration with the current model: Ugh. If I say the width is 200px, gosh darn it, it’s gonna be a 200px wide box even if I have 20px of padding. Joe Lambert says I’m a big fan of this technique and have been using it in a number of mobile web apps (and increasingly) website projects. Jeremy Keith simply calls it the bee’s knees. While Stephanie Rewis wonders if we should have lobbied the W3C to change their box model instead. I hear this frustration from devs all the time..

Thierry Koblentz however has a word of caution:

Regarding what we used to call the “broken box model”, I think the issue is that you do not own the content box and any change in border or padding impacts that content area. I understand that it can be easier for people to style boxes that way, but it’s not a magic wand, you end up dealing with different issues.

Boris Zbarsky of Mozilla claims it [the spec] doesn’t define how it should work in enough detail that it can be implemented, leaving that to CSS3 Box, as far as I can tell…, while David Baron (also of Mozilla, and the CSS WG) states box-sizing is a poorly-designed feature that’s frankly intended only for backwards-compatibility with quirks mode.

The pros and cons as I see it are the following:

Pros

The size of an element is far easier to calculate. It is the size I tell it to be, no matter what I set the border or margin to be.
We can use percentage based widths in a fluid design while still using ems or px for padding. With the traditional model we would need calc to solve this problem. See Chris Coyier’s excellent box-sizing post for an explanation of the issue.
If you have grey hair from all those days developing for IE, you already know how to use it.

Cons

If you need to support IE7 and below it is a no go, unless you want to use a polyfill, or put IE into quirks mode (not a good idea). Firefox also still needs a prefix, and you’ll need the -webkit- prefix if you care about relatively modern versions of WebKit. See browser support.
Firefox’s behaviour is still buggy, especially around interactions with min- and max-width/height.
You lose control over the dimensions of the content box, which can lead to unpredictabilities you didn’t have to deal with before. For example, what happens if the padding is the same size or greater than the width or hight (cue frantic visits to the spec to check for the correct answer)?
Perhaps the biggest issue for me is author expectation. If I use * { box-sizing: border-box; } on code that has to be used and extended by other developers, they will more often than not expect the W3C box model, and their own styles will not behave as desired. Furthermore, if they are a new developer, they might not be familiar with the IE box model at all, requiring further reading to get started even after figuring out the cause.

What do you think?

With all that being said, and plenty of other reasons in either camp that I’m sure you can come up with, what are your thoughts? If you were working on a project where other developers would need to work with your code, would you use box-sizing: border-box? I’ve created a poll so that you can let me know, and when the results are in, I’ll report back with what the crowd voted.

Take the box-sizing poll now!

Responsive viewport units (vw, vh, and vmin)

Tue, 17 Apr 2012 12:36:00 -0700

With all this new fangled talk of responsive web design, its about time that we had a poster child CSS unit to go with it. So move over em, CSS3 Values and Units introduces a bunch of new viewport units that are getting ready for their time in the limelight.

Motorola recently implemented support for these viewport length units and they’ve now found their way into Chrome Canary, so we can now start to experiment with them. They are also supported in IE9, although the vm unit has been updated to vmin since then.

Introducing vh, vw, and vmin

The vh unit stands for viewport height, vw for ~~Volkswagen~~ viewport width, and vmin represents whichever of vh or vw is the shortest length.

The values used can be somewhat confusing if you’ve not used these units before, as 1vh represents 1% of the current viewport (the content area of the browser window) height, rather than 100% as you may expect. Therefore if you want an element to be the full height of your viewport you should set it to 100vh. As you would expect, vw works exactly the same way as vh units.

If you have a widescreen monitor and your browser window is set to full screen, the width would be wider than the height. In this case the vmin unit would be the same as the vh unit.

The viewport units are dynamic rather than static, so if you resize the browser window, the computed value of the units will also change. If for example your browser window is 1000px wide, and element with a width of 10vw would be 100px wide. If you shrink the browser window to only 100px wide, the width of the element would resize with it to 10px wide.

A responsive example

One of the big issues with using multi-column layout is that you need to endlessly scroll up and down the page to read each column if the height is taller than the viewport. The viewport units mitigate this somewhat, as you can set the hight of the element with multi-column applied to it to be smaller than the viewport height (but remember to take the margins into account). You still have the issue of horizontal scrolling if you restrict the height, but this may be an ok solution if you’re designing for something like a tablet device.

I’ve created a quick example that uses this technique. Go and check out my multi-column responsive viewport example in Chrome Canary to see it in action. It should look something like the following screenshot:

As the scrollbar is hidden by default in Mac OS X Lion, its a bit difficult in this example to see that the text is scrollable horizontally.

Setting the width and height to respond to the viewport size is trivial with the vh and vw units:

article > section {
    column-width: 22rem;
    column-gap: 2.6rem;
                
    height: 80vh;
    width: 80vw;
        
    overflow: scroll;
}

This sets the height to be 80% of the viewport height, and the width to be 80% of the viewport width. The width of each column is set to be ideally 22rem (220px in this case) wide, but the browser can adjust this as needed. Finally overflow is set to scroll so that additional columns are hidden and can be scrolled into view, rather than overflowing to the right, and potentially overlapping any element that we place there.

I also set some margins on the body element to give some breathing space. This also scale with the viewport size, to be 2% of the viewport height top and bottom, and 10% of the width left and right:

body {
    margin: 2vh 10vw;
}

With this, you have a truly responsive design (at least with a simple example such as this), without even touching media queries. Imagine what untold powers they will bestow on you when you combine them? Add Flexbox to the mix, and we’ll really be cooking on gas.

What’s new in CSS3 Values and Units?

Tue, 25 Oct 2011 19:09:00 -0700

In CSS3 the values and units we can use in CSS properties are defined in the appropriately named CSS Values and Units specification, with the exception those relating to colour and images, and the pre-defined keywords specific to individual properties.

This spec gives us one new CSS wide keyword to play with (the initial keyword), five new relative units for lengths, five new functional notations, and various new types and units to support new CSS3 modules such as Grid and Flexbox layout, Transitions, and Transforms.

CSS-wide initial keyword

CSS2.1 added the first CSS-wide keyword to every property with the inherit keyword. CSS3 adds to this with the initial keyword. When you set a property’s value to initial it will set the value to what is defined as the initial value in the CSS specification for that property. Note that this is sometimes, but not always the same as the default value set in the user-agent style sheet. For example the initial value for various margin and padding properties is 0, but the default value given by the user-agent depends on the element to which it applies.

The initial keyword can be useful if an element is inheriting unwanted styles and the original styling is desired. It is probably not something you will need to use often, but it is a useful tool to have on occasions. This is currently only supported by WebKit and Firefox (with moz prefix: -moz-intitial).

Take a look at the initial keyword demo I prepared to see this in action. This currently requires a Gecko or WebKit browser at the time of writing.

Font relative length units

The rem unit

The rem unit is perhaps my favourite new part of CSS3 Values. It stands for root em, and if you already understand how ems work (I assume that is most of you?) then you’ll be right at home. They are only subtly different, but it makes them easier to work with.

The root part of the name refers to the root element, or the html element in HTML and the initial svg element in SVG. With regular ems the size of 1em is set to value of the font-size property of the current element, or the size of the parent element’s text size when used with the font-size property itself. The font size varies from element to element, so the size of an em is not consistent across the document. This requires a lot of calculation when you are tying to line elements up or are tying to compose text to a vertical rhythm.

The rem value however stays consistent across the document, as 1rem is always the same size as the font-size of the html element (or root of which ever language you are using). If you want a margin to be a certain length, you just need to calculate it once for any element. If you want to make the maths as easy as possible you can set the html element to have a font-size of 10px (or another multiple of 10), then set the desired body copy size on the body element, such as font-size: 1.2rem for 12px. Now you get the scalability benefits of ems along with the ease of use and predictability of pxs.

The only downside is the browser support. Its supported in IE9, Firefox 3.6+, Safari 5+ and Chrome. It is also coming to Opera 12, which should hopefully be released soon. As Opera users generally upgrade fast, and Firefox <3.6 is only around 1% market share, your only real issue in the near feature will be those users stuck on IE6–8. Using a fallback is easy if you set the root font size to 10px, as you can set every size you set in rems to the equivalent px size. For example 2rem is 20px, 1.7rem is 17px, and so on. It adds a lot more page weight however.

I’ve prepared a rem unit demo which shows how you can follow a vertical rhythm using this unit.

The ch unit

The ch unit is equal to the width of the 0 (zero) glyph in the font used by the current element. This is mostly useful when using monospace fonts, where all glyphs are the same width. For example, if you have a pre element where you want it to wrap after a 55 of characters, you can use width: 55ch; unit.

This unit is currently only supported by Internet Explorer 9 and Firefox.

Viewport relative lengths

There are three viewport relative lengths: vh, vw, and vm. These are relative to the size of the initial containing block, or in other words the viewport. If you resize the viewport, such as changing the size of the browser window, then the size of elements specified in these units will change.

The vw unit

This is relative to the width of the viewport. One vw unit is 100^th of the width of the viewport. If the viewport is 1000 pixels wide then 10vw would map to 100px.

The vh unit

The vh unit works the same way as vw, but is relative to the height of the viewport instead.

The vm unit

The vm unit maps to whichever of the viewport width or hight is the smallest. There is some talk of dropping this as the same can be achieved using the min() functional notation.

These new units can be very useful if you don’t want something to end up larger than the viewport. One use case I’ve had for these is while using multi-column layout. You often don’t want text using multi-column to be taller than the screen size as the user will have to scroll up and down for each column. With vh you could use for example height: 95vh which would make it 95% of the height of the viewport, no matter how tall the viewport is. You could also imagine them being useful for things like slide shows, video players, and mobile.

You might think these units sound great, but unfortunately they currently only work in IE9 and above, so it will be some time before we can used them.

The rest

There are new units for angles (deg, grad, rad, and turn units) and times (s, ms units. These are used in CSS3 2D/3D Transforms, and CSS Transitions respectively. There are also new units for frequencies (Hz, kHz units). These are used in the CSS3 Speech module.

There are new layout specific units: fractions using the fr unit, and grid units using the gr unit.

It doesn’t make too much sense covering these, without coving the full spec for which they are used, so I will leave them for a later date. There are also five functional notations, which require in-depth explanation, so they deserve their own post. I will cover these in the near future. These are mathematical expressions (calc(), min() and max()), cycling values (cycle()), and attribute references (attr()).

I hope you find some useful ways to use these new values and units that we now have to play with.

What’s new in Android 4.0 for Web Developers?

Thu, 20 Oct 2011 17:59:00 -0700

Google recently announced the Ice Cream Sandwich version of Android, along with a new version of the WebKit-based browser. Lets have a look at what is in there that’s of interest for web developers.

User agent switching, or a knock to the mobile specific site?

When I was working with web site compatibility at Opera, one of the biggest complaints we got time and time again was when a popular site switched to giving the mobile version of the site rather than the desktop version. Despite perceived wisdom from developers that users are in the mobile context and want mobile optimised sites, the reality is users screamed blue murder. Especially when the site gave no option to switch back. The reasons were usually two fold. One: many users knew their way around the site and where they had to go (even when they only accessed the web on a mobile device) and two: often they wanted to use a feature that the developers had decided the mobile version didn’t need. Many of these users couldn’t just wait until they were on a desktop PC to use those features as their only way to access the web was through a mobile (think rural China, India or the Philippines for example).

One perfect example was GMail. If you tried to sign up for an account (no one does that on mobile right?) it would say something like sign up for an account on a PC. These users were completely locked out of the site with no way to get an account.

I suspect Google has been getting the same complaints Opera was getting, especially as Android is starting to become popular in developing countries. For the Android 4 browser, they have added a way to switch to the desktop site on a per tab basis:

To get the most out of web content, users can now request full desktop versions of web sites, rather than their mobile versions. Users can set their preference for web sites separately for each browser tab.

If I’d hazard a guess about how they do this, then it would be that they switch the user agent string to that of a desktop browser such as Chrome. That way the site developer will think it is a desktop browser and will give the desktop site. If they cloak well enough, there will be no way for the developer to force users into using the mobile site. I think this is a good thing, as it will open up choice to the user, and force developers to think about making their regular sites as friendly as possible. This is exactly what the mobile first brigade have been preaching. I suspect things like Media Queries will still work as expected in desktop mode. It will certainly put a dent in the firearms of those that want to browser sniff to give (or try to give. It always goes wrong. I’ve lost count of the amount of issues I had to deal with related to sever side browser sniffing for mobile browsers going wrong, across almost every major site) a tailored experience to mobile devices.

So to recap, to guarantee a good experience on Android, you will need to make sure both your mobile site and your desktop site is mobile friendly. Or use one site and adapt via things like media queries.

Roboto, a new high DPI optimised font

Times change fast on mobile. Back when Android was first released, Google worked with Ascender Corp to produce the Droid family of fonts. One of the main design goals was to produce a font that worked well at small sizes on the restricted resolutions of mobile devices at the time. Thus, the letterforms were condensed to fit as maximise how much text could fit on screen.

Fast forward to today and mobiles are ever increasing in both DPI and screen real estate (Galaxy Nexus has a 4.65 inch display at 330ppi!), and mobile platforms have expanded to tablets. With these new circumstances, Google has developed a new font in house by Christian Robertson called Roboto.

The font has been created from scratch for high DPI screens. It is a geometric font, somewhat reminiscent of Helvetica. As it is the default font, this is the font your site will be using unless you specify otherwise. You should be able to use it where you use arial or helvetica today without any problems. As it is included in an open source product, it will assumably be available to download freely, just like Google allowed with the Droid family. Be careful if you were planning to use it on desktop platforms however. In a comment in defence of the font, Robertson stated:

since Android doesn’t use much of the nastiness that is TrueType hinting, Roboto is not hinted to support older Windows browsers, for example.

He mentions a few of the design choices in that post, and it is will worth a read. It remains to be seen whether the font gets accepted in the design community, and we will have to see it in its native environment, but I personally feel the UI looks much more fresher with it. I’m unsure of the Droid family, or any other fonts are also available for developers. I expect there should be at least one serif font, but you never know.

WebKit enhancements

One of the key things for web developers is the capabilities of the web browser. The Android browser has always lagged its desktop cousin, and was stating to get a bit of a bad reputation with web developers. Although they haven’t switched to Chrome (yet) in Android, we do get a new version of WebKit. The official docs report that this is WebKit 534.30. By comparing UA strings, it looks like this is the same version used by Chrome 12. However, just because the desktop version supports a feature, it doesn’t mean the code path was enabled on the Android branch of WebKit, or any porting work was done to expose a feature to the browsers.

Performance improvements

The Android team has upgraded to a newer version of V8 with crankshaft support. According to the Unofficial Google system blog in benchmarks run on a Nexus S device, the Android 4.0 browser showed an improvement of nearly 220% over the Android 2.3 browser in the V8 Benchmark Suite and more than 35% in the SunSpider 9.1 JavaScript Benchmark. That’s not too shabby.

New on phones

While tablets have been running Honeycomb, phones have been stuck on Gingerbread. If you’re developing towards phones, then all the features added to Honeycomb will be available to you for the first time. Highlights include:

SVG (Finally!)
CSS3 3D Transforms
Device Orientation Events (access to compass/direction)
File API
HTML5 async and defer attributes for scripts
XHR2
classList

New since Honeycomb

There are not a huge number of toys to play with, but there are a few including:

HTML5 Details and summary elements
Blob URIs from File API
TypedArrays (Originally from WebGL)
Navigation Timing (performance spec)
Updated CSS3 gradients to specced version

Thanks to caniuse.com for the comparison data.

What’s missing?

So that WebKit version that corresponds to Chrome 12? How does it really stack up? Well a pretty huge difference actually. Some of the key things still still missing include:

WebGL
WebWorkers
WebSockets
Server Sent Events
IndexedDB
Drag and Drop
History API
HTML5 Forms (would be very useful on mobile)
Progress and Meter
File Writer
SVG Filters
Web Notifications (these are almost like they were designed for mobile)
WOFF (although does anyone use WOFF now TTF is well supported?)

This is not to mention the features that have been added since Chrome 12. Our new Chrome overlords can’t come soon enough.

So where are we at?

We have some thinking to do regarding desktop sites on mobile being within easier reach, no matter if we like it or not. We have a new font similar to Helvetica as a new font, and a faster more standards web browser to play with. On the whole it is a competent update, but hardly earth shattering for web developers. The Safari browser on iOS is still ahead in a number of key areas in terms of standards support. With Opera Mobile 11.50 reaching 285 on the HTML5test (not featured on the site yet, nor is Android 4), I expect that still has the best standards support on Android currently.