Base Layout + Grid System Review

[loganfranken]

I'm currently working on a redesign that uses Web Blocks and so I've reached a point where I would like to set a basic wrapper to contain the page's width:

http://twitter.github.com/bootstrap/scaffolding.html#layouts

Basically, following Bootstrap's convention, we would want the ability to:

1. Set a fixed width that doesn't shrink on smaller viewports
2. Set a maximum width that does shrink on smaller viewports

I think .container works just fine if we want to keep the Bootstrap convention. I would need to do a little more research to determine the appropriate default width for this.

[ebollens]

Personally, I think we should only support responsive. Otherwise, we're going to end up having to implement a bunch more trickery as we're already developing a lot of elements with responsive in mind.

.container does work just fine for me on this. Personally, I think the default width should be auto with a fixed padding, but these should be made configurable.

[loganfranken]

@ebollens Alright, I'm with you on only supporting responsive. Depending on how media queries are applied to each entity, a fixed width implementation may not be that difficult as it would just be elements filling a fixed container (rather than a responsive container). But we can think about it once we're a little further down the line with the other entities.

Are you saying that the width would just always fit the max width of the page? I think this is the where web design is heading (i.e., "truly" responsive, with elements adjusting to fit the entire available width), but it seems to me that many of the current implementations of responsive designs (http://mediaqueri.es/) are responsive up to a certain point.

There seems to be two approaches here: (1) Bootstrap has a fixed width .container and an auto width .row for the grid system, while (2) Foundation has a 100% width .container but a fixed width .row. This ends up having pretty much the same effect, as far as I can tell.

@ebollens @atsengucla Thoughts?

[ebollens]

I much prefer width constrained by the container and not the row - however, I'd say that it's really up to the adapter to decide how exactly it is implemented, so long as the semantics hold.

[alicetseng]

so Bootstrap's latest version has .container-fluid with .row-fluid : http://twitter.github.com/bootstrap/scaffolding.html#fluidGridSystem . This is what I've been protoing on.

[ebollens]

I think we should seek a prototype like this:

<div class="main container">
    <div class="row"> ... </div>
</div>

And then if we wanted the container to be a fixed size rather than fluid:

<div class="main container fixed">
    <div class="row"> ... </div>
</div>

The reason I say this is basically that I think our rows should always be .row-fluid, a la using percents instead of pixels to define widths. If we want a fixed feel, we can achieve it simply by fixing the width of the container. The reason I say we don't want to have a non-fluid row equivalent is because, if you think about it, how did they actually write the non-fluid equivalents? Simply by doing division, which is the same as using percent widths in the first place - if the container is fixed.

Given this, we can essentially make row of width: 100% of its container. That supports nesting just like in Bootstrap. The ability to have a static container gives us the ability to have static-feeling columns in the row.

You'll also note that I'm using .main.container rather than just .container. The reason is that I'd like to see .main be the thing that actually sets a width for an element by the name .container. Another option is .main-container or we can some up with a name besides "main" that captures it better. The reason is that we already have .float-container and I'd like to reserve just .container to not be something that sets margins and width to some specific value.

If we're agreed on these points, then the next big questions that stand out:

• We need a different name besides .row because is that really semantic? I assume that we want this to implement .clearfix or at least .float-container so that it actually behaves like a row (otherwise floats will run away from us). Bootstrap does exactly this.
• Do we actually want to have something like .main.container set widths and margins while .container is then the thing that just acts like a row. My reasoning here is that this would allow us to have .main.container > .spanX (or whatever we call the grid layout class) and also allow us to have .main.container .container > .spanX as well as something like .main-container .float-container > .float-left + ....

Just some musing here. I think we have a lot more thinking to do on this and should probably consult a few more grid systems first.

[alicetseng]

So I do think that we should keep the name .row.

This is the reason. If you look at the css declarations in the class — it's not simply floating and width setting, but also contains important code to clearfix cross-browser and off-set padding/margin that needs to happen in order for children elements to be rendered consistently (only needed when you try to use float technique for positioning).

As long as we're committed to using a grid and committed to achieving layouts using a float technique, there will be a need for the system to be transparent and reliable to
the end-user how to control their layouts. Floating is full of bugs without these fixes when you begin to nest — so by abstracting the layout mechanism into separate classes and naming in a way to describe clearly to the end-user what these classes do (not what they wrap), it can ensure that these fixes are happening — no matter how the user changes their layouts — but more importantly, it describes clearly to the user what is happening — so they can use it to their custom layout needs -- which is the point of using a grid system, otherwise you'd just declare these positioning rules directly to the content element.

So, I do believe that the name .row is semantic to what the purpose of that class is for — it is simply to create a helper situation that is generic and reusable for every case in which the end-user needs to make a new row of content.

Is it semantic to the content that it wraps -- nope. But in most cases we'll have a situation something like this

-- which is nice. I do want the semantics on the header element to describe the content (hence .masthead)…. but I don't want the float technique to be bundled with that content … there is a real case when with an uber complex layout will mean that I won't want to use floats — that instead, I may want to position the header using another positioning technique such as parent relative position, child absolute position. In such a case I want to have the flexibility to say and dropping the float .row.

What I'm basically saying is that if we choose to use "grid systems" we need to abstract out the positioning mechanism and name it so it's transparent to what its doing for it to be both robust and easy for an end-user to use. One constant we can count on for layout — it needs to be able to meet all cases an end-user will want to customize it for — and we cannot predict what this will be — so it needs to be generic -- .row should be thought of like our other utility classes such as .highlight and we should keep the names to describe its functional utility (positioning technique) rather than the content context.

-alice

From: Eric Bollens <notifications@github.commailto:notifications@github.com>
Reply-To: ucla/WebBlocks <reply@reply.github.commailto:reply@reply.github.com>
Date: Saturday, September 29, 2012 2:51 PM
To: ucla/WebBlocks <WebBlocks@noreply.github.commailto:WebBlocks@noreply.github.com>
Cc: Alice Tseng-Planas <atseng@it.ucla.edumailto:atseng@it.ucla.edu>
Subject: Re: [WebBlocks] Base Layout Classes (#103)

I think we should seek a prototype like this:

...

And then if we wanted the container to be a fixed size rather than fluid:

...

The reason I say this is basically that I think our rows should always be .row-fluid, a la using percents instead of pixels to define widths. If we want a fixed feel, we can achieve it simply by fixing the width of the container. The reason I say we don't want to have a non-fluid row equivalent is because, if you think about it, how did they actually write the non-fluid equivalents? Simply by doing division, which is the same as using percent widths in the first place - if the container is fixed.

Given this, we can essentially make row of width: 100% of its container. That supports nesting just like in Bootstrap. The ability to have a static container gives us the ability to have static-feeling columns in the row.

You'll also note that I'm using .main.container rather than just .container. The reason is that I'd like to see .main be the thing that actually sets a width for an element by the name .container. Another option is .main-container or we can some up with a name besides "main" that captures it better. The reason is that we already have .float-container and I'd like to reserve just .container to not be something that sets margins and width to some specific value.

If we're agreed on these points, then the next big questions that stand out:

• We need a different name besides .row because is that really semantic? I assume that we want this to implement .clearfix or at least .float-container so that it actually behaves like a row (otherwise floats will run away from us). Bootstrap does exactly this.
• Do we actually want to have something like .main.container set widths and margins while .container is then the thing that just acts like a row. My reasoning here is that this would allow us to have .main.container > .spanX (or whatever we call the grid layout class) and also allow us to have .main.container .container > .spanX as well as something like .main-container .float-container > .float-left + ....

Just some musing here. I think we have a lot more thinking to do on this and should probably consult a few more grid systems first.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/103#issuecomment-9008647.

[ebollens]

Hmmm okay that makes sense @atsengucla

What are your thoughts on .container class?

[alicetseng]

hi @ebollens. I think .container is a logical name for a wrapping container.

However, I think the distinction between .float-container and .container could get confusing if we're not careful with our distinctions.

If we are using the class .float-container than we need to be careful when we're talking about a Grid system that uses all floats as its primary layout mechanism.

If I saw .float-container and .container -- I'd assume that one meant I'm using floats to control the layout and in the other case I'm not using floats. Maybe the container is using absolute positioning like in the faux columns technique (http://www.alistapart.com/articles/fauxcolumns/ ) or the display:table technique (http://www.digital-web.com/articles/everything_you_know_about_CSS_Is_wrong/).

So, I think the naming could be confusing to end-users if we don't review a few more grid frameworks that we plan to support and come up with some overall strategy like we did for color.

If we're basically sticking to Bootstrap's grid - they use floats for everything, then in this context .container > .row >.spanX makes sense. But, if we're keeping this logic, then I'm not sure what a .float-container would be.

I've been looking at Foundation vs. Bootstrap and one thing to note is that Foundation 3 forces everything in their Grid to render with box-sizing: border-box ( http://foundation.zurb.com/docs/grid.php ). While Bootstrap's Grid uses box-sizing:content-box.

What this means is that a given unit width would essentially mean different things - in the first the unit width encompasses everything with padding and margin pushing inwards on the unit defined. In the second case, padding and margin pushes out, in addition to the unit width defined. Thus for foundation .row sets the width, having only .columns as numerical dividers and gutters (thus, no need for a .container). While in Bootstrap .span X sets the unit width and .row and .container providing the gutter and margins.

It's gotchas like this that I think we'd want to identify before we settle on a naming scheme. Do you have a few grid systems in mind that we should investigate?

[ebollens]

@atsengucla the reality of it is that .row and the Base/Entity .float-container class are basically the same thing in that they both are essentially an overflow: auto container for a set of floated elements. Maybe we just drop .float-container altogether, at what it does essentially describe is a row - although I will point out that the .row that Bootstrap provides, like the .float-container already provided by us, doesn't prevent a set of floated elements from overflowing to the next line, but rather simply ensures that other content will not slip up into the space created by the floated elements. Thoughts? Should we just chuck .float-container and instead let that be .row?

As for grids to consult, here was a list we put together in the wiki:

• GridPak http://gridpak.com/
• Semantic Grid System http://semantic.gs/
• Gridset http://www.gridsetapp.com/
• Golden Grid System http://goldengridsystem.com/
• Simple Grid System http://simplegrid.info/
• Foldy960 https://github.com/davatron5000/Foldy960 (responsive extension of 960.gs)
• Less Framework http://lessframework.com/
• Columnal http://www.columnal.com/
• Skeleton http://www.getskeleton.com/
• Bootstrap http://twitter.github.com/bootstrap/
• Foundation http://foundation.zurb.com/
• HTML5 Boilerplate http://html5boilerplate.com

As for concern over box-sizing and stuff like that, I wouldn't worry too much about that yet. It's an implementation-specific detail on a framework-by-framework basis. Depending on what adapter you use, it will vary.

[ebollens]

Also, what do you think of something like .four.columns instead of .span4. I will say I think .span4 is definitely not the right way to do this. A span already has a meaning in HTML, and the class has nothing to do with its HTML meaning. To tell you the truth, I'm not quite a fan of either, but I don't really have many good ideas on this one.

[modernrockstar]

Is the convention in other frameworks to use .spanX?

Is there a limitation to using a new convention of spelling out column number names?

From: Eric Bollens <notifications@github.commailto:notifications@github.com>
Reply-To: ucla/WebBlocks <reply@reply.github.commailto:reply@reply.github.com>
Date: Monday, October 1, 2012 9:06 AM
To: ucla/WebBlocks <WebBlocks@noreply.github.commailto:WebBlocks@noreply.github.com>
Subject: Re: [WebBlocks] Base Layout Classes (#103)

Also, what do you think of something like .four.columns instead of .span4. I will say I think .span4 is definitely not the right way to do this. A span already has a meaning in HTML, and the class has nothing to do with its HTML meaning. To tell you the truth, I'm not quite a fan of either, but I don't really have many good ideas on this one.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/103#issuecomment-9038380.

[ebollens]

@modernrockstar there's no "convention" around using spanX. It's just what Bootstrap uses, and given its recent popularity, it's the one on everyone's mind. However, I really don't think it's semantically accurate.

Here's a breakdown of what each framework I listed above uses:

Gridpack:

• .col.span_X

Semantic Grid System:

• Provides SASS mixins that generate spanning in actual elements instead of providing a grid unit

SimpleGrid:

• .row
• .slot-0, .slot-1-2, .slot-3-4-5 (page is broken up into 6 or 4 slots)

Foldy960:

• .row
• .grid-X

Columnal:

• .row and .row.reverse
• col_X

Bootstrap:

• .row
• .spanX

Skeleton

• .one.column (works without a .row class although they do provide a .container class)

Foundation:

• .row
• .four.columns

HTML5 Boilerplate:

• .grid
• .grid-cell

[alicetseng]

I'd have to spend more time looking at the other frameworks – but I agree that spanX is an odder naming convention.
Columns makes more ready sense to me, when you're talking about layout.

Personally, I feel that Foundation's grid is much more elegant – especially when dealing with % based grids, but again — I think it would be good to review at least 5 popular systems to see what conventions are being used. Ultimately with this we have to balance elegance with common convention — like it or not — end users get trained to a certain way of doing things and if we want adoption we want to make sure it supports what they are expecting.

Shall we divy up some frameworks at the meeting today and create a task to do some review write ups?

RE the limitation for spelling out column names. I guess the only one I can think of is not using an incrementing count if its spelled out instead of numerical.
And also maybe more room for typos since 5 is fewer characters than five. Really, as long as it's a sane and consistent convention that follows a logic and clearly spells out what it's doing, I think we're OK.

My vote is to review Semantic Grid, Golden Grid, Foundation, and LESS against Boostrap. Since Bootstrap is essentially a 960 and many of the others are based on 960 it would be good to see some others.
Boilerplate is essentially in the same vien as Boostrap and Gridpack is more a visualizing tool to roll your own Grid.

Cheers,
alice

From: Joseph Maddela <notifications@github.commailto:notifications@github.com>
Reply-To: ucla/WebBlocks <reply@reply.github.commailto:reply@reply.github.com>
Date: Monday, October 1, 2012 9:12 AM
To: ucla/WebBlocks <WebBlocks@noreply.github.commailto:WebBlocks@noreply.github.com>
Cc: Alice Tseng-Planas <atseng@it.ucla.edumailto:atseng@it.ucla.edu>
Subject: Re: [WebBlocks] Base Layout Classes (#103)

Is the convention in other frameworks to use .spanX?

Is there a limitation to using a new convention of spelling out column number names?

From: Eric Bollens <notifications@github.commailto:notifications@github.commailto:notifications@github.com>
Reply-To: ucla/WebBlocks <reply@reply.github.commailto:reply@reply.github.commailto:reply@reply.github.com>
Date: Monday, October 1, 2012 9:06 AM
To: ucla/WebBlocks <WebBlocks@noreply.github.commailto:WebBlocks@noreply.github.commailto:WebBlocks@noreply.github.com>
Subject: Re: [WebBlocks] Base Layout Classes (#103)

Also, what do you think of something like .four.columns instead of .span4. I will say I think .span4 is definitely not the right way to do this. A span already has a meaning in HTML, and the class has nothing to do with its HTML meaning. To tell you the truth, I'm not quite a fan of either, but I don't really have many good ideas on this one.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/103#issuecomment-9038380.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/103#issuecomment-9038797.

[loganfranken]

I'm changing the title of this issue as we've veered slightly off topic into the broader grid discussion (which is a good thing). I'm not sure if we have enough research here to make a decision about the base container or if we have decided that the base container and grid system are too tightly coupled to implement separately?

At least as far as the base container discussion, I think a responsive container with fixed maximum width (that can be customized, of course), filled with percentage-based rows, makes the most sense.

Determining that fixed maximum width is a little more involved:

• Bootstrap's container uses 1200px width for larger displays and 980px width for "default" (1024x768)
• Foundation has a pretty straightforward 1000px default width for the rows
• SimpleGrid uses 1236px and 986px
• Less Framework uses 992px
• Columnal uses 1140px
• Skeleton uses 960px

This would also bring up the discussion about whether or not we include some default breakpoints (ala Bootstrap: http://twitter.github.com/bootstrap/scaffolding.html#responsive), although ideally a website should have breakpoints based on the needs of the design (not based on arbitrary device widths). This should be spawned into a separate issue.

I feel like it would be useful to have a breakpoint supporting 1024x768 at the very least. 960px seems to be the safest choice here in terms of making sure it fits on most browsers (and it's a very conventional width these days). Maybe 960px with 10px margin/padding on either side (for a total 980px) would be most appropriate.

960px/980px looks relatively small on larger displays, though, so I think that a maximum width somewhere closer to 1200px should be the default maximum width.

Some articles in my attempt to try and find some info about maximum viewport sizes (it's all very scarce):
http://www.cameronmoll.com/archives/001220.html
http://stackoverflow.com/questions/447456/what-the-typical-viewport-size-on-a-1024x768-screen
http://philfreo.com/blog/largest-website-width-to-support-1024x768-resolution/
http://www.nealgrosskopf.com/tech/thread.php?pid=43

[ebollens]

@loganfranken as far as I see it, you could implement .row with or without a base container (so they're not tightly coupled). If a base container is implemented, then .row would go to fill it in or else it would fill in whatever the width of its containing element is. So yes, then we need to come up with a maximum width that feels good for the base container, and then .row can adapt to it.

[alicetseng]

Wiki page created here for Grid Strategy: https://github.com/ucla/WebBlocks/wiki/Grid-Strategy

[loganfranken]

Any objections to closing this issue and creating a (1) grid system issue and a (2) default breakpoint issue?

[loganfranken]

I want to keep moving forward, so I created both the issues. I'm closing this issue now; feel free to close/delete/open/eat/hug any of the issues if you disagree.

[ebollens]

Sounds good!

On Oct 8, 2012, at 11:33 AM, "Logan Franken" <notifications@github.commailto:notifications@github.com> wrote:

I want to keep moving forward, so I created both the issues. I'm closing this issue now; feel free to close/delete/open/eat/hug any of the issues if you disagree.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/103#issuecomment-9235437.