Check HTML5 Browser Height and Width using Canvas

I’ve been working on building mobile web apps the last few weeks and I needed a quick way to check the browsers screen size for both mobile and non-mobile. So, I built a small, rough app that quickly lets me do that. Here’s what the app does: 

–          Detect HTML5 Canvas support

–          For height give clientHeight, offsetHeight and scrollHeight.

–          For width give clientWidth, offsetWidth and scrollWidth.

–          Recalculate when browser is resized or rotated. Here’s the link to try it out.

Remember, it’s rough so if you need to tweak it for your needs feel free to grab the code via the link or QR Code and play:

At the heart of the app there are a few key pieces of code. There’s the Canvas element:

<canvas id="rectangle1" style="height: 100%; width: 100%; border:solid 1px #000000;"></canvas>

And, there’s the code that reads the height and width properties from the canvas element:

document.getElementById("main").innerText =
"clientHeight: " + rectangle1.clientHeight + ", clientWidth: " + rectangle1.clientWidth + "\r"
+ "offsetHeight: " +rectangle1.offsetHeight + ", offsetWidth: " + rectangle1.offsetWidth + "\r"
+ "scrollHeight: " + rectangle1.scrollHeight + ", scrollWidth: " + rectangle1.scrollWidth;

Here are a few guidelines on how to interpret the results:

It works great! This means you are using a modern browser that supports the HTML5 Canvas element.

Nothing shows up. If the mobile browser shows nothing, it probably doesn’t support HTML5. Example of this is Firefox for Android. Hey don’t laugh, we can’t change what browser people use.

Rotating phone doesn’t change numbers. If the numbers don’t change when you rotate the phone, then the browser has incomplete support for HTML5. Example of this is Opera for Android.

Just the height numbers don’t change or are inaccurate. The default height for canvas on most browsers is 150px. So if the browser can’t interpret the property height:100%, then you may simply see a height of “150” in the app.

Height number is too small. In some browsers, if a sub-window is open, for example Chrome developer tools, then the height number reflects the available browser window height not including the developer tools sub-window.

If you have suggestions for improvements the let me know!

[Minor update: May 26, 2012 – corrected a couple typos]


Caniuse– Canvas

Mozilla – Determining the dimensions of an element.

The 1 Minute Primer for HTML 5

HTML 5 is getting a lot of press these days and I get a constant stream of questions from many non-techies, as well as developers, asking me to explain HTML5 in layman’s terms. So here it is.

HTML 5 is really a combination of three things: HTML, CSS and JavaScript. When all three of these technologies work together in a web browser then you have an HTML5 application. Period.

Why should we care about HTML 5? HMTL 5 brings many long awaited enhancements that make it easier for web developers to build more complex applications. More importantly, HTML 5 is being adopted by the major browser vendors: Google, Microsoft, Mozilla and Apple and this adoption is making it possible for developers to take advantage of the latest web technology that are built into web browsers.

How is HTML 5 “built into a web browser”? Web browsers have to interpret a web page first, and then display the content for you. Browsers contain logic that let’s them parse a pages’ code, and that code provides instructions for the browser to do certain things. Behind the scenes, in fact, the page you are looking at is built using code. It’s the browser that interprets the code and displays it in a way that makes sense to you. If you haven’t ever seen web page code then you can usually select View > Source on your browsers tool bar. Cool, right?!

HTML 5. HTML 5 is the latest version of the Hypertext Markup Language (HTML) specification which has been around in various forms since approximately 1991. HTML is a tag based language that defines the meaning and placement of elements of a web page. For example, a <button> tag defines a clickable button on a web page.

Cascading Style Sheets (CSS). Cascading Style Sheets, or more specifically CSS version 3 (a.k.a CSS3), provide the ability to apply styling to HTML elements. An example of styling would be to change the color of an HTML <button> from grey to green, as well as defining where on a web page it will be visible such as the top left corner.

