I have specified my grid with rems in Susy and I'm not getting a pixel fallback. I am using Susy 1.0.9 and Compass 0.12.2. The $rem-with-px-fallback var is set to true but I don;t get pixel fallbacks for the span-columns mixin. Any ideas? It's causing issues in IE8 where my column elements are not displaying correctly due to only having rem widths, not even a percentage width is set.
You're right. Susy was designed originally for fluid/magic grids, and it looks like the static option was missed when rem support was added. Feel free to file a bug.
Related
On widths smaller than $max-width, the grid starts from the edge of the viewport. I added some padding to avoid the text from starting from the edge of the viewport, but now it's out of alignment with the grid. How can I make the grid start from the content edge rather than the viewport please?
Unfortunately this is not possible with the current version of Neat (1.8). The good news is that in 2.0 this functionality is baked in, it will be released soon but you can download the latest Beta here:
https://github.com/thoughtbot/neat
UPDATE
Neat 2.0 has now been released where this is included, you can find more info here:
http://neat.bourbon.io/
Be warned a lot of the syntax has changed
Any help is much appreciated. I'm using Sass, Compass and Susy to redesign my website. I'm needing to figure out how I can set up a vertical center in browser. I have a row with five columns and I need to center it vertically.
Here's the HTML:
<div class="layout">
<section></section>
<section></section>
<section></section>
<section></section>
<section></section>
</div>
The sections create the row of columns. I need to center the .layout class vertically.
For any issue like this, start by solving for vertical-centering in CSS. The two best methods I know, only work in modern browsers. The best option is flexbox, followed by a little trick using position and transform. There are other solutions if you search around for "css vertical center".
Both of those require prefixing to work across browsers, which is where Compass might be helpful. Compass has mixins to help with both flexbox and transforms.
I'm trying to position two buttons side-by-side using Susy and this seems to work fine:
.fifty {
#include span-columns(3);
#include nth-omega(2n);
}
However as soon as I ad a 1px border to the button the effective width is 100%+4px and thus it breaks the layout.
I'm using the Compass Vertical Rhythm plugin for all my button padding values so would like not to mess that up.
This is related to "How to include padding in column width with Susy", but your second option is a bit different. This problem isn't specific to Susy - it's true of any fluid layout - But Compass and Susy can help you with the first solution:
Use box-sizing: border-box; - this is now supported by all the major browsers, and Compass has a handy box-sizing() mixin to take care of prefixes for you. If you use it everywhere (like I do), it can change the size of a Susy container, but Susy comes with the handy mixin to fix all that for you. Simply add this at the root, before you set your containers - it will set the box model, and let Susy know to adjust for it:
#include border-box-sizing;
Or just use the Compass box-sizing(border-box) mixin where you want it (on these buttons).
Since borders don't take % values, there is simply no good way to add borders to fluid elements (using the default content-box model). If you can't use the border-box model, the only other option is to add an internal element in the markup, use the outer for sizing, and the inner for borders and styles.
There is a third option - using calc() - but it's harder to do, and has even less browser support...
Option #1 is the best by far - as long as you can leave IE7 out of the fun.
I'm getting strange problem with pie.htc and IE8. I have many elements on page that has rounded corners but pie works only for one element. My CSS is correct - I mean selectors are correctly assigned to pie behavior.
What elese could be wrong?
I have some experience using css3 pie and they have not been great. Here are the fixes i have used:
The elements that you are applying the behavior library too need to be position: relative for a start, so check that first. It may fix it.
If you want it to work in IE6 and 7 you need to add zoom: 1. I know you said you were using IE8 but my customers have said that in the past and it has been in compatibility mode, so always best to add that setting.
CSS 3 Pie does not support browser zooming either on background images so check that you are viewing the website in the 100% view and no other.
Hope that has helped. If you could post a jsfiddle then I could try and help further. If not check the css3pie known issues http://css3pie.com/documentation/known-issues/
Found a solution. Problem was that for these elements was used background with filter. Also css3pie sets background for these elements. After removing this filter everything works fine.
When using a custom font via #font-face, it does render just as I think it should in Chrome. In Firefox, though, additional padding (top and bottom) is added to the font.
Here is my example page that outlines the problem.
Is there anything I can do about it?
FYI, this also happens in Firefox on Linux (and not in Chromium). I tried to load your font in FontForge and immediately got a warning:
The following table(s) in the font have been ignored by FontForge
Ignoring 'LTSH' linear threshold table
Ignoring 'VDMX' vertical device metrics table
Ignoring 'hdmx' horizontal device metrics table
I think the problem is that the VDMX (Vertical Device Metrics) table is defect:
In order to avoid grid fitting the
entire font to determine the correct
height, the VDMX table has been
defined.
This looks exactly like what happens in Firefox: somewhere the minimum and maximum height is incorrectly calculated. This is also clear when you select the text: the selection box extends to the utmost top and bottom of the line; if the h1 element really had padding, you would see a gap between the top and bottom of the line and the selection box.
Also, validation revealed that almost every glyph is “missing points at extrema”:
Both PostScript and TrueType would
like you to have points at the maxima
and minima (the extrema) of a path.
A quick search showed:
The only other problem I had was a
rather nasty condition called "Missing
Points at Extrema". With a font,
there needs to be a point (or node, as
they are called in Inkscape) at the
extreme left, right, top and bottom of
a glyph. Normally they are there
anyway simply because of the way your
glyph is built, but diagonal lines
with rounded ends often cause problems
[source, including picture (scroll down)]
Just Add:
line-height:1;
to your CSS rules