Alice Grid Strategy Notes

Alice Proposals for Grid Strategy

Following research completed reviewing seven Grid Systems (see research notes here), these are the following patterns and issues I could discern:

A. All Grid Systems think of their elements in Design Function language:

The elements describe what the Grid does rather than what the content is. The only difference between the (5 CSS frameworks) and the (2 Pre-Process Based Systems) was the use of classes that reveal these design functions. In the case of the Semantic Grid System -- the Grid mechanism is pushed to the pre-processor -- as a variable rather than an outputted class.

B. There are basically 3 main patterns for naming the Sub-Section of Fluid Grids:

1. some varient following Foundation using .(variable).columns

2. some variant following Bootstrap using .span(variable)

3. some adaptation of 960GS using .grid(variable)

I. Major Issues with Existing Patterns

• The .grid pattern is neither semantic to content or specific enough in revealing the design function to be helpful to a novice.

• Of the colunm/span patterns -- both present issues for novice users to understand the logic of a "Fluid Grid Layout" -- using % based measurements.

The Main Point: % based columns, Don't behave like normal columns.

The Foundation method reads more fluidly -- six.columns.end -- which may be friendlier for a novice to read.

However, one key problem with fluid grids is the notion of columns. In reality, when dealing with % and not a static grid designed with PX measurements, the 'column' actually does not behave like a 'column'.

In reality, what Foundation is calling a column is actually a segment. In their System, the page is divided into 12 equal segments -- and must always add up to a total of 12. When you nest items inside of six.columns, your children must add up to 12 rather than 6.

Using the term "column" will most likely confuse a novice user or a user who is experienced with static grids such as the 960GS (where the term column originated). However, in the original 960GS context, the column was a true column -- an element with six.columns had children who added up to 6.

The Bootstrap method span(variable), omits the term '.column' as class name, however -- since it still borrows the conceptual notion of a column and then uses modifier names of an implicit column: Basically, span(variable) = the number of columns spanned.

This still will confuse the novice when they attempt to nest. And, the reading of the chained class names are less readily decipherable.

.spanX .offsetX is somewhat cryptic.

Additionally, a span is an existing html entity that has layout properties -- so this could be quite confusing to a novice user.

II. Other Models

• The Golden Grid System avoids the issue by avoiding naming completely. It leaves the unit name up to the user by providing a pre-processor variable. While pre-processor variables are elegant they leave those users who don't use pre-processors without the ability to customize layout -- which is problematic for an aesthetic framework. [See notes on Golden Grid System]

• Based on the above issues -- I propose we avoid .span and .column and name the unit something closer to .segment. When we are talking about a responsive (fluid) grid -- which is the only grid we are supporting by default-- the notion of a segment is a truer conceptual description for the relationship of the part to the whole.

A segment is a portion of a whole. Thus, segmentX would be a sub-portion of 100% of the page. I believe that 'column' made more sense for a static layout, where children sum to their parent column value. In a percentage-- nesting with columns that aren't true columns can be hard to understand -- and easy to make mistakes with.

All Grid Systems (with the exception of Semantic Grid System) de-couple and abstract the Grid Mechanism from the Content Entity:

All use the construct of wrapper classes -- some apply them to generic divs, others apply them to html5 entities. Similarly, the widths/layout settings and default responsive behaviors are applied to the Grid rather than the child content entity.

Two strategies could be supported for WebBlocks:

1. Grid Abstracted classes and helper classes outputted to a Grid CSS that an end-user who wants modular layout control but cannot use a pre-processor; these would need to allow a simple and consistent patterned markup structure separating the layout from the content. This method is easier for a novice end-user to repeat since there is a regular pattern to follow. For advanced users who rather not deal with wrapper elements, additional support could leave in clear-fixing classes for them to apply on their own. Clearfixing is an intermediate notion, so this would have low success for beginners. [See notes on Foundation, Bootstrap, and Skeleton]
2. For advanced users who want to avoid all presentational wrappers and classes in their markup, the Grid mechanism could be abstracted to the pre-processor layer as variables. They may use the pre-processor and avoid all presentational classes and wrappers.

An issue for WebBlocks to consider -- How much of the Grid and Layout Mechanism do we Support as our Core?

• Foundation is the most complex of the framework with a rich feature set filled with additional helper classes and even page layout alternatives for various use-cases.
• On the other hand, Bootstrap is very lean with ONLY the basic core units and some responsive helpers.
• Do we really want to get into the specifics of adapting complex layouts (such as Gutters and Vertical Rythem) -- or do we consider that for advanced users -- and simply allow them to leverage the framework we're adapting to by calling those classes? This may not be fruitful considering that only the core grid elements are shared in common across all systems.