Back to News for Developers

Supporting Multiple Screen Formats in HTML5

September 10, 2012ByTeemu Ikonen

Teemu Ikonen is the CTO of NonStop Games. In this post, he discusses a model for writing a single HTML template with minimum redundant CSS for multidevice HTML5 pages.

One potential way to support multiple screen formats, like mobile, tablet and desktop, is to write separate HTML documents for each device class, and use custom CSS tailored to each screen size. You could also use a flexible templating engine to build different HTML documents, but these nearly always require complex if-else logic and often lead to messy spaghetti templates and redundant CSS. It also makes deployment automation, such as CSS minification, much more difficult.

NonStop Games has developed a simple model that reduces HTML code and redundant CSS significantly. In all multiplatform games, we use a global .mobile, .tablet or .desktop class. This is similar to CSS media queries, but the CSS becomes far easier to maintain.

This method can be used with static and dynamic HTML pages, but works best on games where a single document is loaded once and usually contains all possible game views and dialogs.

For example, suppose you want to create a simple dialog that should have different dimensions and position depending on which platform is displaying it.

One solution would be to make three different dialogs and apply different CSS to each. This makes the code harder to maintain, slows and selectors, and increases load and parsing time.


    <div class="dialog-desktop">

    <div class="dialog-tablet">

    <div class="dialog-mobile">


What we do instead is add a global device type class (e.g desktop for desktop) to the HTML body tag at load time. This reduces the document to:

<body class="desktop">

    <div class="dialog">


The class can be set either by a backend templating engine or by simple client side JavaScript.

Next, we define a common style for the dialog that is shared by all platforms.


Device specific styles (in the same CSS file) are defined like this:

.desktop .dialog ,
    .tablet .dialog 

This drastically cuts development time, as adjustments to a specific device are fast to make without it affecting any current layout/functionality. And the game code knows nothing about this.

Note that our best practice is to keep all game CSS in single file, as code, HTML and CSS are often so tightly coupled that separating CSS to different modules (such as layout, theme, ..) becomes a maintenance disaster in a fast-moving development cycle.

This model can also be extended to portrait and and landscape styles, but in our experience, it's not worth to try to support both in mobile game implementations.

When code is structured like this, its also much easier to build stand-alone test pages that can be used to tweak the game views as static HTML pages without reloading the whole game after every change. This is not so much of a problem in desktop, but helps tremendously in mobile and tablets that do not have online CSS debuggers like Firebug.

An example page can be viewed here.