Best Practices for Combining Old and New CSS Styling

  • 18 November 2022
  • 2 replies
  • 32 views

Badge

Hello all!

I was looking back through some old custom CSS code and the new way of theming using CSS properties. We have some very custom CSS code that, for example, selects specific widgets or specific pieces of the WebUI, and we would obviously like to keep this custom CSS code while still taking advantage of the new WebUI styling that has come out in the last year.

However, I know recently some updates to WebUI, esp. the new 16-color palette, caused some issues with backward compatibility. Are there best practices for maintaining custom CSS code that may not be affected (e.g. “don’t use custom styling for x kinds of widgets or y kinds of selectors”). I am referencing the post here (

), which mentioned that it should be possible to combine the “old ways” and the “new ways” of doing things. I guess I am just looking for some guidance on the best practices in ways to go about this to ensure forward compatibility.

Edo Nijmeijer 10 days ago

Hello Matt,

Those are very good questions, indeed touching upon decisions that everyone needs to take when choosing their approach to customizing the look of their application(s). And I'm glad you also seem to be considering our new Theming, using our latest set of CSS custom properties.

Although you seem aware of it, let me bring in some details for others reading this:

  • After the community posting you link to, we released the new Theming Options with release 4.85.1, back in April this year.
  • The online documentation can be found at https://documentation.aimms.com/webui/theming.html
  • As mentioned in there, the list of available theming properties (which has been extended once or twice since 4.85.1) is visible, with usage/hints, in a file in your AIMMS installation folder

Potentially disappointing, but that's as far as a list as we can possibly get with the technicalities involved with 'theming'. We have of course looked at numerous applications of several customers to see if we could come up with a real 'cookbook', or a list of best practices. But that has proven pretty difficult: our customers chose quite unique ways to achieve often very specific changes to the UI, influenced by their level of knowledge and the history of their applications.

That is also why we designed the new Theming to work next to the usage of the 'old' custom stylesheet approach. One is not a full replacement of the other, and they offer possibilities that suit a different purpose. Both for AIMMS and for our customers.

So as you mentioned, using custom stylesheets can be complicated and involves the risk of seeing things break between releases. That's because most customers' custom stylesheets rely heavily on very complex css selectors, diving into the structures of our widgets.
And although we try and achieve our enhancements to old and new widgets without disrupting those structures, we cannot always get away with it. We sometimes need to re-order things. Rename them, using different classes or hierarchies. While moving our whole framework into the next phase of its existence, using modern frameworks and techniques, this is happening more and more often. For the benefit of better and faster updates, but sometimes leading to custom css no longer applying like before.

Which is why we 'invented' Theming. Which, for us, is a list of UI-changes that we take the responsibility for maintenance for. Because we control it ourselves, without having to guess what customers have created in their custom stylesheets.

For sure, the modern Theming options are mostly about colors, with the choice of fonts thrown in for good measure. We were (and are) not ready yet to open up all kinds of sizing and spacing, given the ways that can break an application. But since most customers start out with applying their own brand's colors, modern Theming should get most of them in a good looking state, quickly and easily.

And with that, you have the basic answer to the question "What do I use: CSS properties or custom stylesheets?"

  • CSS properties mainly deal with coloring and basic branding.
  • Layout of pages and widgets should be managed using our (custom) Grid Layout options.
  • And everything else is, and always has been, the domain of custom stylesheets...

The latter does indeed involve some uncertainty as to whether your work remains applicable throughout releases. It puts the maintenance work on the customer's end.
Where for Theming, AIMMS is responsible to keep things working, so your buttons remain the desired color with every release and within any context that we can come up with ourselves.

If your custom stylesheets attempts to do complicated changes to layout or coloring, you might wonder if you're not fighting the built-in design and options too much. Maybe a new arrangement of the page can help. Or splitting pages up. Or usage of new(er) widgets you might have overlooked. Less of the custom css is, in my opinion, always better.

Which is why I really would encourage you to post specific questions here in the community, or contact our User Support. They have lots of experience to come up with great solutions, or can access the developers to get things solved differently, either as a bug or a new feature request. We need our customers to tell us what they try to achieve, so we can cater for it, in some way, especially if it serves a bigger audience.

Hope that helps to see how we try and create options for everyone. And would love to see examples and issues posted here in the community, for everyone to learn from.

Best regards,

Edo

p.s. when trying to combine an existing custom stylesheet with the desire to take on new Theming, I would always recommend to start from (almost) scratch:

  • remove/disable all custom css
  • use Theming to bring back the color scheme and then
  • re-apply, in custom css, the remaining changes that are not about colors (with the exception of annotations of course).

