The grid system

Basic layout

The foundation of our grid is a 20px/60px system of left-aligned gutters and columns. It starts with the gutter on the left side, which is directly leaning onto VS Code's File Browser column, and it keeps going from there alternating columns and grids into infinity on the right side (or, if infinity is impossible, simply to the end of the user's viewport, that will also be sufficient).

Since user's viewport is of unpredictable size, more often than not, the right side of the grid will inevitably be cut off at some non-ideal place.

Sizing and padding

Since the grid is left aligned inside the available viewport, and on the right side it will nearly always be cut at a strange position, the grid itself is sometimes used as a sizing tool, and a padding tool, rather than as a direct schematics where to place things on screen. We should use the ideal grid placement, the one ending with right side gutter as a design template, knowing that the right side might not be always as neatly positioned as in the ideal scenario.

Construction rules

On this ideal grid we can have left and right aligned items, usually various panels (Property panel, Outline, Pages, ...). They should utilise their respective gutter first, and then use as much grid space as they need to solve their particular problem. In total this means that fixed-pixel panels can be of the following sizes

1 column panel: 80px (starting gutter, plus one column),
2 column panel: 160px,
3 column panel: 240px,
And they keep growing in the increments of 80 pixels.

Various objects can then be placed on the grid itself, left aligned in the available space. Here's for example a 2 column left side panel, with some tiles stacked on the grid itself. Note that the third tile did not have enough space in the grid to be rendered on the far right side, so it stacked down in the next available space.

In such tile construction case, there should be at least 20px padding (one gutter size) on the right side of the viewport, so that the tiles (or any such objects) don't touch the edge of the screen. For example, if the viewport ends right at the edge of one column, thus there is no gutter on the right side, this should also trigger the tile to go into next available space below.

Realistic scenario

With all this combined, here's a possible realistic scenario. Note the following:

The viewport is not ideal, and it stops mid-column on the right side,
Right side panel is still correctly scaled to 3 columns width (plus 1 gutter, of course), but since the viewport is not ideal, it also ends mid column,
There's a 100% wide (rather than pixel based wide) purple banner at the top, which is spaced 20px from all sides, including from the right side panel. Being % based, rather than pixel based, and being in a non-ideal viewport, it also ends in a mid-column position, but at least all of the margins from the outside are gutter based,
There are three tiles, and they stack correctly, with the third tile dropping into the second row,
There's an imaginary popup placed centre/centre in the screen. Since the viewport is not perfect, it too is positioned off grid, however, the size of this popup is grid based (in this case, it's a 5-column popup)

General utilisation

We should use the grid to construct major elements on screen, and to space them accordingly. However, if situation doesn't allow it, we should not enforce this grid to the end of the world. Additionally, the grid should be used for all major construction blocks, and if possible for inner construction within those blocks as well. However, in the case of inner construction, the 20/60 grid might be a bit too clunky, therefore it should not be enforced.

Page tree