December 1, 2011

First, Understand Your Screen

I unashamedly maintain that there is so much more to being successful on the mobile web than dealing with screen size. But I do accept that dealing with screen size is at least a first step.

Thank goodness then, that the matter of screen size is so simple and well understood.


As web developers, we will often need to know the screen size of the device we are displaying content on. Perhaps on the server, perhaps on the client, perhaps to be used as a clause in a media query.

But how best to measure it? And what are we measuring anyway? On the client-side, for instance, a variety of ways exist to determine screen and page size: things like screen.width, window.outerWidth, document.body.clientWidth, and so on. But these properties are infamously unspecified by any standards: so what do they all mean – and how reliable are they on mobile browsers?

Required reading at this point is PPK’s viewport article. With an article of tables from him that long, you know something’s up.

But last week I pushed out an update to which allows client-side screen size parameters. Which parameters should mobile developers use? And when?

So for this blog post, I looked at a range of these metrics, and recorded their values for a variety of mobile browsers and page conditions. I’ve been working in mobile for far too long, but still, the amount of diversity in the results shocked me. Read on for the gory details, or skip to the end for the TLDR. I think there are some interesting findings.


The tests comprised a very simple web page, containing several paragraphs of meaningless Latin, and a JavaScript function that runs to take screen measurements within the browser. The following properties are sought:

  • screen.width
  • screen.availWidth
  • window.outerWidth
  • window.innerWidth
  • document.body.clientWidth
  • document.body.offsetWidth
  • @media device-width
  • @media width
  • screen.height
  • screen.availHeight
  • window.outerHeight
  • window.innerHeight
  • document.body.clientHeight
  • document.body.offsetHeight
  • @media device-height
  • @media height
  • window.orientation
  • @media orientation

The CSS media query properties (device-width, orientation, etc) are taken programmatically by evaluating expressions with the matchMedia() function, supported in iOS v5.0 and Android v4.0.

I’m sorry to say that the tests were run on emulators rather than real devices, but covered iPhone (iOS v5.0 and iOS v4.3), Android v2.3, Android v4.0, and Opera Mobile v11.0. The Android and Opera simulators were set to use HVGA (320×480) so as to have conditions as consistent with the iPhone as possible. (Even though the actual physical screen of a retina iPhone is 640×960, this HVGA resolution is the one reported to the software APIs).

The tests were run with two different HTML document types – HTML5 and XHTML-MP – and also a third time with no doctype specified. The tests were also run both with and without a viewport meta tag to control the default width (constrained to ‘device-width‘) and scaling. Additionally each device was tested with landscape as well as portrait orientation – making a total of 12 test combinations for each browser.

For the iPhone and Android browsers, PhoneGap-wrapped versions of the test pages were also run (without the viewport meta tag), and finally, for iOS v5.0, the iPhone’s ‘Add to Homescreen’ technique was used (with the apple-mobile-web-app-capable meta tag) to launch portrait versions of the tests in a full-screen mode.

As if all those combinations were not enough, the properties were accessed four times during the lifecycle of the page: a) inline before the <body> tag, b) after the </body> tag, c) on the document’s load event, and d) one more time, 250ms later. I had a hunch that the values – at least those relating to page height – might change throughout this lifecycle.


The full set of results is available here. The various combinations of conditions are across the top, and operating systems (and measurements made) are down the left. Each cell shows the value returned from the relevant API call, and ‘-‘ is used where the call failed or returned an undefined value.

Where the value changed during the lifecycle of the page, slashes delimit the change, and a letter is used to indicate at which of the four measuring points the value changed. So for example, ‘208/c:1962‘ means that a value was 208 before the <body> and after the </body>, but then it changed to 1962 for ‘c’, the document’s load event, and remained so 250ms later.

There’s a lot to digest in there, although you may at least have noticed – as I have – that homogeneity is scarce. You may notice some particularly strange results, particularly on Android, but also on iOS and Opera. Let’s analyze the data by slicing the findings by property measured, dicing by operating system, and trying to digest the whole sorry lot.


screen.width & .height

These two properties are generally understood to return the physical dimensions of the screen upon which a browser is running. On desktop browsers, they will return you 1024×768, 1440×900, 1600×1200 and so on, regardless of how the actual browser window is sized. On mobile devices, one would expect the same behavior, and get full physical screen sizes.

