I'm getting some strange behavior and was wondering if I am using a grid-column-row incorrectly.
I have the following HTML structure:
<div id="homeTop">
<!-- homeTop content such as headings and other nested rows and columns -->
</div>
<div id="homeMain">
<div id="homeMain-left"></div>
<div id="homeMain-right"></div>
</div>
<div id="homeBottom">
<!-- homeBottom content such as headings and other nested rows and columns -->
</div>
I then have the following SCSS to style this content:
#homeTop {
#include grid-column-row;
}
#homeMain {
#include grid-row;
}
#homeMain-left {
#include grid-column(12);
#include breakpoint(medium) {
#include grid-column(8/12);
}
}
#homeMain-right {
#include grid-column(12);
#include breakpoint(medium) {
#include grid-column(4/12);
}
}
#homeBottom {
#include grid-column-row;
}
When I view the page on a desktop-sized screen, there is one line of css that's causing the homeBottom div to float right, which is throwing off the layout. The line of CSS causing the issue is here:
#homeBottom:last-child:not(:first-child) {
float: right;
}
Since a column-row is meant to be a single element acting as a row and a column, in other words, a full width container, I'm confused why I would ever want it to have a float property. It seems that this line of CSS makes sense for columns, but not for column-rows, since the column-row behavior shouldn't depend on whether or not it's the last-child of its parent.
Is this a bug, or am I using the column-row incorrectly? I'm just trying to avoid setting homeBottom as a grid-row, and then including an extra html element inside of it just to act as a full-width grid-column. As you can see, this isn't necessary for homeTop, even though it's also using the grid-column-row mixin. This makes me think I may be using it incorrectly.
I guess another option would be to define my own my-grid-column-row mixin that includes the float declaration:
#mixin my-grid-column-row {
#include grid-column-row;
float: none !important;
}
But this seems like it shouldn't be necessary.
It looks like this is an issue with foundation:
http://github.com/zurb/foundation-sites/issues/8108
My workaround for now is to override the grid-column-row mixin with the following:
#mixin grid-column-row(
$gutter: $grid-column-gutter
) {
#include grid-row;
#include grid-column($gutter: $gutter);
float: none !important;
}
Related
I am attempting to define some default behaviors for a grid and then override them at specific breakpoints. In the following example I would like the two divs to be stacked on top of each other, with slightly modified gutter settings from the default, and then at 800px and above I would like the divs to stack next to each other. The second part does not happen. Seems like some margin settings from the less than 800px scenario are being applied to the greater than 800px scenario. Please let me know how to code this and adhere to susy best practices.
HTML:
<div class="container">
<div class="primary">
<p>I am Primary</p>
</div>
<div class="secondary">
<p>I am Secondary</p>
</div>
</div>
SCSS:
$susy:
(
flow: ltr,
output: float,
math: fluid,
column-width: false,
container: 1200px,
container-position: center,
last-flow: to, columns: 12,
gutters: 1 / 4,
gutter-position: after,
global-box-sizing: border-box,
debug: (
image: hide,
color: rgba(#66f, 0.25),
spot: background, toggle: bottom right)
);
* {
#include box-sizing(border-box);
}
.container{
#include container;
}
.primary{
background-color: red;
}
.secondary{
background-color: blue;
}
// Mobile first layout with slightly different
// gutter settings from default
#include with-layout(12 0.5 split){
.primary{
#include span(12);
}
.secondary{
#include span(12);
}
}
// this layout should take over at 800px and above
// and share a row but instead boxes end up on different
// rows
#include susy-breakpoint(800px, $susy)
{
.primary{
#include span(first 6);
}
.secondary{
#include span(last 6);
}
}
I also made a codepen example that can be found here:
http://codepen.io/sbonham/pen/vLKvMJ
Yep, Susy is just writing CSS values, so you have to handle this the same way you would with plain CSS. Susy doesn't know your DOM, so it has no way of knowing that you want to override values that you set before. If we assumed you always want to override, we would have to output massively bloated code.
There are two solutions here:
Put your small-screen layout inside a max-width media-query, so it doesn't affect larger screens.
Or: override those global values inside the large-screen media-query. The problem to fix is the extra margins added by your initial split gutters.
I prefer the first solution, because I think overrides are ugly. But if you're dealing with some small browsers that doesn't support media-queries (do those still exist?), then you'll need to use the second solution. Try:
#include susy-breakpoint(max-width 800px, 12 0.5 split) {
.primary{
#include span(12);
}
.secondary{
#include span(12);
}
}
this seems like a hack, but hopefully you get something out of this! I added the following to your codepen:
.primary, .secondary {
display: inline-block;
margin: gutter(12);
width: span(12);
width:500px;
}
http://codepen.io/alexG53090/pen/wMWNzR
On their website, the first feature is "Experience cleaner markup without presentational classes.", how do they solve this problem?
I think what Compass has to offer in order to allow us to create cleaner and semantic markup comes for free if you already use SASS alone.
By instance take this trivial example:
Some Mixins
#mixin box {
display: block;
}
#mixin sized_box($width:auto, $height:auto) {
#include box;
width: $width;
height: $height;
}
#mixin floated_box($direction:none, $width:auto, $height:auto) {
#include sized_box($width, $height);
float: $direction;
}
#mixin left_box($width:auto, $height:auto) {
#include floated_box(left, $width, $height);
}
#mixin right_box($width:auto, $height:auto) {
#include floated_box(right, $width, $height);
}
A Placeholder
// divs will be red
div%colored_floating {
#include left_box;
background-color: #ff0000;
}
// paragraphs will be blue
p%colored_floating {
#include right_box;
background-color: #0000ff;
}
Our stylesheet
// if #some.selector * turns out to be a div it will be red,
// and if it is a paragraph it will be blue
#some.selector *{
#extend %colored_floating;
}
Finally on your markup, you don't need any presentational classes
Except for those to make the placeholders more specific, of course.
<section id="some" class="selector">
<div>This will float and it will be red</div>
<p>But this will float right and will be blue</p>
</section>
You could always do:
// to make the placeholders absolutely generic to the whole markup,
* {
#extend %colored_floating;
}
Again, sorry for the very trivial example, but hopefully it will give you an idea on how to get rid of the presentational classes on your markup, aiming to pure semantic content.
What Compass gives us in addition is a complete framework of these mixins, placeholders and so on, ready to be used for good.
Cheers!
Question
Why is the bootstrap-sass makeColumn(X) mixin not behaving the same as the Bootstrap .spanX class? For example, a class using makeColumn(9) does not look the same as the same div using a .span9 class.
Context
I'm building an application using Ruby on Rails and having major problems trying to use the mixins in the bootstrap-sass gem.
When I use the classes I've defined I don't get the same styling as if I were to just use the .span class in Bootstrap. I've looked all over the Internet and can't figure out what's wrong. I'm guessing it's something fairly obvious that I'm just not seeing because I've been staring at a screen for too long.
HTML
<div class="content">
<div class="main">...</div>
<div class="sidebar">...</div>
</div>
scss file
#import "bootstrap";
body {
.main-content {
#extend .container;
}
.content {
#include makeRow();
}
.content .main {
#include makeColumn(9);
}
.content .sidebar {
#include makeColumn(3);
}
.feature {
#include makeColumn(4);
}
padding-top: 60px;
}
footer {
#extend .container;
}
#import "bootstrap-responsive";
Thanks for the help.
I'm not sure what SASS Adaptation you're using but in the one I'm using (https://github.com/anjlab/bootstrap-rails), there isn't a lot of documentation and the format changes.
Instead of #include makeRow(); you have to use:
#include make-row();
Instead of #include makeColumn(3); you have to use:
#include make-column(3);
more documentation can be found here: https://github.com/anjlab/bootstrap-rails/blob/master/app/assets/stylesheets/twitter/bootstrap/_mixins.scss
I have created a jsFiddle to demonstrate this issue. It's just an example.
What I'm doing
Let's say I'm making a flexible grid. My HTML looks like this:
<div>
<p>a</p>
<p>b</p>
<p>c</p>
<p>d</p>
</div>
Four columns. I have two mixins and a global variable called $gutter. In my mixin, I call this variable to add gutters and change the widths.
$gutter: 1%;
#mixin col($width){
float: left;
width: $width - ($gutter * 2);
margin: 0 $gutter;
}
#mixin row(){
width: 100%;
overflow: hidden;
}
I use it like so:
div { #include row(); }
p { #include col(25%); }
What I want to do
Now let's say I want to add a second, different grid to the page. I create this HTML and give each grid and ID to differentiate them:
<div id="one">
<p>a</p>
<p>b</p>
<p>c</p>
<p>d</p>
</div>
<div id="two">
<p>a</p>
<p>b</p>
<p>c</p>
<p>d</p>
</div>
I want the second grid to have a different gutter width. Or, alternatively, no gutters.
#one { #include row(); }
#two { #include row($gutter: 0); }
This obviously does not work. Because the number of columns can be variable, I cannot add this $gutter:0 declaration to each instance of #include col(). It breaks the DRY principle and eventually (in complicated layouts) becomes unmaintainable.
The question
How can I allow a variable set in one mixin to filter down to another (on a child element)? I am aware that I could simply do this:
#mixin row(){
width: 100%;
overflow: hidden;
.col { etc etc etc }
}
But the class name may not always be .col. Does this make sense? I want the col() mixin to inherit a variable I pass through to the row() mixin. How?
I forked the jsfiddle from Sófka and extended it with the CSS Child selector (">") to target any tags in the row.
// Inside the row mixin
& > * {
#include col($columnWidth, $gutter);
}
Furthermore I added the column width attribute to the mixin and set a default gutter.
$defaultGutter: 1% !default; // Make sure the variable is set
#mixin col($width, $gutter: $defaultGutter){
...
}
See: http://jsfiddle.net/N44LW/12/
PS.:I'm not sure if I fully understood your question, but hopefully this helps.
From the Susy docs: http://susy.oddbird.net/guides/reference/#ref-grid-background
SUSY GRID BACKGROUND
Show the Susy Grid as a background-image on any container.
// susy-grid-background();
.page { #include susy-grid-background; }
If you are using the element as your Container, you need to apply a background to the element in order for this grid-background to size properly.
Snippets of my css:
$total-cols : 16;
$column-width : 4em;
$gutter-width : 1em;
$grid-padding : $gutter-width;
html { background: #fff no-repeat left top; }
.standard {
#include container;
#include susy-grid-background; /* Susy */
and in my Haml:
%body.standard
Whatever I've tried the grid always shows 12 columns. Would anyone be kind enough as to point me in the direction I need to go to get this debug tool to work?
susy (1.0.rc.1)
compass (0.13.alpha.0)
If you have some breakpoints, you also need to address these directly in order to change the number of columns $susy-grid-background shows:
.page {
#include container ($total-columns, $break1, $break2);
#include susy-grid-background;
#include at-breakpoint($break1) {
#include susy-grid-background;
}
#include at-breakpoint($break2) {
#include susy-grid-background;
}
}
$total-cols should be called $total-columns. The name of that variable changed in 1.0. The default setting is 12 columns, and you are not actually overriding that anywhere.