OOCSS grid names in a responsive site

responsive-oocss-grid-names.md

OOCSS grid names in a responsive site

I love using OOCSS grid names like .size1of2 or .size3of5, they are really handy. The problem I have with them though is that they make no sense in a responsive design where a grid of .size1of3 on a big screen might be a grid of .size1of2 on a slightly smaller screen.

Solution 1: use desktop sizes

Use the same classNames and don't care about the exact width. So a .size1of3 can actually be 33% wide on a big screen and 50% wide on a smaller screen and probably 100% on a very small screen. I have a problem with this, you might understand that.

Solution 2: use different classNames for different resolutions

What you could do is use different classNames for different resolutions. That might result in classes like .xl1of2, .l1of2, .m1of2, .s1of2 and xs1of2 which would result in HTML like this:

<div class="xl1of8 l1of6 m1of3 s1of2 xs1of1">

</div>

It looks a bit dirty. And it assumes that it's possible to create a predefined set of grids.

Solution 3: ask you

I'm not really happy with these two options. That's why I wrote this gist. I hope you have better ideas for this issue. Please let me know.

Another option is to use col classes I guess. It's a more general naming convention which doesn't cause as much confusion as .size1of3 and .size1of4 do.

<div class="col-8">
</div>

<div class="col-4">
</div>

In this desktop example, it shows that the col-8 should be wider than the col-4 and more specifically, the col-8 should be double the width of the col-4.
For tablets it could mean that the .col-8 class will be half the width it was before and the same for the .col-4. This way it still makes sense what you are doing to the widths in my opinion.
I guess for smartphones it doesn't really matter what classes you use because you probably will set them to 100% width and won't float anything.

It won't be the best solution either but it might be less confusing than the size classes?

Just use LESS. Write your grid-framework as you normally would, but then instead of polluting your markup with these non-semantic classnames (that lose all meaning when the layout changes), use them as mix-ins in your LESS code.

So instead of writing your markup like this:

<div id="header" class="grid_4"></div>

Write your LESS CSS like this:

div#header{ .grid_4; }

@decthomas those cols classes definitely make more sense, especially if the numbers are not mathematically associated with a width. I like it.

Or use classnames that describe their (main) content not their appearance :)

I wish people wouldn't always answer with "Just use [something awesome]" when there is a question about CSS. It's starting to get annoying. It's not helpful and it is never an answer to the question.

@gillesv I can't use LESS, we work with too many people from different organisations on our projects.

@davidhund the appearance is actually the meaning of a grid. I think separation of layout and content is a good thing.

@vasilisvg but, as you've discovered, a grid is not static. What once was a column could suddenly become a row. What in one context is a half-width column could in another context be a 25opx absolutely positioned element ;)

I think, therefore, that naming your elements with 'static' appearance-names (div.col-2-of-4) is just as silly as h1.red.

In this sense semantics should not be based on appearance but on content. The 'grid' is in your head, not fixed in the structure (< / morpheus>)

@davidhund Agreed that the grid is not static (that's the reason for this gist :-), but it does exist in my setup. And the grid is agnostic of its content so I can't give it a class name that describes it content.

@vasilisvg good point re: the content-agnosticism :) (That's probably how it should be, too)

Basically: we're screwed! Just pick something random: .alpha .beta .gamma…

@davidhund I really like that solution! I might add a prefix though: .g-alpha .g-beta…

If "the grid" is agnostic of its content, how do we even know whether it's still a grid? How many (semi) fluid/liquid layouts are you looking at supporting, as in, how many, for want of a better word, steps (?), are there? Doesn't it as @davidhund said, make more sense to base class names on content?

@matijs I don't know the size of a content item. For instance, a small component with a heading, an image and a list of links can be placed anywhere on the page, it does not have a width in itself, it just adapts to its parent. It is perfectly possible that an item like this is placed in a sidebar and in the main content area. On a large screen this might mean that this item is 200 and 600px wide. Separating layout from content keeps things manageable.
The other question you ask is how many "steps" there will be. I don't know yet. I will add as many steps as needed. If the layout is too cramped in a certain area a new step is created for that part of the layout. I think steps is not the right word though: they are layout/content conflicts and I solve them per item.

I hate saying that something is impossible, because part of me always sees that as a challenge...

...but I think that OOCSS grids and responsive layouts are fundamentally incompatible. If you want to use OOCSS, you have to accept the fact that you are embedding a certain amount of visual semantics in your HTML. (I wrote a bit about that here: http://sunpig.com/martin/archives/2011/06/25/oocss-and-html-semantics.html)

OOCSS grids are a perfect expression of this: when you use them, you are saying that the visual semantics of the content use a certain grid layout. If the visual semantics do not require a specific grid layout, then you should not use the OOCSS grid classes.

If your responsive design asks for a 3-column layout at some widths, but a 2 or a 4 column layout at other sizes, this means that the content does not conform to, or require a specific grid layout. Therefore, you should not use OOCSS grid classes to embed visual grid semantics in the HTML.

I love OOCSS grids, and I use them a lot, but they are not the right tool for this particular task.

I do think it would be possible (and very cool) to design a set of abstract layout classes for responsive designs based on OOCSS principles. But, semantically, you're not talking about a grid object any more. You're talking about a composite object that -- under certain specific circumstances -- displays grid-like properties. The classes you will end up with will be very different.

** resurrecting thread

+1 sunpig

I don't see how you could ever use these in markup in a responsive site:
https://github.com/stubbornella/oocss/blob/master/core/spacing/space.css