JavaScript. JavaScript, which is really the meat behind HTML 5, is a type of programming language that lets developers implement actions within a web page. An example of an “action” would be when a web page visitor clicks a button that loads a picture. So, HTML defines the <button>, CSS styles the button, and JavaScript handles the action behind the scenes by retrieving the picture and then telling the browser how to display it for the end user.

This all sounds great, are there any downsides? Yes. First, HTML 5 is a standards-based specification that is still a work in progress. The specification and all its’ associated parts won’t be finalized for some time, possibly years. The good news is that browser vendors are keen to adopt this standard as much as possible. Second, implementation across different browsers isn’t 100% consistent. The good news is that there are tools and online resources to help developers work around many of these problems. Last, older versions of browsers (e.g. Internet Explorer 7 or 8, older versions of Safari, etc) don’t support HTML 5. There are strong campaigns under way to educate people to upgrade for security, performance and viewing experience.

So, there you have it. That’s a cursory pass at HTML 5 and I hope this post helps. I’ve added a few links at the bottom if you want to learn more about it.

Learn More: – includes information on features, tutorials and great slide decks. –  includes live “Try it” samples that let you explore the functionality.

W3C HTML 5 Specification –the World Wide Web Consortium is the group that writes the standards. If you are a techie, this is “the” specification that the browser vendors base their functionality on.

Firefox It’s Been Nice Knowing You

I recently dumped Firefox 7 and relegated Firefox to the occasionally used computer corner where I store all my various testing tools. After sending several emails to Mozilla, blogging about how terrible the new release is and tweeting about it…I heard not a peep, zero, zippo. Which is strange. It’s rare these days to not hear anything back from an organization, especially when you make a complaint on social media that’s backed by a blog post. I supposed I’m just one small voice in the sea of millions.

So, I’ve done what consumers do and voted with my feet. I dumped Mozilla in favor of Chrome, which has been elevated to the lofty status of what they call the “Default” browser.  I’m still getting used to Chrome and recently had some issues with accidentally closing tabs. And, it’s developer tools are a bit more rustic than Firebug or httpfox’s polished functionality. But, it does seem faster and it’s definately more stable.

So, that’s that. The browser wars continue, especially on the mobile front. By the way, I did briefly try Firefox mobile but dumped that also because the work flows were too ackward. There will be dozens of new browser updates in the next year, who knows what new excitement is in store.

Mozilla + Firefox über-release cycle = #FAIL! The long tail of costs and risks associated with fast release cycles.

Dear Mozilla Foundation, according to your web site you promote openness, innovation and participation. So, I feel strongly enough to write you about a problem. You are pushing for too many major releases in too short of time. If it wasn’t for firebug and httpfox developer tools, I’d dump Firefox as my browser of choice right now. In my humble opinion they are still the best web developer tools around…for now. But back to my point, and note that this isn’t a rash or knee jerk response: Firefox 7 appears to be the least stable browser I’ve used in a long time, Period. I’ve had a dozen lock-ups, problems on startup and various slow page load problems.  

I haven’t added any new plug-ins that might de-stabilize it. In fact, I’ve been using the same set of plug-ins since Firefox 3.x. And, I haven’t had any similar widespread problems with the latest versions of Internet Explorer or Chrome. You might ask “What if it’s just your machine?” To that I say I’ve experienced this on four different machines, and many of my colleagues share the same opinion. So Mozilla, I’m hanging on by my fingertips and you are stomping on them.

The Heart of the Problem

Maybe I’m the exception, but I believe that getting cool new browser features every few months at the expense of stability is the wrong choice. I’ve said this before in another post and I’ll say it again. I’ve read countless articles saying this is what Mozilla has to do to stay competitive. I say you couldn’t be more wrong and that there needs to be a more balanced approach to major releases. Now, I’m not implying that you, Mozilla, are intentionally leaving stability or scalability behind. I’m saying that the massive rush to stay abreast of new features being released by your competitors has to come at a cost, and I believe the cost for Firefox, at this point in time, is stability.

