@wavetro, the Babylon GUI system is a stand-alone system build for the engine that takes inspiration from CSS, but is not a direct re-implementation of CSS. So there will be things like rem that have not been implemented into Babylon GUI. That does not mean they will never be there if there is enough call for them to be developed. And there’s nothing stopping anyone from contributing to the Babylon GUI system to add features like this before the core team can devote resources to them. But I can’t say for sure when a feature like rem would be added to our production schedule. But we do want to improve the responsiveness of Babylon GUI as we develop out the GUI Editor.
For your question about buttons and flexbox, I would agree with @mawa that the best way for now is to set your button size with pixels, and then the grid cells with percentages. This should prevent you needing to customize quite so much based on screen. It may not be exactly what you are used to with CSS, but that is the best way to work in the system as it stands today.
For break points, you have two options. GUI Editor itself is just a graphical editor for Babylon GUI code so you don’t need to write the code for all of your controls yourself. In that sense, you still need a scene to get the most out of your GUI such as behaviors and state change. You can approach updating your GUI based on device in a couple of ways. One would be to swap your ADT based on the screen proportions so that you are serving a portrait layout for portrait-oriented screens and a landscape layout for anything landscape-oriented. The other would be hiding/showing controls that belong to one orientation or the other depending on the screen orientation.
We have an example of the latter in the Space Pirates demo GUI Framework and you can see the in-game menu using that ratio where we check the aspect ratio of the screen and then either show or hide specific controls based on that check. In this case, we are generating all of the controls in code, but if you are using the GUI Editor, you would just use that check to enable or disable controls you have already created in your ADT. I would just use a name prefix or suffix to generate an array of all controls that need to be changed with the screen ratio such as controlName_land and controlName_port. Getting the control names and then splitting the string by the _ is an easy way to sort them into arrays.
You could also have parameters that change based on the screen orientation, maybe your grid has fewer columns or maybe your button sizes change. But changing individual parameters based on screen ratio would be very tedious. If you don’t want to load and swap multiple ADTs, you can create different control hierarchies for each screen orientation and then just enable/disable them based on the screen ratio.
This would be the same as if you were showing/hiding new UI based on user interaction like clicking a button. In this case, however, it would be driven by the engine updating the ADT based on screen width divided by screen height.
I hope this helps, but please feel free to ping back if you have more questions.