Approaches

Build our own grid configurator

This would involve both the front end builder tool and the output that it produces.

We could inject client-side generated grid stylesheets into the DOM. The stylesheets would be created at render time.

We might also create a server-side callback that returns a generated CSS file that can be cached. I’m trying to avoid writing files to the server. Is this a legitimate concern?

Hard-code default grids and provide an import for extension

If we want to avoid the problem of generating grid CSS dynamically, we can simply hard-code several options into the tool. Then we would either allow for users to import a grid CSS (I’m not sure how this would work in terms of mapping classes to HTML) or provide plugin access to exend that basic set.

Establish a hard requirement to a third party system to extend the defaults.

For instance, we could build a semantic grid mapping using SASS and Susy (not sure how this would work technically yet). Or we could say that all grid CSS must be produced through a tool like Gridpak.

Comments

mustanggb’s picture

mustanggb commented

Why would we need client side stylesheets rendered at runtime?
Can we not just generate the stylesheets when the layout is created?

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

We could inject client-side generated grid stylesheets into the DOM. The stylesheets would be created at render time.

I think one of our primary goals is to not require JS at all for the presentation of the layout, so this seems like a no-go? (I assume "client-side generated grid stylesheets" means JS generated).

We might also create a server-side callback that returns a generated CSS file that can be cached. I’m trying to avoid writing files to the server. Is this a legitimate concern?

We should try our best to generate the CSS file on the server. This makes it compatible for minification, results in better performance for subsequent page loads, etc. The more breakpoints/columns there are, the more the CSS will be, and including that verbatim on all page loads sounds like a bad idea.

Hard-code default grids and provide an import for extension

This is already happening. I've been working on integrating the grids with ctools exportables for import/export exactly so that people can ship with default layouts for their sites (which require them to be able to ship with default grids, etc). We can use this system to ship some default grids as well as to allow people to manually add new ones and ship grids with their modules.

The real question is how we communicate properties of the grid inbetween different layers. If we generate our own grid system, we know column numbers, etc. to use in the editor; and we know which css classes to apply. The best in generating our own CSS is that we can generate with the region class names directly, so we don't need to inject all the breakpoint/width specific classes, making our markup more semantic. If some arbitrary grid CSS is used, we cannot even tell the grid classes to use, or we'll need to put serious rules on how the CSS should be structured.