Well, close. But no cigar.

Opera Mobile and Android v4.0 (as well as v2.3 in a PhoneGap app) behave most intuitively in this regard, and will indeed report 320×480 or 480×320 for portrait and landscape respectively.

iOS also consistently reports the physical dimensions of the screen (320×480), but notably fails to flip them for a change or orientation. So be aware that in landscape mode, your browser’s width will actually, apparently, be reported to be larger than the screen’s.

Android v2.3, in a regular browser scenario, however, displays even more curious behavior. Its screen.width always starts off as 800 – which is clearly some sort of virtual viewport, rather than the physical screen. But when the document has an XHTML-MP doctype, or a constrained viewport (for any doctype), the value will switch, by the time of the document load event, to be the 320 or 480 you might expect.

Now this might be tolerable if you remember to wait for documents to fully load before accessing this property, but even that caution is blown to the wind by Android v2.3′s screen.height behavior.

With a non-constrained viewport, a portrait orientation, and with no doctype, screen.height was reported during this test as 1003. With an HTML5 doctype, it also switched to 1003, but only after dallying at 498 until at some point after the document load event. With an XHTML-MP doctype, it also started out at 498, but then dropped to about 40% of that value (199) by the time of the document load. With a constrained viewport, behavior was stable as a function of doctype, but also demonstrated the 60% drop at document load: from 1003 down to 401.

Landscape-wise, the same sort of issues occur: with no doctype, screen.height is a reliable 402; and with an HTML5 doctype, the same value is also (eventually) returned. The XHTML-MP doctype, or a constrained viewport, will cause the eventual value to be 241, but by way of various intriguing values. Our constrained, HTML5 document, for example, reported 372 before and after the <body/>, 223 on load, and 241 at some point afterwards.

Yes, these actual values are probably dependent upon the length of my particular test page itself, but remember that these are supposed to be the physical screen dimensions, folks!

Some semblance of normality returns to Android v2.3 in the PhoneGap environment. The values of 455 and 295 are hardly accurate measures of physical screen size, either (since bizarrely they seem to take the 25 pixel status bar into account!), but at least they’re close, and hooray: take solace that the value does not change during the page lifecycle.

screen.availWidth & .availHeight

In the desktop world, the available width and height returned by these two properties still relate to the whole screen, rather than the browser’s window, but they take operating system chrome into account. The menu bar in OSX means that screen.availHeight is at least 26 pixels less than screen.height, for example – although the width values will probably be the same (unless you have a non-minimizing dock on the side of the screen).

In mobile, one might expect the available values to take into account any OS status bar height. Let’s see, shall we?

I need to caveat the Opera results here, since the simulator runs in a dedicated window without any ‘real device’ chrome. But that should have implied that its available dimensions are the same as the screen’s – and this was not what was seen. In fact, the availHeight is reduced to 369 from a height of 480, not by any OS chrome, but by the browser’s own rather fat chrome. This is not what is expected – even if, on a real device, it emerges that the OS chrome is deducted too.

And having labored over Android v2.3, above, there’s not much more to say here about that operating system either. Without exception it depressingly reports exactly the same values for availWidth and availHeight as it did for width and height – although at least that means that the PhoneGap values are now correct! Android v4.0′s browser also reports the same available values as it did for total width and height, but fortunately they were slightly more sensible to begin with. But bizarrely the PhoneGap app doesn’t take the status bar height off as it does for v2.3.

And then there’s iOS: it does successfully deduct 20 pixels for the operating system’s chrome. But remember that orientation is ignored! So although a portrait availHeight is sensibly 460 (having dropped from 480), it is anti-intuitively the width in a landscape orientation that is reduced (from 320 to 300) by a bar at the top of the screen!

Quirks on all fronts. Sigh.

window.outerWidth & .innerWidth

In contrast to the screen properties, the window properties are understood to refer to the browser window itself. For desktop browsers, (at least, when they’re not running in full-screen mode), the outer dimensions will normally be smaller than those for the screen. The inner dimensions then further deduct browser chrome: window borders, toolbars, status bars, and so on, and so they are normally smaller still.

In mobile, we might expect the outer values to more or less match those for the available screen – since apps run full size. And indeed, with window.outerWidth, we have a good news story.

