Major revision suggestion for styling in Mendix apps based on SASS modules - Mendix Forum

Major revision suggestion for styling in Mendix apps based on SASS modules


Allow for editing SASS files in the Mendix modeler itself. And compile them there too in real time based on Calypso.

That way SASS definitions can become project independent. As definitions can be moved towards their own namespaces.

For example my namespace becomes

@use "my-client-apps-namespace" as client;

.element {
  background-color: client.$body-bg;
  @include client.float-left;

 but one could also easily use the @forward component specific styles sass functions and mixins to other modules and components

For example I could forward mixins, styles and functions from button to my modal pop-ups or data-grid.

The modular approach would also allow for not including styles for elements that are not being used. Like right now Mendix comes with tons of styling variants in

listviews/template grid etc, and then you get custom sass which overwrites these adding on top of the specificity. And pretty much resulting in a 2MB css file.



2 answers

Hi Jason,

just to give some feedback on your feedback:

  1. Mixins are a little difficult to work with, but when moving the SASS editor inside Mendix, it could easily auto-complete or suggest mixins that are available based on the name-spaces added. This idea only should make it more accessible because now mixins are distributed on several layers.
  2. Other benefits are no more conflicts in styling as the changes can be handled as other parts of Mendix code.
  3. Mendix styling should be bare minimum, no paddings, no margins, just a css reset and normalization for cross browser stuffs. From that point all should be adjusted by adding new namespaces like AtlasUI.webstore, AtlasUI.accounts or CompanyStyling. Plus currently the direction chosen by Mendix by defining selectable styles for a widget / component only introduces a bigger class & interface hell inside Mendix. Now we get components with 80 classes rendered on them, one for each selectable option.
  4. It's the result of trying to implement everything for users, whereas there is no design solution that fits all. And by trying to cover as many options as possible in the "default” styling package it automatically creates bloated stylesheets. 

Hi Marnix,

I’m going to break your post down a bit, cause there’s a bit to unpack.

  1. Creating efficient and modulair workflow.
  2. Mendix owned Sass
  3. Creating efficient workflow without having to overwrite multiple !importants and other values.
  4. having a fast and small css package.


1 I think working with mixins is great in a small team, but its hard to keep all people (with different skill levels) aligned, let alone developers that sometimes want to mess around in the sass.

2 Having Sass in mendix, would solve some sync issues (multi app landscape). Also makes it easier for devs to mess around in it, not sure if this is good or bad, but creates some opportunities.

3 I have to admit that Mendix Legacy css is a bit of a mess, not sure if this is the way to solve it though, I’d rather see a cleanup of the legacy css

4 this is a bit of a result of the legacy mess, small css is always good :D