Cells And Responsive Layouts in Frontastic

Cells in the backstage editor can be used by Frontend Managers to influence how tastics are displayed in the Frontend. Frontastic provides you with a set of predefined cells and breakpoints. The available cells and breakpoints are not yet extensible, but will be.

The breakpoints relate to target devices. Currently we support "mobile", "tablet" and "desktop" as the three breakpoints for Fontend Managers. These breakpoints primarily enable Frontend Managers to hide / show entire cells or tastics only on certain devices. You can of course use more breakpoints in your CSS to implement more specific behaviour.

There are a number of different cells which behave in certain way by by default:

Cell Mobile Tablet Desktop CSS-Class
1/1 1/1 1/1 1/1 o-cell--12
1/2 1/1 1/2 1/2 o-cell--6
1/3 1/1 1/3 1/3 o-cell--4
2/3 1/1 2/3 2/3 o-cell--8
1/4 1/2 1/4 1/4 o-cell--3
1/6 1/1 1/3 1/6 o-cell--2

This is the default behaviour implemented by Frontastic. You can, of course, change this bahaviour by using different CSS for certain cell types, like:

.o-cell--2, .o-cell--1\/6 {
    @media (min-width: $layout-breakpoint-l) {
        // Make the 1/6 cell span 50% on tablet
        grid-column: span 6;
    @media (min-width: $layout-breakpoint-xl) {
        // Make the 1/6 cell span 33% on desktop
        grid-column: span 4;

Inside the editor in backstage there is a selector for the target device / breakpoint you are woring on on top right, but we are using this one only to illustrate which tastics and cells are active on this device. We do not adapt the grid inside the editor. We do not adapt the grid because the displaying of cells can be modified inside the CSS in your catwalk instance. This would then confuse the Frontend Manager. They are asked to use the real preview with a correct target device.

Additional Layout Information

We do not allow to specify additional layout information inside backstage for multiple reasons.

Side Effects Are Hard To See

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 behaviour for all target devices. We assume that this would break layouts more often then it would allow to fix layouts.

We say that tastics nad 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 there are basically two options for you:

  • Create a spacer tastic

A simple space tastic could have configuration options like Space: {s, m, l} and implement a spacing according to this. This would allow the developer to implement this in a stable way and the content editor to apply additional spacing.

  • Create a boxing tasic

Frontastic supports tastics in tastics and all tastics can receive any options. Thus you can create a tastic which receives options for margins and paddings and cobntains the actual tastic which should be displayed. We strongly recommend to not do this, while it is possible.

Pages Should Survice Layout Refactorings

The idea behind page configurations in Backstage is that they survice visual refactorings which is why you should not 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 re-configured after any layout changes which affect the platform.