Initial Situation

Villeroy & Boch is a producer and merchant of high quality porcelain. Both wholesalers as well as customers are the target audience of Villeroy & Boch, addressed via a Magento multistore, translated in several languages. The existing template has been established two years ago. At that time, responsive design and mobile displays were not considered.

Objective / Requirements

Since the percentage of mobile traffic is constantly growing, the design relaunch’s objective is to provide an improved experience for these devices. In addition to a fresh, mobile optimized frontend, new shop features are planned.


Project’s Setup

Automated Workflow

For projects of this size, we use a so called Boilerplate for a standardized frontend development more and more often. In this case, Grunt is certainly the setup’s core. It is a JavaScript based task runner, built on the popular framework Node.js. The big community provides numerous extensions, which can easily be integrated in Grunt to adjust the workflow to your own needs.
Grunt makes sure that via Bower managed dependencies are wedded to the actual source code. It compiles LESS to CSS, compresses it, merges JavaScripts and minimises them, too.

Furthermore, we generate a sprite, based on single SVG files and performed an image optimisation if necessary.

All of this happens either directed by the developer via the command line or in the background organised by a File Watcher, that triggers predefined tasks as soon as the according files have changed.

Directory Structure

In general, we create theme directories based on Magento best practices. In addition, we prefer to have only source code in our repository. Dependencies like frameworks, etc. (e.g. Bootstrap) are not versioned. These are managed in a separate Vendor directory in Bower. After the compilation, these sources are no longer necessary; they are not uploaded to the live server.

In the skin/ directory, there is an additional distribution layer, containing all styles and scripts. These are versioned.

Modular Style Sheets

A lot of CSS code comes along with projects of this size. Using a preprocessor (LESS), files can be organised in any order. The exact structure can be built according to the developer’s / team’s taste. For us, sorting styles in three categories proved to be reasonable and practical:

  • Generic Styles
  • Magento Template
  • Styles referring to external modules, e.g. from third parties

Under generic styles, we sum up what is used globally. Next to the basic Bootstrap framework (which – to be precise – is only referenced here from the Vendor directory), general teaser definitions, styles for links, icons, typography, etc. belong to this category.

But the main part is accounted for by styles belonging to the Magento templates. Personally, I am no fan of spaghetti code, so whenever possible I try to keep files as small as possible. It proved to make sense to use Magento’s logic for its own modules and blocks for styles, too. As a result, we created the following directory structure:

The modules/ directory contains styles of further (external) dependencies. E.g. slideshow plugins, etc.

The order of elements in compiled CSS is controlled by the central styles.less.

The structure is quite straight-forward and scalable. It takes a bit of overcoming and thinking ahead, when you are used to work with fewer, bigger files.

Disposable CSS

Yeah, we have a modular development environment, our dependencies and frameworks are separated from our work resources, we use a great preprocessor – nothing can stop us, right?! Right, nothing!

At this point the dark side of the „force“ comes into view. We shall never forget what the little gizmos are doing in the background, while we sit here, drinking coffee, throwing around with Mixins and Co.

The mood grows sober quite fast as soon as we start using complex frameworks in combination with LESS, etc. and look at the generated style sheets’ file sizes. Careless or unthoughtful usage can quickly lead to files in the region of several hundred kilobytes or more (even if compressed), which are performance killers.

You can find a number of good articles about this topic online, therefore, I’ll limit myself to a few basic principles which should be kept in mind at all times during the development:

  • Whenever possible, refrain from integrating precompiled or “complete” frameworks. Only add those parts to the process which are actually needed.
  • Reference imports (in your framework, too) if possible.
  • Extend classes instead of using Mixins
  • Make use of reasonable media queries

Bootstrap in Use

We use Bootstrap in its version 3.x and solely integrate the components we need. We primarily use the very flexible grid system, the responsive parts, as well as a few basic styles and mixins as a basis for our work. When it comes to interactive elements, we focus on modals.

Considering the way to employ Bootstrap, we try to keep the balance between a markup that is as semantic as possible on the one hand and the best possible performance on the other hand.

Especially for complex templates, as it is the case for a Magento project, semantic HTML and self explanatory selectors are important factors for the project’s clarity and extendability – think of your team mates! For example, a “simple” use of grid classes such as .col-sm-6 directly inside the markup is the most performant solution but it is no option for us.

If you decide to assign framework functionalities via the preprocessor to the according classes as we did, you should be aware of the considerable overhead in the resulting style sheet – and don’t forget about the principles stated above!


