I've defined a Susy-based responsive grid system handling 4 (mobile), 8 (tablet) and 12 (desktop) columns. My layout is having a fixed header bar which is divided in two sections "logo" and "toolbar".
The "logo" div is not nested within Susy's grid-container and is positioned absolute to always be on the very left.
The "toolbar" div contains the Susy grid-container and holds a search- and a logout-action - so far so good :)
When resizing the browser its in the nature of the grid to change total-columns when there's no more space for say 12 columns. This causes following problem:
The "logo" div gets overlapped by the grid since its positioned absolutely.
Is there a way to tell Susy to break the layout to 8 columns before the black border of the "logo" div is being reached?
Any advice would be highly appreciated. Thanks in advance.
#Eric: I managed to get it working. This is what is used:
#mixin update-container {
#include container;
#include susy-grid-background;
}
.page {
#include update-container;
#include at-breakpoint(865px 8 1149px) {
#include update-container;
}
#include at-breakpoint(1150px 12) {
#include update-container;
}
}
So I've explicitly described the min- and max widths to tell the columns when to change. Is this the "right" way to go or is there any more elegant way for solving this?
Thanks :)
Related
trying to re-write another's template (which works well and is written in raw css3 – but is very messy).
Most stuff is easily translated to bourbon/neat but I'm stuck on getting up a responsive image grid.
<section class="page-content">
{% for post in site.posts reversed %}
<div class="myevent" style="background-image:url({{post.cover}});">
{% endfor %}
</section>
inside an outer-container I have a set of dynamically generated divs (using jekyll's tempting) and on large screens I have each div taking up span-columns(4) [I have media queries that change columns to 8 and 4 depending on width].
Each div has an image as a background and a header text label.
If this was a fixed screen with no side borders (i.e. each div was 33% of the width it would be simple to add 33vw as the div height to go square
My problem is getting the div to be square. As I do not know in advance what screen width, how much side padding the outer-container gets, how many columns, if there is a gutter (yes normally but no in single column) .....
.page-content {
#include outer-container;
}
.myevent {
#include span-columns(4);
#include omega;
//
// has to be square - can't figure out how to calculate this
//
}
.nth-element {
// clear gutter every third
#include omega(3n);
}
// I also have new-breakpoints at certain widths dropping to 8 and 4 columns automatically with corresponding omega(2n) and omega(1n) changes as the column totals change.
I am at a loss how to calculate the actual width of the .myevent and setup the height of these divs to equal to the width
One possible answer for this (and the solution I would probably use) is to relatively position the span-column object and absolutely position the content inside of it. Then I would add something like:
.my-cool-column {
position: relative;
&::before {
content: "";
display: block
padding-top: 100%;
}
}
This'll cause the padding top to be equal to the width of the parent element. That should work.
Im making a page with bootstrap 2 due to job requirements and facing the following challenge, please understand Im learning it ;)
I have one #mainDiv below a div with my namespace for bootstrap .bootstrapDiv
Below that I have one .row-fluid, under them 2 .span12, here is my problem;
I need to be able to put together with margin-right:0 first one and margin-left:0 second one, these two divs should fill the row respecting the general layout of the rest of rows.
How I see them is ok in the left but at right is missing this gutter width and doesnt looks nice at all, is there any special class that expands the row and its contents horizontally if you take out the iner horizontal margins of the elements in it?
How should you solve this problem normally?
EDIT
Here is my fiddle:
http://jsfiddle.net/qdb74/
im refering to the black space
I usually solve problems like this by creating my own CSS or extending Bootstrap. That is because Bootstrap doesn't have an option to modify the gutter for .row-fluid. Here is an example on how to extend Bootstrap:
.row-fluid [class*="span"].no-gutter {
margin: 0;
}
.row-fluid .span6.no-gutter {
width: 50%;
}
.row-fluid .span5.no-gutter {
width: 41.666666666666666%
}
...
And you can decorate your element like this:
<div class="firstDiv span6 no-gutter"></div>
However if you decide to extend Bootstrap and a new version of the framework comes out this might break. If that is a concern it might be better to create your own fluid grid without gutters. That option will require you to write a bit more CSS than this.
I'm trying to add padding to the .container without it effecting the grid. The best example I can think of is I don't want the content to hit the sides of the .container because if the design has say a blue background and the .container is white I want there to be a padding on the left and right. I quick made an example page here to show the problem.
I'm basically trying to make a container of 1000px with gutters of 20px and each will then take up 65px. Outside of the grid though but inside the .container I want the padding left and right to also be 20px. Not sure if this helps or makes things worse but this is my Calca workout sheet for the grids
Neat has a mixin called pad which applies padding to the current element.
Where you've declared your outer-container just add a pad mixin and specify the left and right values, e.g.:
#container {
#include outer-container;
#include pad(default 50px default 50px);
}
In the above example the parameters are in the order top, right, bottom, left. Handily, the mixin accepts default so you don't need to know the existing values for the top and bottom if you don't care about them.
That said, if your use case is to prevent the background from hitting the side (rather than the content) then padding won't help you, and you'll need to fix margins instead.
Typically grid systems use box-sizing: border-box; to overcome issues with box model calculations concerning margins and padding.
Here's a good article by Paul Irish on this very issue: http://www.paulirish.com/2012/box-sizing-border-box-ftw/
Chris Coyier from CSS Tricks has a good article too: http://css-tricks.com/box-sizing/
I have 4 elements with widths set at #include span-columns(3,12) this outputs each element at 25% which is fine, what I would also like to do is add margin to each element but doing this breaks the layout of these elements as the 25% width and % margin get added together. Can anyone advise how I can combine the margin in with the width?
SCSS
.m-info-col{
.col{
#include span-columns(3,12);
// tried this margin-right: columns(.5,12);
&:last-child{
#include omega;
}
}
}
If you have your container set up with 12 columns and have set $gutter-width to a value, then each column has $gutter-width gap (margin if you like).
If you implement susy grid backgrounds using:
$show-grid-backgrounds : true;
and inside your container context:
#include susy-grid-background;
You will see the gutters behind your design.
You can also add padding into the span-columns mixin (3rd param). This does not always work as expected though.
Another way I have used is the squish mixin and it adds columns as margins. This works quite well but I have not tried using 0.5 columns as the squish amount.
I am getting started with Compass and Susy. My goal is to make my layout adapt to phone, tablet, and desktop screen sizes.
In the Susy examples (susy.oddbird.net or SO question), there is a pattern of having the number of columns adapt to the screen size. Specifically, there are nested rules like these:
.container {
#include container;
#include desktop {
#include container;
}
}
My questions now: What does the container { #include container } do? And, why is it nested again in the desktop include?
The container mixin establishes the width of your page. You only need to repeat it at different breakpoints if that width should change (as they would with adaptive layouts). If you are using a fluid grid, there is no need for the repetition.