So, in response to an outcry over this and other related problems, and in order to counteract some of the side-effects of your über -release cycle, you will begin offering Extended Support Release, or ESR, sometime in the next year. I interpret this as an attempt to mitigate the über -release cycle’s short-term and long-term risks and costs on Enterprise customers by offering an extending support cycle for a limited number of releases and time. But…readers of this post must read the fine print under the Caveats and Risks sections; for example, ESR’s won’t apply to Firefox Mobile at a time when mobile usage is exploding. And, the ESR makes note of the security risks of staying on an “older” release. Fair enough. However one possible conclusion is, on the surface, ESRs seem like a mere concession to a looming problem, and perhaps it is a stop gap measure at best. Perhaps I’m wrong?

Driving Factors

I want to ask Mozilla the following questions:

  • What’s coming up in your next release?
  • Are the changes really so fundamental that the next release has to be a major numbered version?
  • What metrics are you using to make your decisions?
  • How fast are your users upgrading to new versions world-wide?
  • Is the new version adoption rate trending upward or downward?
  • Who are your largest supporters? Large organizations or the millions of individual users?
  • Have you taken a public survey from your largest supporters of what they would like to see?

Now, of course, this post is just my opinion, and I’m willing to admit that I may be seeing this problem in the wrong light or a different context. But, I and a lot of others want to know what you are thinking.

Hypothetical Scenario

Here’s a hypothetical scenario on how an organization might interpret the ESR, and I speak for myself on this one and am simply presenting one outcome of possibly many. Mozilla will continue to blast along having thirteen more major releases between now and March of 2013*. In response, CIO’s of major organizations will start to choose a pattern of leap frogging across swaths of major releases. In response, their development and IT teams will focus on building web apps, along with a full test suite and certification for Firefox 7. Then their next fully tested and certified release will be targeted at Firefox 9 sometime next year. These organizations may choose to not even support Firefox 8 because it’s between their development and certification cycles. There’s also a long-tail of cost associated with maintaining numerous previous releases across a multitude of browser versions from all the major vendors. In effect, these CIOs will weigh the security risks, costs and other issues over the costs of deploying an army of IT folks and developers to keep up with the über -release cycle.

Concluding Remarks

Mozilla I hope you are listening. You should take the following steps to reduce the possibility of failing as a leading browser vendor:

Focus on stability – IMHO, Firefox appears to be paying the price in the rush to add new and supposedly better features. I’m not even sure what those are because your release process isn’t transparent. As your consumer, first and foremost I would like my browser to be rock solid, followed by speed, followed by snazzy features. Rock solid to me also means that it’s as secure as possible. “Dot” releases are okay and in general they ease the support-related fears from both developers and IT teams.

Slow down the release cycles – Mozilla, you already acknowledged there’s a problem when you proposed the ESRs, but you need to go further than acknowledgement and a pat on the back which is what I consider ESRs to be. Seriously.

Now, I know I didn’t address these above, but I’m throwing these into the mix because I think they are strongly related:

Provide guidance on browser certification and best practices – if documentation for this exists today I can’t find it. Building apps on browsers, today in the year 2012, is still like the Wild West in that everyone does what they think is right, but there’s really no word from the Vendor(s) themselves. Most people point to the W3C. But, everyone agrees that what’s agreed upon in the standard is not what’s officially interpreted and implemented by browser vendors in each and every release.

It’s been speculated by others that having browser vendors offer guidelines would crush innovation, and I strongly disagree. It’s your platform we are building on and you know how to do that in the best possible way. Believe it or not, you are also a key caretaker of the internet in that the web, in its current state, wouldn’t exist without the browser. And, I think it’s your responsibility to step up to the plate and help take leadership role, not just a feature-ship role and simply hope that everything turns out okay.