We can employ the Bootstrap grid in several ways. Both DIV elements #red and #green have the same characteristics inside the grid.

The HTML markup:


In order to understand what happens in case of a green DIV, take a look at the corresponding Mixin from Bootstrap:

For the rest of the breakpoints, code exists accordingly. It is easy to see how much overhead is created here.

I will not take sides on this matter – both ways are okay. It is up to the individual developer to choose what is best for his or her particular case. In practice we usually are somewhere in between the extremes.


Most of the time, we rely on the quite simple and robust methodology that forms the basis of Bootstrap. Included are a few useful variables and Mixins to define breakpoints and their use in markup and CSS. You don’t have to reinvent the wheel.

In this project, the header is particularly interesting. Depending on the different displays, there is too much going on to solely rely on simple media queries in CSS. We cannot avoid to move, create/remove or change numerous elements in the DOM during the runtime:

These are the most important but not all states.

JavaScript to the Rescue!

So far, so good. At this point, I’d like to mention a small but nice library which is a great tool for scenarios like this one. Using enquire.js we can define breakpoints analogous to CSS which enable you to execute any code you like in their dependencies. The library itself has no dependencies, weighs only 0.8k, offers the obligatory “match” and “unmatch” events, and even features the option to execute an event only once, and to delay it until the condition is met the first time.

The usefulness of this feature is demonstrated by the navigation: the navigation concept for mobile devices differs a lot from the desktops’ concept; a few lines of CSS will not do. We need a separate object in the DOM and many additional scripts, etc.

Since all of this only happens on mobile devices, we do not want to run the corresponding JavaScript on desktops, and vice versa.

Furthermore, we can enter globally available, device dependent variables for use in other scripts.

Retina & Co.

It was important to our customer to reward users of devices with high definition displays. Anyone with a pixel density of at least twice the usual value (e.g. Retina displays), receives the corresponding image file.

In Magento we adjusted all product and listing displays as well as the corresponding teaser widgets.

In the store’s frontend we use HTML5 elements; it’s up to the client (browser) to decide.

An example:

The browser decides which of the given sources to display based on the srcset attribute. Browsers that do not support the source/srcset tag use the img-tag.

Device Dependent Image Formats

The described concept can be extended by several criteria. For the homepage’s teaser, we can display different formats according to the used device and, thereby, offer a kind of layout variation via the image resources.

For devices with a viewport of at least 767px width, the page shows the image in portrait format, smaller devices display a landscape format. Thus, editors and graphic designers have more options to create interesting image sections that fit the device’s display.

This is how it looks like in a browser:

SVG Sprites

In modern web development, sprites are a standard to organise often used graphic elements (usually icons, logos, etc.). The most common file formats are still gif, jpeg and png.

Not quite as common is the use of scalable vector graphics (SVG) and in particular their organisation in sprites.

Which advantages do SVG files have?

As their name suggests, they are not a pixel based but a vector based format. Therefore, they are predestined for the display of icons, logos and similar graphic elements. A lossless scaling in browsers is possible even with a minimal file size.

Furthermore, a SVG file is just text in form of a syntax similar to XML. No matter how the SVG is created (e.g. exported from Adobe Illustrator), it can be changed with an editor and integrated into the development process, versioned, etc. So from a developer’s point of view, this is a great file format.

Within a SVG, it’s possible to assign classes and IDs to paths and layers which then can be styled via CSS. Need I say more about all the possibilities?

A description of the exact implementation in our workflow would be enough for a separate blog post. So I will keep this short. We use grunt-svg-sprite and implement the sprite as well as the icons inline. Parts of the sprite can be referenced with an according syntax via the IDs:

There are still a few things that need to be considered. When it comes to cross-platform implementation, there are still significant differences regarding the support of some features. We also experienced a few hurdles when SVG code contains inline styles. Usually, they could not be overwritten. So in my own opinion you should try to avoid this and remove inline styles in SVG code.


Compared to non-responsive designs, responsive templates require a lot of planning ahead in order to create an excellent user experience for all devices and display types. In this Villeroy & Boch project, the chosen tools and technologies paved the way to build a template which is both easy to maintain and comes with good performance. However, you should always consider each project’s individual requirements and then choose the technologies which fit best.

Sandro Wagner

Autor: Sandro Wagner

As a trained media designer with a strong focus on frontend development and CMS integration, Sandro Wagner has worked for different leading web agencies and clients, both national and international.
At integer_net, he develops frontend designs for Magento stores, holding the corresponding Magento certificate.