Responsive Layouts about inuit.css HOT 35 CLOSED

I've been thinking about responsive grids in the context of inuit.css as well. I have no problem with putting classes in my HTML, but the only place I don't think it makes sense, is for responsive grids. It just doesn't feel right putting a .one-half class on an item if we decide that on wider viewports we're going to fit 4 per row! So what I've done is made a .g--stackable class for grid items and set their widths inside some media queries in the CSS, rather than adding width classes in the HTML:

.g--stackable {
    /* Mobile-first, so by default, grid items take up 100% of the available space */
    width: 100%;

    @media (min-width: 400px) {
        /* For viewports above 400px wide, make the grid items 50% wide so we can fit 2 on each row */
        width: 50%;
    }

    @media (min-width: 800px) {
        /* And for even larger viewports we can fit 4 grid items per row, making their widths 25% */
        width: 25%;
    }
}

your corresponding HTML would look something like like this:

<div class=gw>

    <div class="g g--stackable">
        <p class=demo-block>First</p>
    </div>

    <div class="g g--stackable">
        <p class=demo-block>Second</p>
    </div>

    <div class="g g--stackable">
        <p class=demo-block>Third</p>
    </div>

    <div class="g g--stackable">
        <p class=demo-block>Fourth</p>
    </div>

</div>​

I've put up an example to show how it works. Not sure if this is the best way to do it? I'd appreciate some feedback!

It's unfortunate that you can't currently use the SASS @extend feature to extend selectors defined outside an @media block. If that were possible, you could use the inuit.css defined width classes instead of numeric values, like this:

.g--stackable {
    @extend .one-whole;
    @media (min-width: 400px) { @extend .one-half }
    @media (min-width: 800px) { @extend .one-quarter }
}

from inuit.css.

@emzo Even I resorted to similar method to get my design working. I changed the width for the .g as such and then made my navbar's layout change too. The major problem I faced was stacking the navbar from a .nav.nav--block to .nav--banner.block-list. I had to override all original styles (which shouldn't be the case)

It would be great if @csswizardry can include .g--stackable in the core.

from inuit.css.

Another option of course would be to use a different grid system altogether. Griddle by @necolas looks like it would work pretty well with inuit.css

from inuit.css.

Although I'm not a big fan of using Javascript for this kind of thing, you could set up your nav for narrow viewports by default with a .nav--stacked class, and use JS to replace the .nav--stacked class with a .nav--fit class when the viewport width reaches a specified width.

There's some interesting discussion about combining CSS and JS breakpoints by @adactio here and @andrewrocco here, which might help.

from inuit.css.

I can’t promise it’s exactly what you’re after (yet) but keep an eye on the try/responsive branch :)

from inuit.css.

@emzo Even I don't like JS much and I was thinking of that option, but then I decided no not go for it. Will be rethinking how to go about it using inuit only.

@csswizardry Quite some interesting things going on try/responsive
Will be looking forward to some great development and will be contributing once my exams get over :)

from inuit.css.

responsive branch looks good, but it seems to me a little bit restrictive. what do you people think about this approach?
http://amperedesign.com/blog/more-responsive-grid-systems/

placeholder for the gridunits and redeclaring the sizes in the different media-queries.

from inuit.css.

I agree with @tobaco. While I'm generally a fan of adding css classes to my HTML on regular sites, in responsive sites this can quickly become unwieldy if you have lots of breakpoints. The problem with simply having a "t-", "m-" and "h-" class is that you are falling into the trap of developing your site depending on device breakpoints which we all know aren't good ;-) Instead you should be applying breakpoints when things look "broke".

See here for more http://coding.smashingmagazine.com/2012/03/22/device-agnostic-approach-to-responsive-web-design/

I'm currently working on a complex responsive site and we have 5 major layout breakpoints but then lots of little ones to apply tweaks to individual components. Currently we use mixins to apply the grid stylings which isn't ideal but the approach linked by @tobaco above looks interesting.

from inuit.css.

The problem with the approach linked (althout it is pretty awesome) is that you have to have an all-or-nothing approach. You have to have either all silent classes or all ‘solid’ classes, and the solid, can-exist-in-markup classes are much, much more flexible.

