I'm using Susy.
I failed leveraging the content-first approach and decided to go window-px-widths-first
At first i tried the content-first approach to grids, but soon i found my site behaving unexpectedly on different devices. It would display a mobile layout where i wanted a tablet layout, etc. I ended up adjusting em values of Susy settings for them to match certain screen widths (px values). The code got ugly and i realized that i wasn't actually using the content-first approach any more.
Here's a static snapshot of the homepage of a site that i created using this faulty approach and a snapshot of its code.
So i decided to dump the content-first approach completely and use px values in the first place.
Before writing code i formulated requirements for my grid
First of all i grouped different devices by their screen size. Then i came up with px values for breakpoints that are the most appropriate for those device groups:
Break- Layout Number of Common
points name columns usage
(px) (sample)
0 ┬
│
│ S 1 Smartphones-portrait, old phones
│
400 ┼
│ M 2 Smartphones-landscape
600 ┼
│ L 3 Tablets-portrait
800 ┼
│ XL 4 Tablets-landscape, netbooks
1000 ┼
│ XXL 5 Laptops, desktop computers
1200 ┼
↓
I suppose the following assumptions/requirements:
Window-px-widths-first approach (described above).
$container-style is fluid. When screen width is somewhere in between two breakpoints, containers' widths are automatically adjust to match the larger breakpoint. The number of columns in the layout is not changed and corresponds to the lower breakpoint.
The last breakpoint is the containers' max-width. The site won't stretch further, it would have extra gutters instead.
Mobile-first. Start with the "S" layout and override it with other layouts as the screen goes wider.
After a lot of thought my approach evolved to the following code
(This code is a synthetic example. I took excerpts from my actual code and made some adaptations, so it may miss something or have inconsistencies.)
<div id="header-wrapper">
<header id="header">
...
</header>
</div>
<div id="main-wrapper">
<div id="main">
<article id="content">...</article>
<aside id="sidebar">...</aside>
</div>
</div>
<div id="footer-wrapper">
<footer id="footer">
...
</footer>
</div>
/////////////
// Variables
/////////////
$development: true // This enables susy-grid-backgrounds and outlines
// Breakpoints
$bp-s-m: 400px
$bp-m-l: 600px
$bp-l-xl: 800px
$bp-xl-xxl: 1000px
$max-width: 1200px
// Columns
$cols-s: 1
$cols-m: 2
$cols-l: 3
$cols-xl: 4
$cols-xxl: 5
// Layouts
// $layout-s is not necessary due to a mobile-first approach
$layout-m: $bp-s-m $cols-m
$layout-l: $bp-m-l $cols-l
$layout-xl: $bp-l-xl $cols-xl
$layout-xxl: $bp-xl-xxl $cols-xxl
// Default grid settings
$total-columns: $cols-s
$column-width: 85%
$gutter-width: 100% - $column-width
$grid-padding: 1em
$container-width: 100%
$container-style: fluid
+border-box-sizing
/////////////
// Mixins
/////////////
// A couple of mixins to open the developer's third eye
=dev-outline
#if $development
outline: 1px solid red
=dev-grid-bg
+dev-outline
#if $development
+susy-grid-background
// A custom container declaration
=standard-container
+container // ← An actual line of Susy code, yay! :D
// This whole post is actualy an attempt to make use of it.
max-width: $max-width
+dev-grid-bg
+at-breakpoint($layout-m)
+set-container-width
+dev-grid-bg
+at-breakpoint($layout-l)
+set-container-width
+dev-grid-bg
+at-breakpoint($layout-xl)
+set-container-width
+dev-grid-bg
+at-breakpoint($layout-xxl)
+set-container-width
+dev-grid-bg
/////////////
// Backgrounds
/////////////
// The wrapper divs are necessary for screen-wide backgrounds
html
background: url('../images/main-background.png') // also repeat, color, this kind of stuff
#header-wrapper
background: url('../images/header-background.png')
#footer-wrapper
background: url('../images/footer-background.png')
/////////////
// Containers
/////////////
// Actually declared in separate SASS files
#header, #main, #footer
+my-container
/////////////
// Columns
/////////////
// An example of declaring columns
$cols-sidebar: 1
#sidebar-first
+dev-outline
+at-breakpoint($layout-l)
+span-columns($cols-sidebar, $cols-l)
+at-breakpoint($layout-xl)
+span-columns($cols-sidebar, $cols-xl)
+at-breakpoint($layout-xxl)
+span-columns($cols-sidebar, $cols-xxl)
#content
+dev-outline
+at-breakpoint($layout-l)
+span-columns($cols-l - $cols-sidebar omega, $cols-l)
+at-breakpoint($layout-xl)
+span-columns($cols-xl - $cols-sidebar omega, $cols-xl)
+at-breakpoint($layout-xxl)
+span-columns($cols-xxl - $cols-sidebar omega, $cols-xxl)
Here is a static snapshot of the homepage of a site that i created using this approach and snapshot of its code.
Questions
Following the window-px-widths-first approach is my deliberate decision and is a given to the following questions. I appreciate your arguments for content-first, but please do not confine yourself to stating that i'm wrong, please answer the following questions specific to window-px-widths-first.
Is my approach an elegant way of doing window-px-widths-first with Susy or it's an ugly piece of code?
How can i make my code more graceful?
I don't like those numerous at-breakpoint declarations that i have to repeat for every container and every column. I could only think of using a poorly documented possibility of specifying multiple layouts for +container. But as long as +set-container-width is not the only code i do within every media query, even that idea is not an option. :(
What is the recommended way of going window-px-widths-first with Susy (and meeting the requirements i described above)?
Please reveal any shortcomings of my code you find. I'm novice in SASS and i'm sure you can suggest more efficient ways of doing the same stuff.
Not bad, but a few things you could clean up.
First the settings. There's no point in using Susy for a single column, so you could drop your small grid entirely, create it by hand (just padding), and have cleaner code. Once you add multiple columns, your current settings don't make much sense. 2 columns at 85%, with a 15% gutter? That adds up to 185% width. It works, because Susy is actually more interested in the ratio between the numbers, than the numbers themselves, but it's a bit ugly. I would change it to e.g. 85px and 15px or 8.5em and 1.5em. Since you are overriding the container anyway, that shouldn't change anything - just a bit more sensible.
The other main change I would make is to drop all the set-column-width calls, since your width is a 100% fluid override anyway. All it's doing is setting a width of 100% every time. Why bother? With that out of the way, I imagine you could automate the dev-background calls with a simple loop through your breakpoints.
$layouts: $layout-m $layout-l $layout-xl $layout-xxl
#each $layout in $layouts
+at-breakpoint($layout)
+dev-grid-bg
Creating a shortcut to change column-spans at different breakpoints would be difficult on your end or ours, and would add a fair amount of output bloat unless that is really the only change you are making at each size. What you have currently looks good.
Related
Let's say I have three divs: a, b and c, that share a common wrapper div and that I'd like to align as a triptych.
Is it possible to have either b or c have a fixed width (imagine a sidebar with nav), while the other two expand fluidly? Note that the source order matters (a, b, c order). A max-width (rather than fixed) could work fine as well, as long as it supports fluid expansion of the other two divs.
Yes you can! Check out this SassMeister showing fixed and fluid columns.
Now, there are a couple of caveats to this. First, you need fixed width gutters as you can't have gutters in proportion to fluid columns if not all columns are fluid. Second, you need to be using the calc output style from Singularity Extras. This means your columns will be output using CSS3's calc that, while widely available, does require a fallback for browsers that do not support it. Other than that, the calc output style works exactly like the isolation output style.
Last year when the calc output style was introduced, I wrote a blog post titled Bulletproof Combo Fixed and Fluid Grids with CSS Calc explaining in detail about using calc to create fixed and fluid grids and introducing it to Singularity.
I've looked at the documentation for Singularity and it seems the recommended way of having multiple grids is to use the layout mixin, but I have been doing it differently.
when I say multiple grids I'm referring to a page that has different number of columns for different page sections, withing the same media query.
My question is, I have been reusing #include add-grid() in my containers to use multiple grids, is that an acceptable way to use sngularitygs? I have found no examples of using it this way, but it seems to work quite well.
.container {
#include add-grid(16);
}
I'm only seeing the add-grid used to set the global grid, is it unwise to use it for adding another grid inside a container as above?
also I have turning on the bg grid in containers to visualize the nested grids.
.container {
#include sgs-change('debug', true);
#include add-grid(16);
#include background-grid();
}
It seems to work great for visualizing the grid in containers, but I see no usage of these mixins in this way in the docs, any reason this is wrong or is there a better way?
thanks.
Singularity stores grid properties in some internal variable.
Whenever you use add-grid(), this variable is updated with new grid properties.
If you use add-grid() once, all Singularity spanning mixins called below will use that definition.
What happens when you use add-grid() again? It will not affect the code above. But the code below will use the new definition of the grid.
Thus, there are two strategies of using add-grid():
Use it once to set one definition all the time.
If you need different grids, use add-grid() every time before calling a Singularity spanning mixin. This will ensure that each mixin uses an appropriate grid definition.
The latter is probably not an intended way of doing things, but if you've got multiple grids to work with, you've got no other option.
I'm using this approach extensively on the good old Singularity 1.1. But it's much simpler there: the variable that stores grid properties is exposed and can be easily and transparently overridden. I'm not sure about the drawbacks of this with the modern version of Singularity. Grid definitions for specific media-queries may stay unresetted and cause trouble. Gotta dig deeper.
UPD1 2014-06-18
Okay, i seem to have figured it out.
How Singularity stores its settings
Singularity 1.2 stores its settings in the $singularity map. It uses the sgs-get() and sgs-set() functions to access those settings. The funny thing with functions is that you can't use them withough assigning a value somewhere, so you can't do:
sgs-set('foo', 'bar')
You have to assign the result of the function to a dummy variable, even if you're not going to reuse that anywhere:
$dummy: sgs-set('foo', 'bar')
How to manually reassign grid definitions
Grids and gutters are stored under 'grids' and 'gutters' keys of the $singularity map. So in order to mix multiple grids on the same page you have to reset those.
Luckily, there is sgs-reset() that exists both in function and mixin forms.
So before declaring a different grid, you have to reset existing grid:
+sgs-reset(grids)
+sgs-reset(gutters)
+add-grid(2 4 2)
+add-gutter(0.2)
A custom mixin to quickly reassign grids
That is a fair amount of work. You can make it easier with a custom mixin:
=reset-grid($grid: 2, $gutter: 0.1)
+sgs-reset(grids)
+sgs-reset(gutters)
+add-grid($grid)
+add-gutter($gutter)
Here's a usage example:
.container-1
+reset-grid()
#foo
+grid-span(1,1)
#bar
+grid-span(1,2)
.container-2
+reset-grid(1 3 2, 0.2)
#baz
+grid-span(1,1)
#quux
+grid-span(2,2)
Resulting CSS: http://sassmeister.com/gist/21249a9dabf745f892cb
Note that if you use the approach of resetting your grids once in your project, you HAVE to use it everywhere in your project. If you don't apply reset prior to every spanning, you might have unpredictable results.
That's because you no longer have a standard site-wide grid and you have to tell Singularity which grid you mean to use every time you ask Singularity to span anything.
Manually using that mixin inside media queries instead of maintaining a complex grid definition
On the other hand, once you're resetting your grids all the time, you no longer need to define media query-aware grids. I find this to be a relief. Managing the consitency of a complex grids hierarchy can be a nuisance.
.container-1
+reset-grid()
#foo
+grid-span(1,1)
#bar
+grid-span(1,2)
+breakpoint(700px)
+reset-grid(3, 0.2)
#foo
+grid-span(2,1)
#bar
+grid-span(1,2)
Resulting CSS: http://sassmeister.com/gist/19f8ad9dab904cfcabba
A custom mixin to quickly span a thumbnail grid
You can save yourself even more time if you're doing a lot of thumbnail grids, as opposed to page layouts. Here's a mixin that generates a thumbnail grid for a given number of columns (works with symmetrical grids only):
=quick-span($cols, $guts: 0.1, $pseudoclass: child, $center-last-row: 20, $proportional-margins: true)
+reset-grid($cols, $guts)
#for $i from 1 through $cols
&:nth-#{$pseudoclass}(#{$cols}n+#{$i})
+float-span(1, $i)
#if $i == 1
clear: both
#if $proportional-margins
&:nth-last-#{$pseudoclass}(#{$i})
margin-bottom: 0
#if $proportional-margins
margin-bottom: $guts / ( $cols + ($cols - 1) * $guts) * 100%
// Centering the last row
#if $center-last-row and $cols < $center-last-row
#for $i from 1 through $center-last-row
$remainder: $i % $cols
&:nth-#{$pseudoclass}(#{$i - $remainder + 1}):nth-last-child(#{$remainder})
margin-left: grid-span(1, 1) * ($cols - $remainder) / 2
Demo: http://sassmeister.com/gist/62f44e02a2fbb3bd4296
A custom mixin to set up a responsive thumbnail grid with a snap of fingers
Finally, you can put this looping mixin in a one more loop to generate responsive thumbnail grids. Here's an example leveraging Breakpoint Slicer, a syntactic sugar for Breakpoint:
=responsive-span($start-cols: 1, $start-slice: 1, $guts: 0.1)
#for $i from 1 through (total-slices() - $start-slice + 1)
$slice: $start-slice + $i - 1
$cols: $start-cols + $i - 1
+at($slice)
+quick-span($cols, $guts)
A single call of this mixin results in a full-fledged responsive thumbnail grid!
.column
+responsive-span
Demo: http://sassmeister.com/gist/acef490deb922535ef19
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 am working on multiple emails for a client who is using Outlook 2010 version 14 for a PC in their office. No matter how the email is created the right side of the table is blown way out.
For example:
Email #1:
Email #2:
This is the code: view-source:http://fortworth.dmplocal.com/main/index.php?action=viewsenthtml&id=95&ids=e9499cb22fd2fbaee560c877a2716fa0aab6880d
I have done a lot of searching to try and figure out what I could do to fix this, below are some things:
Took all CSS inline
Made sure all cell padding, cell spacing, and borders were set to zero
Specified width for tables
Specified height and width for images
Made sure images were the height and width that is specified in the code
Made images jpg's versus png's
Removed all unnecessary white space
My table is not more than 23.7 inches in height
I have read a lot of forums and found that a lot of people have problems with Outlook as well, but I have not found one that has the big space to the right of the table thus pushing it out that mine has.
Any help would be greatly appreciated!
For HTML tables, specify the width and height using HTML attributes rather than CSS styles. Modern versions of Outlook ignore width and height styles.
As #MarcB mentioned, Outlook 2007/2010/2013 uses the rendering engine of Word to render emails. Previous versions of Outlook used the rendering engine of IE. This shift caused significant changes to the landscape of HTML emails.
Below is a partial list of features not supported by Outlook 2007 and up:
CSS styles
float
position
display
width
height
padding (doesn't work on div and p tags)
background-image (only works on the body tag)
list-style-image
HTML attributes
alt (img)
background (table, th, td)
colspan, rowspan (th, td) (there's conflicting info on this, but it does appear to be supported, as long as a value of 0 is not used; however, it's often recommended to nest tables instead of using colspan and rowspan)
Miscellaneous
Animated GIFs
HTML forms
Try placing /> to close the image tag. This alone worked for me. This is a problem wholly invented by MS. As if it wasn't bad enough before.
#MattCoughlin's answer is right insofar as Outlook code. However, I would also add that Outlook is really specific about column and row counts.
Therefore, check that the number of columns add up. Use empty cells and colspans where necessary.
I just did some edits to your code and put up a fiddle for you to test.
http://jsfiddle.net/YWnzc/135/
But I could't check what I have done in my outlook 2010, but I think there are a lot of limitations in outlook 2010
http://fixoutlook.org/
Let me know how it goes.
further I also see that you have tables nested in your code. I dont hink this is necessary. seeing your mailer design this should be a pretty similar and the pronlem you are reporting should not be there, if it was properly coded.
As for me outlook ignored width of div, so if you code it like:
<div style="width:500px">
<table width="100%">
...
</table>
</div>
the width of table would be expanded to 100%, so try nesting all of fixed width elements inside tables and set fixed with to these parent tables (note that table also needs style), like:
<table width="500px" style="width:500px">
<div style="width:500px">
...
</div>
</table>
this will give you the width needed
Recent convert to RoR and I've been using Compass w/ Blueprint to dip into the proverbial pool. Compass has been fantastic, but I've come across something strange within the Typography library.
The blueprint-typography-body mixin contains the following:
=blueprint-typography-body($font-size: $blueprint-font-size)
line-height: 1.5
+normal-text
font-size: 100% * $font-size / 16px
My question revolves around "font-size." I'm a bit lost, as I would expect to pass in a font size and have that size reflected upon page load. However, in this scenario the formula seems to dictate a percentage against the default font.
ie:
+blueprint-typography-body(10px) //produces 7.5px off of the default font size of 12px from what I can tell.
In essence, I'm curious if there is a standard to setting font size within Compass other than explicitly declaring "font-size: 10px".
Note: The reason I'm leaning towards Blueprint/Compass font stylings is due to the standardization of line-heights, fonts and colors.
To be honest, the compass port of the blueprint typography is not fully configurable yet. So changing that default is probably not going to give you a proper font rhythm.
However, The next release of susy has a fully configurable vertical rhythm module that I helped build and it's pretty nice.
Susy
Vertical Rhythm Module
Just read in the discussion on Compass documentation (Julio Antúnez's comment) that you can adjust font sizes like this:
#import "compass/typography"
$base-font-size: 14px
$base-line-height: 21px
header h1
+adjust-font-size-to(18px)
Not sure this is recommended way but it works for me. I just started using Compass & Blueprint so above might cause problems elsewhere.