Historical errata for Pragmatic Guide to Sass

“of is” in the following sentence:

The grand aim of is SCSS to keep the look of CSS while introducing the units of Sass.

It appears that a period should follow CSS in the following sentence(s).

It stands for Sassy CSS If you’re familiar with CSS, it’s pretty easy to read.

Under #9 “Creating Themes with Advanced Colors”, in page# 22, the second half of the page has code that looks like this:

#page {
adjust-hue($main_color, 180); }

I think this should be

#page {
color: adjust-hue($main_color, 180); }

This style occurs twice.

Also, the same page has the following:

grayscale(#336699);
->
desaturate(#336699, 100%);

The “->” is misleading (thought what follows after that symbol was meant to be the final css). I think both are equivalent to get the same output, and so can be changed to something like:

grayscale(#336699);
[OR]
desaturate(#336699, 100%);
->
color: #666666;

I thought we could talk about two more things while talking about mixins:

1. the ability to accept default parameter/descriptor values
2. the original sass syntax of using “=” instead of “@mixin”

I have illustrated both in the below snippet:

=blue_text($size : 20px)
color: $main_color
font-family: $helvetica
font-size: $size
font-variant: small-caps

.product_title
+blue_text —> uses 20px, the default value

.product_summary
+blue_text(15px)

Hope this would help.

“We’ve worked really hard on the Sass development team to make sure that the error messages make as much sense as possible.”

Shouldn’t this be:

“We’ve worked really hard to make sure that the error messages make as much sense as possible.”
OR
“We, the Sass development team, have worked really hard to make sure that the error messages make as much sense as possible.”
OR
“[We, ]The Sass development team, have worked really hard on the error messages to make sure that they make as much sense as possible.”

“worked really hard on the Sass development team” — doesn’t it mean working hard ON the team rather than the intended meaning of “The team worked hard”. Or is my [Queen’s-Indian] English not up to the mark? :)

Might be better to introduce variable/parameter interpolation? The associated code in page# 43 has this:

filter: alpha(opacity=#{$opacity})

Are we assuming that readers will know Ruby and so would understand “#{$opacity}”? I have read other sources and know that interpolation is available in Sass (similar to in Ruby strings). But not everyone would know, right?

Can you provide some [1 or 2 line] guidance in the book on when @each should be preferred and when a mixin should be preferred? For instance, I could achieve the same using this:

=member_info($member)
.#{$member}_picture
background-image: url(“/image/#{$member}.jpg”)

+member_info(thom)
+member_info(jonny)
+member_info(colin)
+member_info(phil)

Yes, there is copy-paste, but the advantage is I can move the mixin to a separate file, isn’t it?

There is a line that reads (in my pdf on a Ubuntu 10.10 box using Document Viewer v2.32.0):

“For example, 20 10 would evaluate to true.”

I think an operator is missing.. may be “>”?

In the code for section 21, for the last two snippets (portrait and landscape), we are missing indentation for the last line:

@media screen and (max-width: 320px)
font-size: 35px

@media screen and (min-width: 321px) and (max-width: 480px)
font-size: 25px

I know this must be a typo, but since it affects the final output (without indentation, the @media is stripped out from the generated css), I am logging this as a Tech Error.

I am on Compass 0.11.5 (Antares).

In the horizontal list, when I don’t pass any params, I am getting the padding as 4px, as against the 10px in the book. What gives?

@import compass/typography/lists/horizontal-list
ul.horiz
+horizontal-list

->

ul.horiz li {
// more lines here…
padding-left: 4px;
padding-right: 4px;
}

This line can be improved? “use” is used twice and the sentence somehow doesn’t gel.

“Within the HTML we have to use to describe the sticky footer, there are three pre-defined selectors that we use in this mixin —root, root_footer and footer.”

I am relatively new to CSS/Sass/Compass/Sprites. I have been having a tough time getting the Sprites thing to work. It would be great if there is a bit more detail available as to how to set up the project (e.g. there should be an images folder, inside which the icon folder should go, and so on). Also, if there are any other pre-requisites, it would be useful to have them listed out as well.

I am on:
Sass 3.1.5 (Brainy Betty)
Haml 3.1.2 (Separated Sally)
Compass 0.11.5 (Antares)

My code in the sass file is:

import compass //import icon/*.png
@import sprites/icon
+all-icon-sprites

I tried setting up the images/icon/*.png, then tried with the commented line above, and since it didn’t work, switched to trying out “compass sprite” command, and tried with the above version. [That command didn’t create anything other than the file sass/sprites/_icon.scss].

The error messages I get are (at different times, when I tried the aforementioned things):

error sass/spritest.sass (Line 18: Invalid CSS after “…$icon-clean-up,”: expected function argument, was “);”)

NoMethodError on line [“24”] of /home/proto/.rvm/gems/ruby-1.9.2-p180@rails3/gems/chunky_png-1.2.1/lib/chunky_png/chunk.rb: undefined method `unpack’ for nil:NilClass

Since it is quite possible that others too might face this issue, would be great if you can provide a bit more details (and gotchas). Thanks!

The second sentence in the “SCSS: A More CSS-like Way to Write Sass” section should read “The grand aim of SCSS is to keep the look of CSS while introducing the units of Sass.” instead of “The grand aim of is SCSS to keep the look of CSS while introducing the units of Sass.”

Last sentence, first paragraph reads:

“If you want to remove only one bullet point, just @includeno-bullet in the class.”

Missing the space between “@include” and “no-bullet”.

" Just place your comment between /* and */. These comments can be on multiple lines.

One will only show up in the Sass document, and the other will be incorporated into the CSS that’s compiled."

This doesn’t seem to be true, if you are compiling with Scout to compressed output style, no matter if production or deployment has been chosen as environment.

Convert a CSS file to a Sass file
should read: sass-convert test.css test.sass
not: sass convert test.css test.sass

Note the hyphen is required in lieu of the space

In the second paragraph, includeellipsis is missing a space after include. - RR

First paragraph: |product|variable is missing a space. - RR

The SCSS example has one too many } at the end.

so :
color: $primary_color; } } }

should be:
color: $primary_color; } }

In the section talking about @extend, the code listed reads

.checkout_button {
@extend .blue_button;
color: darken(#336699, 10%);
}

However, that code, as it stands, produces nigh-unreadable code, and anyone that’s blue colorblind can just forget it. I believe the effect he was looking for is better expressed

.checkout_button {
@extend .blue_button;
background-color: darken(#336699, 10%);
}

which should render the proper effect.