It’s a ponderer :(

from inuit.css.

Just a thought, but there's nothing stopping you having them as silent classes and using a Sass function to generate the 'concrete' classes based on the value of some configuration variable. Those preferring to use 'concrete' classes in their HTML could just set that variable to true to have them generated in the CSS.

from inuit.css.

To be honest, I am in favour of the multi-class method, and I can’t see really how silencing them would benefit more than the current implementation…

Developers will have to use the m-, t-, h- classes sparingly (which I imagine they would be anyway, as they’re mostly used on grids which are rarer, higher-level elements).

It’s one to ponder, but I can’t see inuit.css working with all silent classes for widths :(

from inuit.css.

I'd suggest using a function/mixin to generate the grid anyway to make things a little bit cleaner (see Griddle). You could easily make this generate silent classes for those who want that too.

But yeah, as far as I can see there are no benefits using silent classes other than if you want to apply the widths through SCSS instead of in your markup.

I think a bigger problem is how to make .nav--stacked become .nav without having to override a bunch of classes. If only @extend inside media queries existed.

from inuit.css.

I'd suggest using a function/mixin to generate the grid…

But then we’d lose the semantic* classes like .one-third, .two-fifths etc :(

*as in ‘has meaning to those who read it’ as opposed to ‘web standards semantics’.

from inuit.css.

Hmm, not sure i follow. Why would we lose them?

Edit: LOL, I'm dumb. We'd lose them, yes. Maybe it's better to keep things like they are then.

from inuit.css.

Perhaps I’m showing my Sass n00bery, but how could you write a function to generate classes like .one-quarter etc…?

from inuit.css.

@kevva

I'm dumb

Most certainly not! Thanks for all your help and input :)

from inuit.css.

The more I look at it, the more I like how Griddle manages this.

You could keep your grid classes as they currently are, but modify the grid-build-units() mixin from Griddle to generate all the context specific size classes. You could totally leave out the media query definitions and let the developer to choose those, since the number of breakpoints and their values will probably vary considerably between projects. Keep inuit.css lean and flexible ;-)

I don't really have a problem with using multiple classes on grids. When you're just looking at the HTML, it gives you a clear understanding of what that grid element layout should be at different viewport sizes, and if you're gzipping your CSS, the file size impact is minimal. I really do think breakpoints are best left out of the framework though, since they're such a moving target.

In terms of class naming, as it stands, the Griddle mixin creates classes that follow a unit-{integer}-{integer}{context} naming scheme. I find this pretty intuitive myself, but if you're set on the use of words rather than numbers, {context}-two-thirds would certainly be possible. I might give it a shot tomorrow if you're interested?

from inuit.css.

Perhaps I’m showing my Sass n00bery, but how could you write a function to generate classes like .one-quarter etc…?

You could try to base it on what I did for griddle (sorry, not really worked on it since the original proof of concept). It has some redundancy baked in to avoid duplicate CSS declarations for fractions that can be reduced.

Instead of printing the integers themselves each pass through the loop, you could look at mapping them to words. Although I'll put it out there that relying primarily on integers to represent fractions (so 1-2 or 1of2) is clearer and less prone to typos than word representations.

from inuit.css.

@emzo, I've already found a way to do that by mapping the numbers to words, like @necolas mentions.
https://gist.github.com/4166611

Maybe there is some optimization to be done but it works.

from inuit.css.

Again, although it works (and is very impressive) I feel it’s overengineering a solution that we already have…

That kind of Sass is going to be a massive barrier to entry to a lot of people, and it only really replicates existing functionality. I’d be reluctant to replace a series of classes that we already have with (albeit pretty damn clever) Sass which is difficult to read and understand (inuit.css is designed to be of major use to designers (due to it being design free) so such heavy use of scripting seems a little risky).

Also that and, personal admission, I’m not that ‘there’ with Sass yet, so I’d be a little wary of incorporating something I’d initially struggle to explain and maintain.

Cheers for your input, and it’s certainly something I’m keen to keep in mind (and now I know who to come to in future for some crazy complex Sass :P)

from inuit.css.

I’m thinking about classes like:

.palm- // Anything that fits in your hand
.lap- // Laptops, netbooks, tablets, etc.
.portable- // Both of the above
.desk- // Stuff that doesn’t really move at all

These names are as per Mr. @lukew himself:

These won’t tie us to actual device names like mobile and tablet did, but they do offer the same thinking with much more flexible naming.

from inuit.css.

@csswizardry It's totally your decision, and your call when it comes to what stays and what goes. inuit.css is your baby. Not trying to dictate at all, just enjoying the discussion ;-) Anyway, in response to some of your comments...

That kind of Sass is going to be a massive barrier to entry to a lot of people, and it only really replicates existing functionality.

True, but most users will never need to touch that stuff anyway, and shouldn't, if at all possible. Like you've said yourself, if you need to start messing with things too much, it's a failing of the framework. I totally agree that wherever possible, following the KISS principle is the way to go, but the added flexibility that a mixin provides here is worth it in my opinion.

I’m not that ‘there’ with Sass yet, so I’d be a little wary of incorporating something I’d initially struggle to explain and maintain.

That's a fair comment regarding maintenance, but there are plenty willing to help :-)

I just feel that the current responsive grid features are a bit limiting. For a framework that aims not to make design decisions, why fix the number of breakpoints? Sure, you can add and remove if you need to, but with a mixin to generate the width classes, you could let the user choose how many their design requires from the outset, and build all the classes for them. You would reuse the same mixin to generate the non responsive width classes as well.

To quote @necolas:

...I'll put it out there that relying primarily on integers to represent fractions (so 1-2 or 1of2) is clearer and less prone to typos than word representations.

I agree with this statement. Using 2-of-3 clearly shows that I want this unit to take up 2 of the available 3 columns in this row of the grid. Using integers also reduces the complexity of the mixin, which should cause you less worries.

from inuit.css.

My only problem is that inuit.css, by design, can’t do much in the way of responsive. The most it can do really is provide some alternative grid contexts by way of media queries.

In terms of this commit/feature it’s literally just adding a few different grid variations via some user-defined media-queries. Realistically, you should’t need to alter your grid system that much or that many times (certainly not more than for (and please don’t shoot me) mobile, tablet and desktop).

So—in terms of grid systems—I feel that allowing an infinite number of variations in an infinite number of media queries is irresponsible and out of scope.

I have no qualms with writing/including a more powerful mixin for quickly creating a variety of different media queries, but that functionality is not needed for grid systems.

Currently, inuit.css is wholly non-responsive, adding even this slight addition of grid contexts is a huge addition. In the interests of adding things incrementally, I think this is a suitable place to underline and fix the current feature scope (i.e. an easy interface onto a user-defined series of different grid contexts).

A more powerful mixin for creating MQs can (and should) be added in future, but for now I think that four grid system variations is more than adequate, particularly considering that the breakpoints at which they kick in is wholly user-controlled (we even offer an overlap for ‘all portable’).

I appreciate everyone’s input a lot, and you all know Sass a lot better than I do, but in the interests of growing inuit.css slowly and appropriately, I think we have enough in here currently to service a modified grid system (and that’s all this currently serves; grids).

Yours, trying-not-to-be-a-douche,
H

from inuit.css.

True, but most users will never need to touch that stuff anyway, and shouldn't, if at all possible.

That's true, but in order for users to use the framework properly they at least need to understand how things work. I wouldn't use something myself without looking at the code first. This would, however, only be a matter of proper documentation.

Realistically, you should’t need to alter your grid system that much or that many times.

I agree, four variations is more than enough. I guess you could argue that users should be able to decide for themselves if they want two, three, or twenty different gridsets, but yeah, these four should be sufficient in probably 99% of the cases.

A more powerful mixin for creating MQs can (and should) be added in future.

I'll have some documentation up for my solution later today.

I’m thinking about classes like...

Those are better than the current ones. Should the classes be prefixed or treated as modifiers though? .two-quarters--palm feels more in line of the current naming conventions of the framework than .palm-two-quarters.

from inuit.css.

@csswizardry I know you've made your decision, and I'm in agreement that big changes like this need to be implemented gradually.

Just to put it out there though, I thought I'd share my implementation for the size classes mixin. Like @kevva's solution, it's based on @necolas's Griddle code, but I've made it a little more flexible. You could use it to generate not only width classes (including any number of responsive alternatives), but also the push & pull classes (i.e. you can pass in a different CSS property, e.g. left, right, margin or padding, but width is the default). You can pass it a @content block so that you can @extend some base class, as you do for the push & pull classes. You can choose whether to use human friendly words, or integers. You can also customise the class naming scheme (it defaults to s-{int}-{int}, but takes arguments for the prefix, suffix and separator, like so {prefix}{numerator}{separator}{denominator}{suffix}. It will also correctly pluralize the denominator of the values (e.g. two-thirds instead of two-third).

All in all, the logic is exactly the same as @necolas's original code, it's just that I've put in a load of variables to make it more flexible. So in order to output CSS that is identical to your push classes, you would use it like this:

.push { position: relative; }
@include proportional-sizes(2 3 4 5 6 8 10 12, left, $prefix: 'push--', $type: words) {
    @extend .push;
}

For width classes, you would do:

@include proportional-sizes(1 2 3 4 5 6 8 10 12, $prefix: '', $type: words);

And for the responsive width classes:

@include media-query(mobile-only){
    @include proportional-sizes(1 2 3 4 5 6 8 10 12, $prefix: 'm-', $type: words);
}

The optional keyword arguments it takes (and their default values) are:

• $property: 'width' CSS property to set the size of
• $prefix: 's-' Prefix for the generated class names
• $suffix: '' Suffix for the generated class names
• $separator: '-' Separator to use between the numerator and the denominator values in the generated class names
• $type: int Style of output (anything other than '$type: words`will output integer values for the numerator and the denominator

from inuit.css.

@emzo See, that sounds unreal :D Definitely interested in baking that kinda stuff into inuit.css in future :D

from inuit.css.

I like it. Almost too many variables thrown in there, haha. SO MUCH OPTIONS.

from inuit.css.

Yes, quite a few! However, the defaults could be set sensibly so that you wouldn't even need to use them in the most general case, which in the context of inuit.css, would probably be generating width classes. It currently defaults to generating integer values in the class names, but that can easily be changed to more friendly words, and the prefix could be empty by default (it's set to 's-' because when you use integer values, it would create class names beginning with numbers, which of course ain't valid).

from inuit.css.

Again, although it works (and is very impressive) I feel it’s overengineering a solution that we already have…

It's abstracting the process of "proportion creation". Realistically, you don't need to go into the Sass functions again once they're written.

That kind of Sass is going to be a massive barrier to entry to a lot of people

Sass is already a barrier and it introduces significant code fragmentation ("to use this, you need Sass"). For these reasons, and the fact that Sass is solving a problem I don't have anymore, I rarely use Sass at the moment. When I do, it's only to leverage variables until we get a CSS variables shim. But with Sass, I agree that it's definitely a delicate balance to tread. I am generally a fan of not forcing people down into multiple layers of understanding, and opening up a "CSS" file full of pseudo-programming definitely isn't the nicest way to try and understand what is going on.

I’d be reluctant to replace a series of classes that we already have with (albeit pretty damn clever) Sass which is difficult to read and understand.

Yeah, this is generally my reaction too. Griddle was more of an experiment, although if you have moderate JS experience I think it's relatively clear after a moment.

My only problem is that inuit.css, by design, can’t do much in the way of responsive. The most it can do really is provide some alternative grid contexts by way of media queries.

...and the (non-JS) tools we currently have for responsive design are poor once you move beyond small-sites.

from inuit.css.

@necolas Out of interest, do you know if Griddle is being used much in the wild? Have you used it yourself for any projects?

from inuit.css.

I’ve merged in all features within the current scope so I’m gonna close this, however I’d like to keep you guys on board (if you’re still up for it when it comes to it) for adding in this superawesomeness…?

from inuit.css.

Sure, count me in :D

from inuit.css.

Yep, sure. Sounds good.

from inuit.css.

You guys rock, thanks so much :D

from inuit.css.

Even I am in :)

from inuit.css.