Why Sugar.css grid is so revolutionary?

In this article, I want to introduce you to a novel CSS grid concept that differs significantly from what we're accustomed to. You can witness it in action within the Sugar.css documentation and delve into its code within the Sugar repository.

The Traditional Approach of Bootstrap-like Grids

For ages, we've relied on grids from libraries such as Bootstrap or Tailwind. Despite transitions from percentages to flex and later to grid, little has changed over the years. Both Bootstrap and Tailwind, along with many others, adhere to the same core principles:

• A predetermined number of columns in a container (usually 12).
• Generation of an extensive array of classes applied to cells to determine their column occupancy or offset.
• Adapting the grid layout based on window width through the application of different sets of classes, ensuring responsiveness across various devices.

However, this approach comes with several drawbacks:

1. A fixed number of columns necessitates the use of media queries. The presence of media queries is particularly problematic for component-based front-end frameworks. Components should be agnostic to whether they occupy the full screen width or a mere 200 pixels. Yet, the width of the component is pivotal for effectively setting up cell classes in a responsive manner. This issue could potentially be addressed by transitioning from media queries to container queries.
2. To ensure optimal responsiveness, one must define a cell class for every breakpoint, such as col-sm-12 col-md-6 col-lg-4 col-xl-3. It results in lot of HTML markup, which is hard to read.
3. The generation of a vast number of classes to cover all scenarios. While this can be partially mitigated by CSS cleansing (the automated removal of unused classes), it is not ideal for larger projects where most classes are already in use.

The New Concept Introduced in the Sugar Grid

The core principles of the Sugar grid diverge significantly:

• The container has no preset column count.
• Users specify the optimal width of a column, and once a new column fits within the container, it is automatically added.
• Instead of classes, CSS variables like --span:2 are utilised to span cells across multiple columns, eliminating the need for class generation.
• Another CSS variable can adjust the span count of a cell based on different container sizes, such as --span-6:3. This means that if at least 6 columns fit within a container, the cell should span across 3 columns instead of the default --span value.

This approach seemingly resolves all the drawbacks associated with traditional grids.

We can also observe that this appears to be an intrinsic design, a design pattern that seems to be the holy grail after traditional responsive design. The distinction between intrinsic and responsive designs lies in the fact that the former does not rely on media queries and is instead driven by content.

While I would like to categorise the Sugar grid as intrinsic, it would only be partially accurate. It utilises container queries under the hood, although they are not essential for core functionality. Presently, their necessity arises due to a peculiar behavior of spans in the grid. For instance, if a grid has two columns but one of its cells spans three, the grid becomes disrupted, causing content overflow. Ideally, it should automatically adjust to a span of two, but this functionality is currently lacking. Perhaps this issue will be resolved in future iterations of CSS.

Advantages of the Sugar Grid

The results are staggering: a significant reduction in CSS. Sugar's grid comprises approximately 150 lines of code, compared to Bootstrap's 1500 lines. It's about 10 times smaller.
It also eliminates the need for an excessive number of classes applied to cells in HTML. In scenarios like cards in a grid container, you simply apply style="--span:2" to the container itself, and you're done. The span definition is passed from the container to the cells. If needed, you can still overwrite it on a cell level.
For more complex situations, syntax like --span:2; --span-6:3; span-12:6 can be used, although such cases are rare and mostly pertain to specifying page or large component layouts.

Disadvantages of the Sugar Grid

It is different! It requires new way of thinking. It employs modern CSS features like container queries, and careful consideration is necessary regarding its usage. Since there are no breakpoints, aligning with traditional designers who insist on pixel-perfect designs with specific breakpoints might pose a challenge. It requires a shift in their mindset.
It introduces an unnecessary div wrapper between the container definition and cells, primarily as a workaround for a Safari bug. Once resolved, this wrapper will be eliminated.

Conclusion

Is the Sugar grid revolutionary? I believe it is, albeit it requires some time for widespread adoption. The Sugar grid is rooted in the concept of intrinsic design, even if it's not a pure implementation.
Sugar offers additional features like offsets and specialised grid behaviours for layouts. However, the focus of this article is to highlight a new direction in which CSS grid "frameworks" can evolve.
Perhaps in the future, grids like Sugar will be further simplified. Currently, the main hindrances to such simplification are various bugs related to container queries (subgrids, Safari repeat column template).

If you haven't already, you should definitely give it a try!