iOS v5.0 uses window.outerWidth to redeem itself over the lack of the orientation’s effect on screen. It is 320 for portrait viewing, and 480 for landscape viewing. Bam.

Opera does the same. Bam. Astonishingly, Android v2.3 also nails it. Bam.

In fact, the only small blot that stops window.outerWidth being the model student is Android v4.0 in landscape: the property often has the portrait value of 320 before the <body> tag is reached. However, this is arguably an edge case, and a very minor misdemeanor.

After that rousing news, it’s back to earth with a small bump for window.innerWidth. If your desktop experience had convinced you that innerWidth must be the same or smaller than outerWidth, you’ve now got the TARDIS-like experience of mobile viewports to enjoy.

Without dropping into classic viewport theory here, it’s sufficient to say that WebKit mobile browsers seem to use the boundary between the window’s ‘inner’ and ‘outer’ width and height properties to delineate the world of physical pixels and the world of viewport pixels: the latter a realm where zooming, pinching and tapping allow the mobile browser to sensibly scale web pages designed for much larger screens.

For those pages where the viewport’s behavior is constrained, perhaps through the use of meta tags, this is of little concern, since the mapping of the two worlds is 1:1. And indeed, in our tests, when such a tag is present, innerWidth takes exactly the same value as outerWidth – modulo the Android race conditions, at least.

Less well-known might be the fact that, for all these browsers, when an XHTML-MP doctype is present, the same is also true. We’ve alluded to this already: the presence of this forces the viewport width to be the same as the physical width of the screen (either 320 or 480), while still allowing subsequent scaling.

And of course, PhoneGap’s default configuration is also to constrain the viewport, so the values there also match.

But when the viewport has not been constrained, and an HTML5 doctype (or none at all) is used, innerWidth will suddenly start to represent values much larger than the physical screen: and represent the width of the viewport canvas upon which the page has been rendered.

On a portrait iPhone, for example, the default viewport is 980 pixels. On a landscape iPhone it is, well, according to window.innerWidth, 981 (yes, really).

Android 2.3 and earlier used a different value of 800 for the default viewport width, and this is exposed as window.innerWidth (as well as the vestigal value before document load for the constrained tests). With Android 4.0, the default viewport has been brought in line with the iPhone’s: 980 pixels.

window.outerHeight & .innerHeight

Mobile browsers normally have no vertical chrome, so apart from the matter of viewports, outerWidth and innerWidth values corresponded relatively nicely. However, they do have horizontal chrome elements: address bars at top, and toolbars at bottom. So we should expect the height to be reduced accordingly.

Opera, in a way, gets this right. We have already pointed out it surprisingly deducted the browser chrome to calculate its screen.availHeight. But since it then promptly uses the same value for window.outerHeight and window.innerHeight, it meets our expectations on the latter of these two properties at least.

For Android, window.outerHeight is also relatively deterministic. Again, there are timing wobbles, but after page load, the values are consistently 455 (in portrait) and 295 (in landscape). The Android OS bar, as we’ve mentioned, is 25 pixels.

But it’s iOS that baffles this time. Only in homescreen mode, with an HTML5 doctype (or none at all), does the browser report the expected window.outerHeight value of 460.

In all other cases, bizarre numbers come out. For iOS v5.0, for constrained portrait pages, it’s 356 that becomes 445. For non-constrained portrait pages it’s 356 that becomes 1602. For constrained landscape pages it’s 208 that becomes 667. For non-constrained portrait pages it’s 208 that becomes 1702. In PhoneGap, it’s 460 that becomes 1602, or 480 that becomes 1202. And for constrained homescreen apps, it’s 480 that becomes 1602.

The fact that this is the one property whose values significantly vary from iOS v4.3 to iOS v5.0 also raises alarm bells.

Perhaps we could write a whole blog post to reverse engineer is going on here. 356 and 208 seem to have some plausibility, but apart from that – who knows? There’s no apparent Safari documentation for this property, and even WebCore’s own test suite describes the expected results as ‘empirical‘.

I think I can safely caution you never to use window.outerHeight in iOS and expect a meaningful answer.

After that, window.innerHeight seems relatively stable and predictable. In constrained (and XHTML-MP) scenarios in the regular iOS browser, it sits at that familiar 356 value for portrait and 208 for landscape. This is the actual inner height of the browser window, sans browser chrome, as per documentation. (The fact that these two values are not the same amount less than the physical screen dimensions is due to the fact that the landscape toolbar is slightly shallower than the portrait one.)

