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.

@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