Let's say i have a grid of articles (2 columns), inside another column.
What's the best way to achieve this without having to explicitly tell singularity on which column should the article be.
Is it the only option to declare it with pseudo classes?
article:nth-child(1n){
#include grid-span(1,1);
}
article:nth-child(2n){
#include grid-span(1,2);
}
Thanks.
There is an even shorter way than Scott aka user2242314 has suggested above::
$grids: 12;
$gutters: 1/3;
.column {
#include float-span(1);
&:last-child {
#include float-span(1, 'last'); }}
Unfortunately, there's a bug in Singularity that prevents from using this short method, even though it's suggested by Singularity documentation.
I've fixed the bug and submitted a pull request. Wait for Scott or Sam aka Snugug to accept it and release an updated gem (of version 1.0.7 or later). Then run gem update or bundle update and you're able to use the cleanest solution.
You can use the float output style but you are still going to have to deal with the extra padding on your right column.
http://sassmeister.com/gist/5256403 - you may have to select singularity from the drop-down menu to make this link work.
With floats, writing “last” in the location column is equivalent to “omega” in Susy. Dealing with that extra padding is still going to be tricky but at least your columns are floating next to each other without nth.
If you are still unsatisfied, you can write your own output style. Not sure what CSS will do the trick but at any rate, the CSS Singularity generates is completely customizable. I have yet to fully document but you can add your own output styles: https://github.com/Team-Sass/Singularity/tree/1.x.x/stylesheets/singularitygs/api
Related
I use Singluritygs and Breakpoints (with the included respond-to) and I want my global gutter width to change according to those breakpoints.
I thought this would work, but it doesn't:
$breakpoints: add-breakpoint('small', 768px);
#include add-grid(12);
#include add-gutter(1);
#include respond-to('small') {
#include add-gutter(1/2);
}
Am I approaching this the wrong way?
Note that adding a grid does work using this technique:
#include respond-to('small') {
#include grid-span(9, 4);
}
Problem and solution
Singularity is not compatible with Respond-To. Or, to be more precise, Respond-To does not provide functionality required by Singularity.
The correct way of defining responsive gutters is described here and looks like this:
#include add-gutter(.25 at 900px);.
Responsive grids and gutters should be defined on top of your Sass, alongside mobile-first grids and gutters.
Example:
$bp-small: 768px;
#include add-grid(12);
#include add-gutter(1);
#include add-gutter(1/2 at $bp-small);
.foo {
#include float-span(1);
#include breakpoint($bp-small) {
#include float-span(1);
}
}
Demo:
http://sassmeister.com/gist/b49bd305f029afe9cd68
Update 1
davidpauljunior
I thought Singlurity was compatible with respond-to, I'm using it to successfully add new grids - see my added note in the question. The docs say that for reponsive grids use Breakpoint, and Breakpoint includes Repond-to in it (github.com/Team-Sass/breakpoint/wiki/Respond-To).
You were doing it wrong.
Singularity maintains a list of grid definitions for various breakpoints (and another list for gutter definitions). When spanning, Singularity asks Breakpoint for the context (current breakpoint) and retrieves corresponding grid and gutter definitions from lists.
When used with Respond-To, Singularity is unable to retrieve the context and considers that it spans item in the mobile-first context.
Instead populating the grid/gutter definition lists with defintions for each breakpoint, you had only one entry in the list -- the mobile first one.
By reapplying add-gutter() inside a media query, you thought that you were setting the gutter definition for that media query. But instead you were overwriting the mobile-first grid definition globally. And due to Respond-To not reporting context to Singularity, it was using the mobile first definition inside the media query.
This is a valid approach per se. In fact, i've being actively using it with Singularity 1.0. But it has an obvious downside: due to the fact that grid/gutter definitions are overridden globally, you end up needing to reapply add-grid() and add-gutter() before every usage of spanning mixins, otherwise there's a change that Singularity will be using definitions that you don't expect. This is especially the case if you organize your Sass code in a large number of small files.
I suggest that you investigate two extensions that i wrote:
Breakpoint Slicer -- a very quick and efficient syntax for Breakpoint. It's better than Respond-To, and has full support for Singularity.
Singularity Quick Spanner -- a tool with a number of shortcut mixins for Singularity. One of them is designed to ease the approach of reapplying grid/gutter definitions every time.
Update 2
davidpauljunior
I still don't see why if grids can be redefined globally within Respond-to media queries, why gutters can't. Also, you said I only have 1 entry 'the mobile first one', but that entry was the screen size after mobile first (768px).
You have to understand that #include add-gutter(1/2); overwrites the mobile-first gutter definition regardless of whether you execute it inside a media query or not.
Above i have already explained (and provided a link to documentation) how media query-aware grids and gutters should be defined. Repeating:
lolmaus
The correct way of defining responsive gutters is described here and looks like this:
`#include add-gutter(.25 at 900px);`.
This is how your initial attempt actually works: http://sassmeister.com/gist/c530dfe7c249fad254e9 Please study this example and its output, i hope you will understand now.
davidpauljunior
The idea was that for no media query (mobile first) it would take the global gutter, for my first media query (768 and up) I would reset the global gutter and so on. I've set them all using variables now. Perhaps I'm just missing something about Respond-To.
Again, i have already said that this is a valid approach. My last SassMeister link proves that it is already working for your initial attempt.
And Respond-To is suitable for this situation: it doesn't report the media query context to Singularity, but you're not having Singularity take the media query context into account, you're having it use only the mobile-first definition all the time.
Just don't forget to reapply grids and gutters every time you span a new element, just to make sure that you're doing it in the desired context.
You can make the job of resetting the grid/gutter definitions easier with my reset-grid() helper.
I’ve hacked around this before by writing my own mixins, but I get a feeling there must be an inbuilt method in Susy to get around this problem.
I have a mobile-first grid which uses my default $grid-padding, say 1.5em, but once I hit my first breakpoint I switch to a wider $grid-padding-tablet, perhaps 3em, and so on through other breakpoints.
In addition, some elements also use the bleed mixin to give the visual impressions of infinite width.
Is there an easy way, just using something like #include container rather than building my own media queries and mixins to accomplish this?
The built-in technique for this is the with-grid-settings mixin (documentation):
#include at-breakpoint($tablet) {
#include with-grid-settings($padding: $grid-padding-tablet) {
// your tablet code here
}
}
I'm doing my first project with singularity grid system and I'm loving it so far. However, I'm having a strange problem in a section where I have an <h2> and <h3> elements overlapping... really having an hard time figuring what's the problem.
My project in development is available at:
http://senseslabv3.brunomonteiro.mixture.io/
First <section> with class=intro.
Does anyone have a clue about it's going on?
Thanks for your time.
As the others have said, you need to clear your floats. By default, Singularity's output style is "Isolation" which requires a knowledge of how floats should get cleared (clear: left, clear: right, clear: both, clear: none). Singularity assumes no clear (clear: none) which means that grid items may overlap if not properly cleared. It does this to adhere to the most common mental model for the Isolation output method, specifically placing blocks at a discrete point on the grid. Clearing your floats will clear them to an item's margin edge, most visibly by creating new rows. See the Mozilla Developer Network article on Clear.
Note, clearing your floats and clearfixing as proposed by lolmaus actually do different things. Clearing your float will clear items to margin edges, whereas clearfixing an item will ensure that all of its floated children are properly contained.
The Float output adheres to a different mental model, one of walking across a row of your grid, and therefore automatically clears your floats for you. If you'd prefer to use the Float output style as your default, simply add $output: 'float' to your Sass file before calling your grid. This will change your global output style context. Alternatively, you can use float-span to use the Float output style mental model and output on-demand instead of grid-span, or pass $output-style: 'float' as an option to grid-span.
Take a look at the documentation for Output Styles, Output Span, Float Span, and Context Overrides in grid-span for a deeper dive into the different output styles and options available in Singularity.
Clear both needs to be declared somewhere below your grid-span mixin .tag h3 {clear: both;}
instead of the ugly <div style="clear: both;"></div> consider this:
.intro h2 {
#include pie-clearfix; }
Or, if you use toolkit:
.intro h2 {
#extend %clearfix-micro; }
We might better address your problem if you share your SASS code.
This is an old question but I just ran into the problem. Snugug's answer worked perfect but I wanted to show the code that worked for me. (Couldn't put code in a comment)
//Main content container
.l-main {
#include breakpoint(80em) {
#include grid-span(16, 3, 20);
}
}
// A full width banner inside content container. I needed this to clear because there are several other smaller columns/grids above and below the banner.
.b-banner {
#include breakpoint(80em) {
#include float-span(16, 1, last);
}
}
I'm using Compass/Susy for the first time. I'm having an issue when using the #include container mixin. It's automatically applying a clearfix to it. This is not desired. Is there a way to turn this off, or override it?
Yes, you can fork the source of susy and change this file:
https://github.com/ericam/susy/blob/master/sass/susy/_grid.scss
It looks like the pie-clearfix is applied in this mixin: #mixin apply-container
There might be a way to over-write mixins... Or just make another one that is similar to this one - and call that instead.
I have been trying out the Susy plugin for Compass (SASS), but I noticed that it isn't working as intended for me.
I took the index.html and screen.scss from the official Susy tutorial, compiled the SCSS and put it up on my server. As you can see it looks just like it's supposed to (on all browsers I tested it on):
What I did next was the following:
Copy the <article> in the <div role="main"> and paste it six times
In screen.scss, change the column-span (div[role="main"] > article) accordingly: from #include columns(6,9); to #include columns(1,9);
But now those new elements don't align to the grid at all, they are off by a clearly visible space. I tested this in recent versions of FF, Safari and Chrome, and only FF seems to display it correctly. Screenshot is from Chrome:
I also uploaded the source for everyone to inspect here.
Is this a general problem with Susy that the grid isn't correct or am I doing something wrong? If the first, does anybody know a workaround? I also tried with percentages and pixels, but neither worked.
Susy isn't just another grid system like all the others. It was designed to fulfill a very specific purpose: grids that are fluid on the inside. The units you use to create the grid are applied to the container, not to each column. Everything inside is built with percentages. What you are seeing is normal. It's true of all fluid grids, because of sub-pixel rounding. It's not a bug, it's a part of building responsive web sites.
If you need pixel-exact grids, Susy is the wrong tool for you. It all depends what you are trying to build.
Re-size your browser to see how it works. You'll notice the grids snapping-to and floating within a few pixels of their guides, but the grid stays intact and never triggers the horizontal scroll-bar.
Cheers!
-e