This pattern is also consistent when the page is launched constrained from the homescreen or in a PhoneGap application. Here, without any browser chrome at all, the values correctly return to the physical screen dimensions minus the 20 pixel tool bar.

However, this value is not as trustworthy when the page has a non-constrained viewport and an HTML5 (or omitted) doctype. In our test, window.innerHeight had values of 1091 and 425 for the two orientations – doubtless dependent upon the length of the content in our actual page – and hard to predict. As if to prove that point, in homescreen mode, this value increases to 1409. Not particularly useful.

When we look at window.innerHeight for Android, the results appear to follow a similar pattern, but, as usual, are somewhat obfuscated by the fact they change throughout the page lifecycle. For constrained viewports, the two orientations’ values are 401 and 241 in Android v2.3 (where the address bar is 54 pixels high), and 403 and 243 in Android v4.0 (where the address bar is 52 pixels high), and the PhoneGap values are also as expected, considering there is no address bar.

But again, the determinism disappears when the viewport is not constrained, the reported values as varied 1234, 496, 1003 and 402. We can deduce that these are viewport lengths rather than window size, that they are content-dependent, and that they change between platform versions due to the updated viewport width – but again, their utility is more doubtful than in the constrained scenarios.

body.offsetWidth, .clientWidth, .offsetHeight, & .clientHeight

We move onto our final set of JavaScript APIs, and we might hope that we are leaving the vagaries of BOM implementations and entering the consistency of the DOM & CSSOM (although, sadly, these properties are still not under the purview of any W3C standard).

These four values should theoretically be available on all DOM elements: the ‘offset’ dimensions include an element’s content, padding and border, while the ‘client’ dimensions are the content and padding alone. Neither include the margin, as detailed in Mozilla’s documentation.

In our case, we are querying these properties for the document’s body, and, since it has no border, the offset and client values should be the same. Our test pages add a CSS margin of 10 pixels, so on the desktop, we would expect its width, at least, to be 20 pixels less than window.innerWidth. Empirically, desktop browsers seem to use the two heights to represent the total length of the page, rather than the height of the window display. (I’d thought that would be body.scrollHeight, but that’s another story.)

How do mobile browsers fare? How does the viewport concept affect these values?

With offsetWidth and clientWidth, iOS and Android work broadly as you would expect. The non-constrained viewports return measurements in the high 900s (and around 800s for Android v2.3), and the constrained pages in the low 300s (for portrait) and mid 400s (for landscape).

It’s notable how and when the choice of doctype affects these values though. With an HTML5 doctype, non-constrained viewport tests on both platforms report 20 pixels less than the viewport size for both values: 960 pixels regardless of orientation.

With an XHTML-MP doctype, as we’ve previously mentioned, the viewport becomes the device width by default, and again 20 pixels are correctly deducted to give us values of 300 and 460 in landscape and portrait respectively. The same expected behaviour is seen with HTML5 doctypes used on constrained viewports.

What is slightly strange is when no doctype is used. In this case, again on both platforms in all scenarios, the clientWidth is the full viewport width (980, 800, 480 or 320), and the offsetWidth is reduced by the margin (to 460, 780, 460, or 300). This seems systemic: as though the lack of doctype puts the browser into a mode where it interprets the body’s margin as a border.

Across all of our testing combinations, though, the offsetHeight and clientHeight values are the most bizarre set of results in the whole experiment.

There are three patterns on Android and iOS. Firstly, pages with no doctype will always have clientHeight equal to window.innerHeight once the </body> tag has closed – but the offsetHeight will be completely different. Secondly, when there is a doctype, the clientHeight and offsetHeight are always the same, and nearly always regardless of what the doctype actually is. (The bizarre exception is Android v2.3 where the HTML5 doctype on the non-constrained viewport causes both values to reduce dramatically at some point after the document load event). And finally, the offsetHeight value of the non-doctype test always produces the same values as the clientHeight and offsetHeight of the HTML5 equivalent.

Got that?