Provide official tools for browser certification – please don’t leave this entirely up to third parties with different goals and objectives. Based on your vast experience in this process, it would benefit everyone if you were to publicly share your tools, patterns, knowledge and guidance. Or, maybe you already do share this with key partners. Yes, you are open source, but not open process. Browsing through your partner sites doesn’t give any indication of publicly available tools.

I believe that the combination of these four goals would help propell Firefox on more successful trajectory than the one us users see today. Without the inclusion of my last two suggestions, as an application developer I’m hoping my code will work as best as possible, without truly knowing what that means. Is what we are doing simply good enough, or could we all do better? What are your recommendations on patterns for best performance or even unit testing for various languages? I can’t help but believe that you hold the key to that level of knowledge, as well as methodologies and tools that can help Firefox help us deliver on the next generation of web applications.


*Mozilla release schedule

Mozilla rapid-release schedule

Mozilla Defends Rapid Release of FireFox Versions (CIO Magazine, August 2011)

Improving Browser performance and stability – will web workers help?

The single-threaded nature of JavaScript is an old tradition that needs to go away. It was great in the wild-west, internet days of the 20th century. But, today we have more complex needs that are being driven by the advancements that are happening around good old JavaScript as we know it, such as…on-going advancements in HTML 5.  

The reason I bring this up is because I’ve been watching the discussion on Web Workers as it has evolved.  It’s a brave attempt to bring a standard for implementing some sanity on this ancient notion of single threading. Now, I do want to say that this post isn’t about debating the merits of web workers, per se. It’s about giving developers better tools on which to build web applications for end users. I’ll be the first to agree that many developers (but not all!), for a variety of reasons, build apps like factories, but without many quality checks.

One argument the pro-single threaded parties claim is that doing away with single-threading will make things even more complicated for the companies that develop browsers and the developers that build apps on them. And, in effect, you’d be giving them (web app developers) free license to create even more terribly built web pages that crash browsers.  For brevity sake, I’m only picking this one out of many possible arguments, as the one that comes up most often in discussions.

I also don’t ever recall seeing a browser vendor themselves saying something like this publicly, but it’s possible.  This is a very weak argument that won’t stand the test of time. Sure, as we build more complex apps then there will be more of both good and bad apps. That’s just the way things work. There’s no way we would ever have a single authority that reviews all web apps before they are published. Perhaps, similar to what Apple does with iPhone apps. Not only would it be impractical, but it certainly seems like it goes against the spirit of the internet and WWW.

I fall into the camp of evolving the tools to better to fit the ever-changing and growing needs of the end users. End users don’t understand the limitations of the browser technology.  They don’t need to and shouldn’t be expected to. All they know is that they want to see ever more visually stunning applications that run well and don’t crash all the time.

Developer tools and technology are much, much more advanced now than when the venerable Mosaic Web Browser hit the scene back in 1993. As an example, all eyes are on HTML 5 (more on that at a later date), and certainly we have the well-known browser plug-ins: Flash and Silverlight, and each has their own development kits. These technologies enable the building of some of the most eye-catching websites, and they really opened people’s eyes on what the web experience should be more like.

Now, I am eyes-wide-open about this. There are some well-documented, but not well understood existing limitations related to the web surfing/development experience as I blogged about here. But, merely saying things should not change because it will become too complicated isn’t a good enough reason to, well…not change.  There are lots of smart people out there that love solving these types of problems.

So, I have a few suggestions of my own for the browser vendors and others to debate and work on. I think web workers are huge step in the right direction. But I also think there’s some other more strategic things that browser vendors could be doing that I think would also help. To me these are just as important as evolving the web standards, perhaps even more so. This is about browser vendors officially providing guidelines for us on how to do our job better:

  • Best Practices Document. All the major vendors should publish web development best practices for HTML and JavaScript development. And, I’m not talking about the W3C standard. That is what’s expect, but not actually what’s implemented. For example, I did a quick search of “web development best practices” using Google and Bing and the very first result I found was a short, not-really-so-helpful article on the Apple web site that was written in 2008!
  • Online HTML/JavaScript Validation engine(s). Each browser vendor should publish their own online HTML/JavaScript validation engine. Or better yet would be if someone builds one site that checks all major browsers in one shot and provides actionable feedback. I’m aware of other types of validators such as this one by W3C for HTML and the like. But, in general right now it’s just a hodgepodge of 3-rd party tools and guesswork as to whether a web app is working right. And, if you are like me and running the web debugger all the time, you’d know how many broken web pages there really are.


