Cells and responsive layouts

Frontastic provides you with a set of predefined cells and breakpoints. Cells in the Frontastic Editor can be used by frontend managers to influence how Tastics are displayed in the frontend.

The breakpoints relate to target devices. We currently support mobile, tablet, and desktop as the three breakpoints for frontend managers. These breakpoints primarily enable Frontend Managers to hide or show entire cells or Tastics on certain devices. You can use more breakpoints in your CSS to implement more specific behavior.

Inside the Editor, there's a selector for the target device/breakpoint you're working on the top right of your screen, but this is only to illustrate which Tastics and cells are active on this device. We don't adapt the grid inside the Editor because the displaying of cells can be modified inside the CSS in your Catwalk instance and this would then confuse your Frontend Manager. They're asked to use the real preview with a correct target device.

JavaScript based breakpoints

minWidth breakpoints for the three main devices must be added to your project.yml configuration file so that they're loaded with Server Side Rendering. This also allows for better performance on your site.

To add this, just paste the below into the data-node section within your project.yml file in your config folder:

      - identifier: mobile
        name: Mobile
        userAgentRegexp: (Android|webOS|iPhone|iPod|BlackBerry|Windows Phone)
        userAgentRegexpModifiers: i
      - identifier: tablet
        name: Tablet
        userAgentRegexp: iPad
        userAgentRegexpModifiers: i
        minWidth: 768
      - identifier: desktop
        name: Desktop
        minWidth: 1025

You can define any other breakpoint you want within CSS but the above breakpoints must be in JavaScript.

Additional layout information

We don't allow you to specify any additional layout information inside the Frontastic Editor for multiple reasons. If we start allowing people to specify CSS values like margins and paddings inside the Editor, they would need to really verify their changes on every device, and CSS developers know how hard it can be to create a sensible behavior for all target devices. We assume that this would break layouts more often than it would allow fixing layouts.

We say that Tastics and Cells should be created in a way that they look great at least 90% of the time. If you really need some additional space somewhere that your Frontend Manager can easily apply, you could create a spacer Tastic that could have configuration options like Space: {s, m, l} and you can then implement a spacing to this in a more stable way.

Pages should survive layout refactorings

The idea behind page configurations in the Frontastic Editor is that they survive visual refactorings which is why you shouldn't give the Frontend Manager the possibility to change concrete layout values. If Tastics have a concrete padding or margin assigned (or any other CSS option) all these Tastics will have to be reconfigured after any layout changes which affect the platform. For this reason, we highly recommend avoiding margins for Tastics.

‹ Back to article list

Next article ›

Server Side Rendering (SSR)

Still need help? Contact us Contact us