But what the values actually are seems extremely non-deterministic. We’ve already commented on the arbitrary nature of window.innerHeight which the non-doctype results seem to echo. But despite the doctype, orientation and viewport size, the meaning of these values would seem very hard to assess. The best we can say is that when clientWidth or offsetWidth go up, clientHeight or offsetHeight go down (as seems sensible), but that no attention seems to be paid to our 20 pixel margin.

Again, properties best left alone, I think.

In contrast to iOS and Android, which use window outer and inner dimensions as the point of delineation between physical pixels and the viewport, Opera Mobile’s strategy seems to have been to to stay in the world of real pixels until this last document.body set of measurements, and finally we get a sense of how it sizes the viewport.

The default viewport width seems to be 850 pixels, but although Opera has, until now, remained oblivious to the pages’ doctypes, the values seem to suddenly be very dependent upon them. With an HTML5 doctype on a non-constrained viewport, both clientWidth and offsetWidth are 830 (which probably has had the 20 pixel margin deducted), and with XHTMLMP, we get 300 or 460 (which would be consistent with a constrained viewport, also minus margins).

But with no doctype and no viewport constraint, in either portrait or landscape, we get 850 for clientWidth (i.e. no padding) and… for offsetWidth, 2048! What?

And finally, as they were for iOS and Android, the clientHeight and offsetHeight are a fairly disparate bunch of values. The only assumptions we can make are that a) constrained clientHeight with no doctype will be the same as window.innerHeight after the </body> tag; that b) clientHeight and offsetHeight for constrained HTML and any type of XHTML-MP will all be the same value for a given orientation (and that non-constrained HTML5 will also eventually converge on that value sometime after the document load event); and c) that the values themselves will be more or less unpredictable.

But perhaps not as meaningless as the offsetHeight for non-constrained doctype-less pages. It’s consistent. But a highly unlikely 40960 – which must surely, more or less, mean undefined!

@media device-width & width, device-height & height

We conclude the menagerie of screen dimensions by looking at the values used in CSS3 media queries. These are used as ‘features’ in declarations which are used to conditionally load stylesheets or apply the rules within them. Media queries are a staple of contemporary web design, and perhaps should be understood by designers as much as the other properties above need to be understood by developers handling layouts.

Finally, we have some properties which are defined by a standard.

Because, for this test, we needed to evaluate these values in JavaScript, we use the matchMedia function and varied the operand until it returned true. This does mean we only have results for those devices which support that API call: namely iOS v5.0 and Android v4.0.

Well it’s nice to end with some good news. In both platforms, in all conditions, @media device-width always returns the same value as screen.width, and device-height always returns the same value as screen.height. There’s no matchMedia support in Opera, but I’ll assume the same would be true.

This is great – but of course don’t forget the main issue afflicting those measurements: the lack of rotated values in iOS and Android 2.3′s wacky 800 viewport value which I’ll postulate may be echoed here too.

@media width and height also track other JavaScript properties in both platforms. @media width is almost always equal to window.innerWidth (except in non-constrained landscape mode in iOS v5 when the former is 980 and the former that curious 981). @media height is always equal to window.innerHeight.

(It’s not so clear whether this pattern would be followed by Opera too, were we able to measure it this way. To confirm, it would require a CSS-based test harness – perhaps another study.)

But there are a couple of things worth saying about this observation. Firstly, the window.innerWidth and window.innerHeight values themselves are something of a bit of a mixed bag. See the earlier discussions above.

Secondly, it’s interesting to note that the matchMedia result changes with page lifecycle in the same way that the regular JavaScript measures do. This may mean that media queries change their results as the page loads – I don’t know how to predict when these parametric CSS rules are evaluated – and I imagine this might create conditions under which certain resources referred to in the CSS, loaded early in the page (when the size is evaluated to one thing), might turn out to have been unneccessary later in the page’s life (when the size is evaluated to quite another thing).

Hardcore browser theory & probably more testing required.

window.orientation & @media orientation

As a final aside, note that we also measured orientation results. window.orientation returns the number of degrees (0 for portait, 90 for landscape), and is flawless in iOS, and set correctly after </body> on Android. (Just remember not to evaluate orientation before the <body> – it’s likely still to be 0 in landscape mode)

Opera does not seem to support the API.

The media query equivalent is also apparently fine (where measurable). The only Android timing quirk here is PhoneGap in portrait which thinks it’s landscape at first. I guess nothing’s perfect.


