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 (149)

  1. July 29, 2014
    Michael C. said...

    You mention you ran the tests using textual page content; I’d be interested to see if using a fixed-size div at something like 5000×5000 would affect things in a way that would give a clearer insight into why certain values are what they are.

    Also – spam filter please! :o

  2. July 29, 2014
    homepage said...

    DVRs are more popular for its convenience and image quality.
    Audio and video signals are carried on a single coaxial cable.
    Hdmi to component video converter

    Be certain to sign up for the free ezine and ebook for the website.
    If these content creation tips have helped you, come checkout and
    learn how I was capable of cut my article writing time from nearly one hour to lower than 10 minutes.
    Hdmi cable with rca jacks homepage Content writing or content development,
    is a process of writing, modifying, paraphrasing and editing.
    There are many varieties of directories including regular directories, blog directories, niche directories and

  3. July 31, 2014

    The Unique babyliss program Will Work While You Go to bed!
    tiffany jewellry sale

  4. August 12, 2014

    List of helpful approaches to find out about babyliss before you are left out.
    nail down a great rate 2013 new! moncler down jackets womens stand collar zip black supplier

  5. August 12, 2014

    The Spanking new babyliss application Work Even When You Sleep!
    shop for men louis vuitton taiga leather organiser atoll gray m30652 early bird specials

  6. August 12, 2014

    Can I merely say what a relief to uncover somebody who actually is aware of what theyre talking about on the internet. You undoubtedly know the approach to bring an concern to mild and make it critical. Extra folks must read this and perceive this aspect of the story. I cant consider youre not a lot more popular since you positively have the gift.
    Ray Ban Clubmaster Frames Only

  7. August 12, 2014

    Superb post but I was wanting to know should you could write a litte more on this subject? I’d be quite thankful if you could elaborate slightly bit much more. Thanks!
    Ray Ban Caribbean Optical Uk

  8. August 12, 2014

    Immigration… [...]the time to read or pay a visit to the content or internet sites we have linked to below the[...]…
    cheap beats by dre pro touring

  9. August 12, 2014

    Trusting to make the right decisions can be tough. It can take many people a long time to build a strong moral system. Frankly it takes more than just happening to happen.
    michael kors coupons outlet

  10. August 17, 2014

    When I originally commented I clicked the “Notify me when new comments are added” checkbox and now
    each time a comment is added I get four e-mails with tthe same comment.

    Is there any way you can remove mme from that service? Appreciate it!

  11. August 18, 2014
    antalya escort said...

    Escort Bayan Artık Hayal Değil Özel hayatınızdaki en iyi kararı vermek üzeresiniz. antalya escort bayan hizmetimizden yararlanarak gündelik hayatın antalya escort ilan

  12. August 30, 2014

    Thanks oon your marveous posting! I definitely
    enjoyed reading it, you can be a great author.I will make certain to bookmark your blog and will eventually come back in tthe future.
    I want to encourage you conntinue your great
    work, have a nice holiday weekend!

  13. September 5, 2014
    spillemaskiner said...

    It is not my first time to go to see this website, i am browsing this web site dailly and get good information from here all the time.

    Here is my page spillemaskiner

  14. September 6, 2014

    Simply want to say your article is as astounding. The clearness
    to your post is just cool and that i could suppose you are a professioknal in thnis subject.
    Well with your permission allow me to grab you feed to stay up to date
    with forthcoming post. Thanks one million and please continue the rewarding

    my blog post :: Las Vegas Dryer Repair

  15. September 9, 2014

    Hi there! Quick question that’s completely off topic.

    Do you know how to make your site mobile friendly?

    My web site looks weird when browsing from my iphone 4.
    I’m trying to find a template or plugin that might be
    able to correct this issue. If you have any recommendations, please share.

    Review my blog post – how to make a blog

  16. September 9, 2014
    shisha pens said...

    Some I did secretly, under a blanket on the airplane and in the hospital; others
    I did in the open. Electric cigarettes or electric cigarettes,
    are the newest products in the quit-smoking industry.
    Either that, or they are using the highly controversial e-cigarette to cover up the fact that the
    fire was the hospital’s fault.

  17. September 11, 2014

    Valuable information. Lucky me I discovered your web site unintentionally, and I’m stunned why this
    twist of fate didn’t took place in advance! I bookmarked it.

  18. September 12, 2014

    Good day very cool web site!! Man .. Beautiful ..

    Superb .. I will bookmark your site and take
    the feeds additionally? I’m glad to find numerous useful info here in the put
    up, we need develop more techniques in this regard,
    thank you for sharing. . . . . .

  19. September 23, 2014

    Hi there! This is kind of off topic but I need some advice from
    an established blog. Is it very difficult to set up youyr own blog?
    I’m not very techincal but I can figure things out prettry fast.
    I’m thinking about creating my oown but I’m not sure where to begin. Do yyou have anny tips orr suggestions?
    Appreciate it

  20. October 10, 2014

    Following this routine should make steady, consistent fat loss
    even though keeping or even developing muscle.

  21. October 15, 2014
    Martina said...

    I’d like to thank you for the efforts you’ve put in writing this site.
    I really hope to see the same high-grade content from you in the future as well.

    In fact, your creative writing abilities has encouraged me to get my own blog now ;)

  22. October 28, 2014

    I do like the way you have framed this specific matter plus it does indeed offer me a lot of fodder for consideration. However, through everything that I have seen, I simply wish as the comments pack on that people stay on point and don’t start on a soap box regarding the news of the day. All the same, thank you for this outstanding point and while I can not necessarily concur with the idea in totality, I respect the perspective.
    herve leger dress sale online

  23. October 28, 2014

    A lot of of what you state is astonishingly appropriate and that makes me wonder why I had not looked at this with this light previously. This piece really did turn the light on for me personally as far as this topic goes. Nevertheless at this time there is actually one issue I am not too cozy with and whilst I try to reconcile that with the actual core idea of your issue, permit me see just what all the rest of the subscribers have to point out.Very well done.
    black ugg boots button

  24. October 28, 2014

    My partner and I stumbled over here from a different web address and thought I may as well check things out. I like what I see so now i’m following you. Look forward to finding out about your web page yet again.
    uggs for men 70s costumes

  25. October 31, 2014
    eusebio517 said...

    Hey there. Do you know how you can make a website mobile warm and friendly?
    I’m trying to find a topic or wordpress tool that might be able to resolve this concern. If you have any suggestions, please share.
    Brief problem that’s 100 % off of subject.
    My website appearance weird when browsing.

  26. November 7, 2014

    It’s amazing to pay a quick visit this site and
    reading the views of all mates about this paragraph, while I
    am also keen of getting know-how.

  27. November 11, 2014
    Mireya said...

    Excellent way of telling, and good article to take information about
    my presentation subject, which i am going to present in institution of higher education.

  28. November 14, 2014
    Ute said...

    I am actually delighted to glance at this web site posts which includes lots of useful facts,
    thanks for providing these information.

    My web page breast cancer symptoms [Ute]

  29. November 16, 2014

    Ich wollte einfach einen netten Gruss hinterlassen.
    Bin gerade auf eure Seite gestossen.Peuterey Men Jackets Peuterey Women Jackets

  30. November 25, 2014 said...

    Pretty component to content. I just stumbled upon your site and in accession capital
    to say that I acquire in fact loved account your weblog posts.

    Anyway I will be subscribing for your feeds or even I success you get right of entry to persistently rapidly.

  31. November 25, 2014 said...

    This is a really good tip especially to those new to the blogosphere.
    Short but very precise info… Many thanks for sharing this one.
    A must read article!

  32. November 26, 2014 said...

    I just like the valuable info you supply in your
    articles. I’ll bookmark your blog and test again here regularly.

    I am rather sure I will be told lots of new stuff proper right here!
    Best of luck for the following!

  33. November 27, 2014 said...

    I visit daily some websites and information sites to
    read posts, but this web site presents feature based content.

  34. November 30, 2014
    Claire said...

    My family members all the time say that I am wasting my time here at
    net, but I know I am getting experience all the time
    by reading such fastidious articles or reviews.

  35. December 18, 2014

    [...] pourquoi ce n’est pas aussi simple, je vous invite à consulter l’excellent billet First, understand your screen basé sur un tout aussi excellent (et complet) test du célèbre Peter-Paul Kock [...]

  36. December 29, 2014
    Read More said...

    include que understand a number of very good cosas below. Totally well worth marcadores para volver a visitar. Me marvel como una whole lot effort y arduo trabajo oneself position towards build 1 de Those Good enlightening website web page.

  37. January 13, 2015

    |ハミルトンジャズマスター 中古| that a door had been opened for me to explore mysoul, hey I a life coachcoach or the insect recognised

  38. January 13, 2015

    |セイコー ワールドタイム| The forwards (CF and FW) are the players display in the same location,

  39. January 13, 2015
    Ugg Tasman said...

    |Ugg Tasman| The city you selected is glamorous, There were definitely much better action movies last year.

  40. January 13, 2015


  41. January 13, 2015

    L’universit茅 de Notre Dame enverra m锚me une lettre de remerciement aux farceurs en leur demandant un nouveau dipl么me car le nom de John Shumate 茅tait mal orthographi茅.

  42. January 29, 2015

    [...] und Betriebssystemen kein zuverlässiges Verfahren, was auch der Webentwickler James Pearce in einem ausführlichen Artikel darlegt (vgl. Pearce 2011). Das beim Nutzer zudem zwangsweise JavaScript aktiviert sein muss, [...]

  43. February 9, 2015

    Very soon this site will be famous amid all blog users, due to it’s nice posts

  44. February 11, 2015
    Revival Meeting said...

    This sort of movie intends to assist non-believers of God to learn and seek what is correct and how to experience God within our daily lives. Parents get a needed break, and the youth gets a break from bad influences and can gain a new, healthy outlook on life. Just make sure that you choose the right one for the next upcoming occasion, so that you can make your family members and also friends happy and remembered.

  45. February 11, 2015

    Bé số khá như tham vọng của Con Cưng cũng thành phần như thế nào
    đề cập lên được tính thu hút của thị
    trường này.

  46. February 11, 2015

    Great blog right here! Also your site so much up fast!
    What host are you using? Can I get your associate link to your host?

    I want my website loaded up as quickly as yours lol

  47. February 11, 2015

    I was very happy to find this great site. I want to to thank you for ones time for
    this particularly fantastic read!! I definitely enjoyed every bit of it and i also have you saved as a favorite to see new stuff on your web

  48. February 12, 2015

    Nice blog here! Also your web site a lot up fast! What web host are you
    the use of? Can I get your affiliate hyperlink on your host?

    I wish my site loaded up as fast as yours lol

  49. February 27, 2015
    Leah said...

    For your greatest time, I have got involved in strong
    work outs pressing myself personally on the limitations to attain my
    preferred pounds. That’s things i caused by stay healthy.
    But my body weight dilemma was still an issue mainly because whenever I’m done doing
    exercises, I also consume a lot to compensate the electricity
    I missing. Doesn’t appear sensible. I desired a thing to
    assist me give up eating a lot nevertheless i also don’t like the
    idea of starving me personally. And PhenElite slimming pills
    just did the key. It suppressed my hunger for foods without needing these feelings of famished myself.
    I began along with the product 3 months in the past getting 2
    supplements a half-hour before lunchtime. I usually have very good lunchtime daily meals.
    But what produced the real difference was after my
    work out, I no longer binged for food. I could very last the evening with 2 crackers along with a window of
    whole milk. Forget about night time heavy meals.

    And soon after 21 days or weeks with that regimen, I misplaced 17 pounds and so i
    dropped with a 32 pant dimensions to 29. I’ve never ever
    experienced leaner similar to this just before, this in 3 days, couldn’t request a lot

Leave a Reply