I want to get rid of any custom css in my fritz2 project, but could not find a way to do "transform: translate(-50%, 0%)" in the fritz2 styling universe. Is there a way to do that yet?

Have you tried css("your css as atring") builder?

Ah, works. That was not on my horizon. Thanks! 🙂 But now. How can I make it breakpoints dependend like the other position arguments?

position(
sm = { fixed {
  left { "50%" }
  *** I WANT TO HAVE IT HERE ***
} },
md = { fixed { left { none } } }
)

I wasn't aware of responsive option for that! I guess we both learned something new today 😄

Cool. 🙂 👍

As CSS is a complex beast, we have no abstractions for rather complex stuff like animations and so on. So as you have figured out yourself, the universal ``css`` function comes to the rescue, which enables one to add native CSS code into our DSL. It is definitly out of our scope and capabilities to express all this stuff directly within our DSL. Currently our approach towards responsive design is to apply breakpoints within styling functions, so if you need to define different CSS aspects for different target devices, you have to define the behaviour within each CSS function. All our DSL functions should have an overloaded variant, that enables definitions for breakpoints. If you discover a function that does not support applying breakpoints yet, please file an issue! We have allready discussed, whether it would make sense to offer an alternative approach to group the breakpoints at the first level and define all the CSS functions on the second level in order to improve readability. This might be good for rather "symmetric" definitions, where every aspect is defined for each different breakpoint. To give you an imaginary example, of how this could look like:

// somehow within a styling context - NOT A WORKING EXAMPLE, just a sketch ;-)
sm {
    position { fixed { left { "50%" } } }
    css("transform: translate(-50%, 0%)")}
md {
    position { fixed { left { none } } }
    css("transform: translate(0%, 0%)")
}

On the other hand one might argue, that with the current approach you clearly can discover for each function separately, how it behaves for different breakpoints. But your solution is the currently supported one and quite useable imho.

I personally prefer breakpoints per definition (current approach) as it allows for selective universal definitions (applicable to all breakpoints). Also it's easier to follow, since all relevant breakpoint declarations get naturally grouped.