Wow. Painful, on the whole.

Let’s see what we can briefly conclude. I’m not going to go back through each of the properties, but a couple of things jumped out at me.

  • Doctypes matter – you may have no intention of using an XHTML-MP doctype, but if you forget your HTML5 one, some measurements are affected.
  • Default viewports vary from 980 through 850, to 800, depending on platform. Be aware that Android’s default has changed between v2.3 and v4.0.
  • Page lifecycle matters: even if you aren’t stupid enough to run measurement code before the <body>, it can still change radically afterwards, at the document load event, or – most painfully – sometime after that.
  • Race conditions seem more common on Android than on iOS – I admit this could also be affected by the poor performance of the platform’s emulator
  • Height measurements are probably too nerve-wracking to use – as might be expected. Except in iOS, where you’ll need height to get width.
  • Nothing much is standardized and where viewports are involved, the chaos of interpretation ensues. That matchMedia provides a JavaScript API into the (standardized) CSS3 properties might be a chink of light.

But overall, the message should be: don’t take anything for granted. Mobile diversity is, unsurprisingly, still with us with a vengeance – even for apparently simple things like screen size.

Check out the table again, get a little scared, choose your APIs carefully, and test on real devices* like crazy.

(* yes, yes, I still realize this whole experiment is underpinned by the ultimate sin of using emulators :-) )

Thoughts? War stories? Techniques? Fears? Comments welcome.