The browser as an operating system

Having a basic understanding of how our web applications affect browser performance is the key to determining whether the apps you build will be great, and which apps will be a miserable experience for your users. You can have the worlds’ best looking app with the nicest user-interface ever, but if it runs horribly on most visitors machines or phones then you’ve done your end users a massive disservice.

I contend that the browser as a web application programming environment should be treated as its own operating system with its own well defined dependencies. If you have a basic understanding of how these dependencies work, you’ll be able to build better, more stable, faster applications.

We are constrained in what we can build because browsers provide a finite environment in which to play in. To make things even more fun and challenging, in just the last five years we have gained access to some very powerful tools to build even more complex applications, such as Microsoft’s Silverlight API, and Adobe’s Flex/ActionScript API. Now we can build applications with very rich graphics in days or weeks that would have taken many months or even years before these tools became available. And, web applications until only recently gained the ability to semi-directly interact with the operating system to perform operations such as save or retrieve files from local hard drives. In the ‘dark ages’ we had to bounce files off a proxy server before being able to download them to the local machine. How we interact with the local machine is ultimately controlled by what the browser will allow.

The browser sandbox

Browsers provide us with a well-defined sandbox in which our apps can run, and from a developer’s perspective it includes the following:

  • A JavaScript engine
  • An HTML parser
  • User Interface rendering engine
  • Add-ins/Plug-ins (e.g. Flash Player, Silverlight, etc)
  • Cache space (includes cookies and local stores like in FlashPlayer)
  • Access to the internet
  • Access to local resources

It’s also important note, and if you’ve been building web apps for a while now you’ll know, that browser vendors don’t implement the various proposed standards exactly the same. For example, Internet Explorer may display a certain CSS tag different. Here’s an interesting comparison chart.

What about hardware?

I’m also not saying we don’t need to pay attention to the underlying operating system. In fact, we absolutely do need to pay attention to the following. However, we interact with them only indirectly, and because of that we tend to forget just how important they are:

  • CPU
  • Memory
  • Graphics card
  • Internet connection

Mobile devices are a great example. Mobile devices are getting more powerful all the time, but when they try and chug through a fully decked out web page, it takes them longer than a typical desktop or laptop. I’ve had developers tell me an app that’s running slow on everyone else’s machine was running just fine on theirs. What the developer forgot was he had the latest, greatest, hottest laptop out there with 8 GB’s of memory and an excellent internet connection! By way of example, I posted a screenshot at the bottom of this post of another website that even my quad-core laptop used between 50 – 80% of its resources to  load the page.

Simple Tests

Here are some simple tests to tell if you web app is a good one that will meet the needs of your end users:

  1. How much CPU does it consume? Test it on a moderately configured machine, typical of what your users might have.
  2. How much memory does it use? And, how much memory over time? Browsers can be notoriously leaky, but your program may be contributing to it.
  3. Is everything in the correct locations in the user interface at various common browser sizes? (e.g. 1024×768, 1280×800, etc.)
  4. Does it cause temporary slowdowns or lockups?
  5. Does it crash the browser or browser panel?
  6. Does key functionality and layout work consistently across the major browsers?
  7. Does your app work consistently across all the devices you wish to support, including mobile?

A Few References

Here are a few articles and websites for that are handy to have as references:

CPU Usage loading web site with quad-core laptop
Loading an unnamed website using a quad-core laptop