The shorter your css selectors are, the better. Keep them the least specific that they still work. We attempt to do the same for the base styling on our end, so customers also have a better time while trying to do so.

And Custom stylesheets of hundreds of lines are just very hard to maintain, with or without our releases being rolled out.

View original

2 replies

Userlevel 4
Badge +3

Hello Matt,

Those are very good questions, indeed touching upon decisions that everyone needs to take when choosing their approach to customizing the look of their application(s). And I'm glad you also seem to be considering our new Theming, using our latest set of CSS custom properties.

Although you seem aware of it, let me bring in some details for others reading this:

  • After the community posting you link to, we released the new Theming Options with release 4.85.1, back in April this year.
  • The online documentation can be found at https://documentation.aimms.com/webui/theming.html
  • As mentioned in there, the list of available theming properties (which has been extended once or twice since 4.85.1) is visible, with usage/hints, in a file in your AIMMS installation folder

Potentially disappointing, but that's as far as a list as we can possibly get with the technicalities involved with 'theming'. We have of course looked at numerous applications of several customers to see if we could come up with a real 'cookbook', or a list of best practices. But that has proven pretty difficult: our customers chose quite unique ways to achieve often very specific changes to the UI, influenced by their level of knowledge and the history of their applications.

That is also why we designed the new Theming to work next to the usage of the 'old' custom stylesheet approach. One is not a full replacement of the other, and they offer possibilities that suit a different purpose. Both for AIMMS and for our customers.

So as you mentioned, using custom stylesheets can be complicated and involves the risk of seeing things break between releases. That's because most customers' custom stylesheets rely heavily on very complex css selectors, diving into the structures of our widgets.
And although we try and achieve our enhancements to old and new widgets without disrupting those structures, we cannot always get away with it. We sometimes need to re-order things. Rename them, using different classes or hierarchies. While moving our whole framework into the next phase of its existence, using modern frameworks and techniques, this is happening more and more often. For the benefit of better and faster updates, but sometimes leading to custom css no longer applying like before.

Which is why we 'invented' Theming. Which, for us, is a list of UI-changes that we take the responsibility for maintenance for. Because we control it ourselves, without having to guess what customers have created in their custom stylesheets.

For sure, the modern Theming options are mostly about colors, with the choice of fonts thrown in for good measure. We were (and are) not ready yet to open up all kinds of sizing and spacing, given the ways that can break an application. But since most customers start out with applying their own brand's colors, modern Theming should get most of them in a good looking state, quickly and easily.

And with that, you have the basic answer to the question "What do I use: CSS properties or custom stylesheets?"

  • CSS properties mainly deal with coloring and basic branding.
  • Layout of pages and widgets should be managed using our (custom) Grid Layout options.
  • And everything else is, and always has been, the domain of custom stylesheets...

The latter does indeed involve some uncertainty as to whether your work remains applicable throughout releases. It puts the maintenance work on the customer's end.
Where for Theming, AIMMS is responsible to keep things working, so your buttons remain the desired color with every release and within any context that we can come up with ourselves.

If your custom stylesheets attempts to do complicated changes to layout or coloring, you might wonder if you're not fighting the built-in design and options too much. Maybe a new arrangement of the page can help. Or splitting pages up. Or usage of new(er) widgets you might have overlooked. Less of the custom css is, in my opinion, always better.

Which is why I really would encourage you to post specific questions here in the community, or contact our User Support. They have lots of experience to come up with great solutions, or can access the developers to get things solved differently, either as a bug or a new feature request. We need our customers to tell us what they try to achieve, so we can cater for it, in some way, especially if it serves a bigger audience.

Hope that helps to see how we try and create options for everyone. And would love to see examples and issues posted here in the community, for everyone to learn from.

Best regards,

Edo

p.s. when trying to combine an existing custom stylesheet with the desire to take on new Theming, I would always recommend to start from (almost) scratch:

  • remove/disable all custom css
  • use Theming to bring back the color scheme and then
  • re-apply, in custom css, the remaining changes that are not about colors (with the exception of annotations of course).

The shorter your css selectors are, the better. Keep them the least specific that they still work. We attempt to do the same for the base styling on our end, so customers also have a better time while trying to do so.

And Custom stylesheets of hundreds of lines are just very hard to maintain, with or without our releases being rolled out.

Badge

Hello Edo!
Thank you for your detailed and helpful response! I think indeed the process you mentioned above will be a good place to start. I will definitely let you know if I have any further questions!

-Matt

Reply


Didn't find what you were looking for? Try searching on our documentation pages:

AIMMS Developer & PRO | AIMMS How-To | AIMMS SC Navigator