Comments (99)

  1. April 3, 2014
    Tuncay said...

    Thanks for this nice article :)

  2. April 5, 2014

    I have read so many posts regarding the blogger lovers except this post is in fact a
    nice paragraph, keep it up.

  3. April 6, 2014

    Hi there, You’ve done an excellent job. I will definitely digg it and personally recommend
    to my friends. I’m sure they’ll be benefited from
    this site.

  4. April 7, 2014 said...

    Good post. I learn something totally new and challenging
    on websites I stumbleupon everyday. It will always be exciting to read
    through articles from other authors and use a little something from other websites.

  5. April 8, 2014

    I was suggested this website by my cousin.
    I am not sure whether this pst is wrktten by hhim as no one else know such
    detailed about my difficulty. You are wonderful!


    My web blog; ātrie kredīti (

  6. April 10, 2014

    * Makke your choice from exgensive stylish designs and a model from 1000’s available online for easy and reasonable shopping on-line.
    The hazard of traditional tobacco cigarettes has been preached to no end over time.

    Electronic cigarettes are getting reputation because they have been released.

    my web-site: accessori sigarette elettroniche

  7. April 16, 2014

    I’m gone to inform my little brother, that he should also
    pay a visit this website on regular basis to take
    updated from most recent news update.

  8. April 19, 2014

    Having read this I believed it was extremely
    informative. I appreciate you spending some time and effort
    to put this article together. I once again find myself personally spending a significant amount of
    time both reading and posting comments. But so what, it was still worth it!

  9. April 22, 2014

    Wow, this paragraph is nice, my sister is
    analyzing these kinds of things, thus I am going to tell her.

  10. April 22, 2014

    The first step to raking in the levels is game type. S> bases in Pakistan with bomb bay doors open, to show how loaded they were, but
    that did not change one fact. Just like air support, the proximity mines secondary abilities are a lot weaker than thought.

  11. April 23, 2014

    An impressive share! I’ve just forwarded this onto a coworker
    who has been doing a little homework on this. And he in fact bought me
    dinner simply because I found it for him… lol.

    So allow me to reword this…. Thank YOU for the meal!!

    But yeah, thanks for spending some time to discuss this issue here on your web page.

  12. April 24, 2014

    Midbases – Midbases are usually 5, 6 or 8 inch speakers that
    are designed to go lower in frequency and are part of a three way
    system with a mid and tweeter. It is rapidly quick and outrageously
    agile, but, however not as robust as the Hannibal or Wild Bull.
    You may also read all you need to know pertaining to diagnostic and repair details in
    these manuals.

  13. April 29, 2014

    Some are seeking to find a second residence to fly
    to when the winter climate in their Canadian household will get too intense.
    Multi-track Recording: This allows you to record different sounds on different
    tracks – for example a drum beat on one track, a guitar on another, lead vocal on another, and so on.
    Purchasing any downloadable PC game from Amazon from now until the end of 2012
    comes with a $5 credit that can be used towards
    the 2012 Editor’s Choice Games.

  14. April 29, 2014


  15. April 29, 2014

    They’re like one big experience farm, especially if
    your Pokemon are higher levels and you can just breeze
    through them. The most interesting part as this happens will be that Ash.
    mon Bank was originally scheduled to release in North America on Dec.

  16. May 1, 2014

    Yes, no Friday or Saturday night parties if you are doing
    this on a weekend. You should cleanse your skin using your wash cloth or loufah
    to massage the spot where cellulite exists. It taught me to be to quickly
    attain amazing benefits and cleared that gruesome cellulite up inside a relatively short period.

  17. May 2, 2014

    It is often used in entertainment and business world.

    It covers a lot of anatomy for animation and how
    to make your human characters look better. Learning the building
    blocks behind the scene with customized programming training will put together the ground for capitalizing on
    this opportunity.

  18. May 3, 2014
    Jai said...

    І delight іn, lead to ӏ discovered ʝust what ӏ used to Ьe having a lߋok for.
    Ƴoս’ve еnded myy 4 day lengthy hunt! God Bless ƴou man.

    Have a ǥreat day. Bye

    Μy web рage ::, Jai,

  19. May 3, 2014

    While many discovered professors get abandoned hope
    of at any time discovering the facts driving titanfall obtain, I
    for one believe it is nonetheless a worthwhile
    cause for assessment. Looking at the attitudes from the fresh with all the
    actuality felt by their elders is like different the political election in the guy all the time recover of just one a lot more comfortable with titanfall download.
    Money has in a few locations been viewed to take hold
    of an increasing ananiathesis regarding intergovernmentalism resulting in neo-functionalism.

    Here is my weblog –

  20. May 7, 2014

    I couldn’t resist commenting. Very well written!

    Take a look at my homepage download film gratis expendables

  21. May 8, 2014

    May I simply say what a relief to uncover someone that truly understands what they are talking about
    over the internet. You actually know how to bring a problem to light and make it important.
    More and more people have to read this and understand this side of your story.

    I can’t believe you’re not more popular because you surely possess the gift.

  22. May 10, 2014

    Hey I know this is off topic but I was wondering if you knew of any
    widgets I could add to my blog that automatically tweet my newest twitter updates.

    I’ve been looking for a plug-in like this for quite some time and was hoping maybe you would have
    some experience with something like this. Please let me know if you run into
    anything. I truly enjoy reading your blog and I look forward to your
    new updates.

  23. May 16, 2014

    Have you ever considered creating an ebook or guest authoring on other blogs?
    I have a blog based on the same information you discuss and would really like to
    have you share some stories/information. I know my audience would value your work.
    If you are even remotely interested, feel free to send me an e mail.

    Review my webpage criminal attorneys phoenix

  24. May 16, 2014

    I am really grateful to the owner of this web page who has shared this wonderful paragraph at at this time.

  25. May 16, 2014

    Piece of writing writing is also a excitement, if you know afterward you can write
    or else it is complicated to write.

  26. May 17, 2014

    I know this site offers qualoty depending articles or reviews
    and extra material, iss there any other web site which offers these stuff in quality?

  27. May 24, 2014

    You have made some decent points there. I checked on the
    internet for additional information about the issue and found most individuals
    will go along with your views on this website.

  28. May 27, 2014
    anoni said...

    This is great but a bit outdated. Is there an update coming soon to that table?

  29. May 28, 2014
    rea said...

    Spot on with this write-up, I really think this website needs
    much more attention. I’ll probably be back again to rea through more,
    thanks for the information!

  30. June 4, 2014

    Everyone loves it when people come together and share
    views. Great blog, continue the good work!

  31. June 13, 2014

    I blog frequently and I genuinely appreciate your content.
    The article has truly peaked my interest. I am going to bookmark your blog and keep checking for new
    information about once a week. I subscribed to your Feed too.

  32. June 19, 2014
    Get More Info said...

    Apple by jetzt includes Rhapsody als Anwendung, die eine ideal Begin, Yet ist at dieser Time behindert by Of Mangel der Ability in Richtung Of retail-Speicher domestically bei Ihren iPod, und is gebildet Of eine trostlose 64 Kbit/s etwas price Tag. Wenn diese adjustments, dann wird fairly negieren diese benefit für den Zune, nonetheless die 10 audio für Each Zeitraum von dreißig Tagen Willen nevertheless werden substantial Furthermore inside Of Zune Move’ Prefer.

  33. June 19, 2014
    jhondevera said...

    I like the information shared in this page and your thoughts especially this one “But I do accept that dealing with screen size is at least a first step”.

  34. June 23, 2014
    barricade said...

    Simply desire to say your article is as surprising.

    The clarity in your post is just nice and i can assume you’re
    an expert on this subject. Well with your permission allow me to grab your feed to keep
    updated with forthcoming post. Thanks a million and please carry on the rewarding work.

  35. June 27, 2014

    When I initially commented I clicked the “Notify me when new comments are added” checkbox and now each time a comment is added I get three e-mails
    with the same comment. Is there any way you can remove people from
    that service? Cheers!

    Visit my web blog … demenagement residentiel

  36. June 27, 2014
    More Bonuses said...

    by yourself thoughts se I estimate un handful of di content articles come lengthy
    come ho offer you credit rating e assets again towards tuo net?
    È mio world-wide-web within i incredibly exact market come la tua
    e il mio targeted traffic sarebbe fairly convenience against una large quantità di content material yourself give listed here.
    Assicurarsi di enable me understand se questo ok con on il tuo. Molto of because of!

  37. June 28, 2014

    What a data of un-ambiguity and preserveness of precious familiarity on the topic of unpredicted feelings.

  38. June 30, 2014

    We’re a bunch of volunteers and starting a new scheme
    in our community. Your site offered us with valuable information to work
    on. You’ve done an impressivce task and our whole group
    willl likely be grateful to you.

    my blog – Soluções Energéticas

  39. July 3, 2014
    Visit Website said...

    once una cancelación. Knowledge el most importante motives involving car o truck insurance policy cancelar puede aid automobile homeowners protect against 1 quemando de los privilegios de utmost high obtainable. Due para el ideas as significa un resultado de web sitio.}

  40. July 7, 2014
    Francesca said...

    It’s hard to find your website in google.
    I found it on 19 spot, you should build quality
    backlinks , it will help you to get more visitors. I know how to help you,
    just type in google – k2 seo tips

  41. July 8, 2014

    I visited many blogs however the audio quality for audio songs existing at this site is actually excellent.

    my page – service de salon de toilettage a Sherbrooke

  42. July 8, 2014

    Hello! This post could not be written any better!

    Reading this post reminds me of my good old room mate!
    He always kept talking about this. I will forward this write-up to
    him. Pretty sure he will have a good read. Thanks for sharing!

    my blog post :: comptoir en quartz Quebec

  43. July 8, 2014

    Good blog you have here.. It’s difficult to find quality writing like yours nowadays.
    I honestly appreciate individuals like you! Take care!!

    My homepage; bungalows a vendre Sherbrooke

  44. July 15, 2014
    Chase said...

    Finally i quit my regular job, now i earn decent money on-line you should try too, just search in google – bluehand
    roulette system

  45. July 17, 2014

    Howdy, i read your blog occasionally and i own a
    similar one and i was just curious if you get a lot of spam responses?
    If so how do you reduce it, any plugin or anything you can recommend?
    I get so much lately it’s driving me insane so any support is very much appreciated.

    Feel free to surf to my web site :: Best Funny Animal

  46. July 21, 2014

    Hi there to every one, the contents existing at this
    website are in fact remarkable for people knowledge, well, keep
    up the nice work fellows.

  47. July 23, 2014
    Our site said...

    I enjoyed come considerably come on il tuo ti get effettuate straight destro here. Lo sketch è sophisticated, vostro autore make un difference make qualsiasi differenza elegant. on le altre hand, by yourself regulate take purchased anxiousness more of che oneself drive essere furnishing immediately after. ill definitely occur far more beforehand back considering that just i esatta same practically una good deal from tempo per time within just circumstance by yourself protect questo strengthen.

  48. July 27, 2014

    A bags-turbo charge Helps to make the general bags theory So Thrilling
    Chicago Bears #99 Dan Hampton Blue Team Color Big Number With Be,Cheap NFL Jersey-Chicago Bears Jerseys

Leave a Reply