App Styling Basics: Where to Start with Look and Feel

Start your styling engines!

When deploying your first Mendix application, you’ve probably done a whole lot already, including defining domain models, microflows, security, integrations and much more. What hasn’t happened yet, formally, is attending to the look and feel of your application.

That’s where the styling part comes in. You see, there’s a whole lot to say about styling, and the usability of your application itself, and by extension the entire design. And in time, we’ll get to that. But for this post, I want to focus on one simple question: where do we start if we want to change the look and feel of the application?

Press play to start

If there’s one thing I always challenge when working with our partners and customers, it is the assumption that you’re close to finished when the errors are gone and you press that magical deploy button. You see, the deployment means the technical aspects are all in place. What has not been given any attention yet is the entire look and feel of your application. So pressing “play” is not where you finish but where you start styling your application and shaping it into what you ultimately want it to be.

Build and browse

Within the Business Modeler, you’ve built your pages and layouts and put all sorts of relevant content on them. However, what you’re building in the Modeler is all about construction. The way the application looks is ultimately defined by the channel through which it’s accessed – in this case a web browser. That means that, in order to adjust the way it looks, you end up working with CSS files, looking into the html when needed to get the desired end result. And if you don’t like the html you have now, or if it doesn’t work the way you want to, what’s stopping you from adjusting the pages themselves in the Modeler again? It really is that simple of a concept.

Mendix and CSS files

By default, your application will have an index.html file where the entire application is loaded. When you’re navigating to the application, this is the file you’re looking at. It’s almost empty when you open it up; yet when you look at it in the browser, you’ll see a whole lot of html code. This is what Mendix has created for you, based on your choices in the Modeler. There’s a datagrid with its appropriate code, a navigation bar – anything you’ve chosen in the Modeler has its html and its place. And using layouts you can define and designate these positions at will.

The look of all these elements is being defined through a number of CSS files. You’ll see a bootstrap theme, which is a basic version of bootstrap that defines certain defaults for Mendix to work with. There’s also always an mxui.css file that defines the core components of the Mendix elements, making sure tab containers are, well, tab containers for instance.

Then comes the theme.css file. This file is all yours to change and adjust. Leaving the other files intact, you can be sure that the default Mendix framework will look and behave properly with any adjustment you want added on top of it through the theme.css file. And the beauty of it is that you can adjust absolutely everything, if you want to. You can put the theme.css file into the theme/css folder of your project and Mendix will automatically deploy this file with your next deployment.

Understanding the basics

The fact that changing the CSS file can adjust the entire interface and look and feel makes it a very powerful thing. Add that power to the ease with which you’ve probably modelled hundreds of pages already and you might soon feel overwhelmed by the possibilities. Making adjustments to your theme.css file can make applications look different on a page, look different on all the elements the application consists of, and at times things just don’t seem to listen. But never worry, as there’s logic and opportunity in the way the html and CSS work together – and for Mendix, this is no different.

What if you want to style a button, for instance? Well, typing a dot and then the class for the button adjusts all buttons accordingly. So all you need to say, in the theme.css, is .btn – look green! Its syntax is quite simple, too:

Ok, great, now all buttons are green. But perhaps that effect wasn’t the desired one and you only wanted to style the buttons in the datagrid, not all of them? Well, all you need to do is be as specific as you need to be. In this case, you need to define that only the .btn elements within the html that are positioned within a datagrid element appear green. In that case, you need to look at the html to see what a datagrid is called. Luckily, Mendix has got your back and calls its datagrid a logical .mx-datagrid . This means that the definition changes into .mx-datagrid .btn and all of a sudden, you’re good to go.

But wait, actually, there was this scenario where I just wanted this one datagrid to have green buttons, not all datagrids. How do we address this specific datagrid and not all the others? If they are all the same in the html output, don’t we need to make sure that there’s a way for us to address this specific one?

This is where classes come in. In the Modeler, you can assign classes to most things you can select. If you select the datagrid, the properties panel in the Modeler will have a place where you can enter the class itself. Call the datagrid something that makes sense so you’ll be able to find it later. In this case, I’ll call it greenGrid. Note that you don’t need to add the dots; that’s only for the CSS files so they’ll understand you’re talking about classes. You also don’t need spaces, as a space will end up being two classes; assigning “green grid” as a class will add both the green and grid classes separately. You are free to do so when needed, but for now, we’ll stick to this single class.

With the class added, we can redeploy the application and take a look at the output in the browser. When inspecting the code, you can see the class assigned to the datagrid element itself. Now, we can address that class and tell all those buttons to appear green, but only when they’re a part of an element that has this name. The code, you guessed it, remains similar, because we’re doing the exact same thing.

By saying that we want .greenGrid .btn to look green, only the buttons within the element called greenGrid will become green. The beauty of this way of working is that there’s now enormous potential for consistency and recyclability. The class isn’t a standalone thing, but can be reused where and when desired. So assigning another element with the greenGrid class turns all buttons within that element green, even though you only needed to define this once.