[RFR] 1.1.0

_data/languages.yml

@@ -28,7 +28,7 @@ nl:
       link: https://github.com/ttomdewit
 
 en:
-  version: 1.0.0
+  version: 1.1.0
   label: English
   prefix: /
   available: true

en/_author.md

@@ -1,7 +1,7 @@
 
 # About the author
 
-My name is [Hugo Giraudel](http://hugogiraudel.com), I am a front-end developer from France about to move to Berlin, Germany. I have been writing Sass for over two years now and am the author of Sass-related projects such as [SassDoc](http://sassdoc.com) and [Sass-Compatibility](http://sass-compatibility.github.io).
+My name is [Hugo Giraudel](http://hugogiraudel.com), I am a French front-end developer based in Berlin, Germany. I have been writing Sass for over two years now and am the author of Sass-related projects such as [SassDoc](http://sassdoc.com) and [Sass-Compatibility](http://sass-compatibility.github.io). I also wrote a book about CSS (in French) entitled [CSS3 Pratique du Design Web](http://www.amazon.fr/dp/2212140231).
 
 I have also written a couple of Sass libraries, mostly for the heck of it: [SassyJSON](https://github.com/HugoGiraudel/SassyJSON), [SassyLists](http://sassylists.com), [SassySort](https://github.com/HugoGiraudel/SassySort), [SassyCast](https://github.com/HugoGiraudel/SassyCast), [SassyMatrix](https://github.com/HugoGiraudel/SassyMatrix), [SassyBitwise](https://github.com/HugoGiraudel/SassyBitwise), [SassyIteratorsGenerators](https://github.com/HugoGiraudel/SassyIteratorsGenerators), [SassyLogger](https://github.com/HugoGiraudel/SassyLogger), [SassyStrings](https://github.com/HugoGiraudel/SassyStrings) and [SassyGradients](https://github.com/HugoGiraudel/SassyGradients).
 

en/_conditions.md

@@ -76,6 +76,35 @@ When testing for a falsy value, always use the `not` keyword rather than testing
   </div>
 </div>
 
+Always put the variable part on the left side of the statement, and the (un)expected result on the right. Reversed conditional statements often are more difficult to read, especially to unexperienced developers.
+
+<div class="code-block">
+  <div class="code-block__wrapper" data-syntax="scss">
+{% highlight scss %}
+// Yep
+@if $value == 42 {
+  // ...
+}
+
+// Nope
+@if 42 == $value {
+  // ...
+}
+{% endhighlight %}
+  </div>
+  <div class="code-block__wrapper" data-syntax="sass">
+{% highlight sass %}
+// Yep
+@if $value == 42
+  // ...
+
+// Nope
+@if 42 == $value
+  // ...
+{% endhighlight %}
+  </div>
+</div>
+
 When using conditional statements within a function to return a different result based on some condition, always make sure the function still has a `@return` statement outside of any conditional block.
 
 <div class="code-block">

en/_mixins.md

@@ -123,18 +123,18 @@ Sass is actually pretty clever with mixins and function declarations, so much so
 @include dummy(true, 42, 'kittens');
 
 // Yep but nope
-$params: true, 42, 'kittens';
+$params: (true, 42, 'kittens');
 $value: dummy(nth($params, 1), nth($params, 2), nth($params, 3));
 
 // Yep
-$params: true, 42, 'kittens';
+$params: (true, 42, 'kittens');
 @include dummy($params...);
 
 // Yep
 $params: (
   'c': 'kittens',
   'a': true,
-  'b': 42
+  'b': 42,
 );
 @include dummy($params...);
 {% endhighlight %}
@@ -148,15 +148,15 @@ $params: (
 +dummy(true, 42, 'kittens')
 
 // Yep but nope
-$params: true, 42, 'kittens'
+$params: (true, 42, 'kittens')
 $value: dummy(nth($params, 1), nth($params, 2), nth($params, 3))
 
 // Yep
-$params: true, 42, 'kittens'
+$params: (true, 42, 'kittens')
 +dummy($params...)
 
 // Yep
-$params: ( 'c': 'kittens', 'a': true, 'b': 42, )
+$params: ('c': 'kittens', 'a': true, 'b': 42,)
 +dummy($params...)
 {% endhighlight %}
   </div>
@@ -246,14 +246,14 @@ Then using this mixin should be very straightforward:
   <div class="code-block__wrapper" data-syntax="scss">
 {% highlight scss %}
 .foo {
-  @include prefix(transform, rotate(90deg), webkit ms);
+  @include prefix(transform, rotate(90deg), ('webkit', 'ms'));
 }
 {% endhighlight %}
   </div>
   <div class="code-block__wrapper" data-syntax="sass">
 {% highlight sass %}
 .foo
-  +prefix(transform, rotate(90deg), webkit ms)
+  +prefix(transform, rotate(90deg), ('webkit', 'ms'))
 {% endhighlight %}
   </div>
 </div>

en/_naming.md

@@ -61,19 +61,19 @@ As for many languages, I suggest all-caps snakerized variables when they are con
   <div class="code-block__wrapper" data-syntax="scss">
 {% highlight scss %}
 // Yep
-$CSS_POSITIONS: top, right, bottom, left, center;
+$CSS_POSITIONS: (top, right, bottom, left, center);
 
 // Nope
-$css-positions: top, right, bottom, left, center;
+$css-positions: (top, right, bottom, left, center);
 {% endhighlight %}
   </div>
   <div class="code-block__wrapper" data-syntax="sass">
 {% highlight sass %}
 // Yep
-$CSS_POSITIONS: top, right, bottom, left, center
+$CSS_POSITIONS: (top, right, bottom, left, center)
 
 // Nope
-$css-positions: top, right, bottom, left, center
+$css-positions: (top, right, bottom, left, center)
 {% endhighlight %}
   </div>
 </div>

en/_rwd.md

@@ -62,6 +62,10 @@ $breakpoints: ('seed': (min-width: 800px), 'sprout': (min-width: 1000px), 'plant
   </div>
 </div>
 
+<div class="note">
+  <p>The previous examples uses nested maps to define breakpoints, however this really depends on what kind of breakpoint manager you use. You could opt for strings rather than inner maps for more flexibility (e.g. <code>'(min-width: 800px)'</code>).</p>
+</div>
+
 
 
 
@@ -86,8 +90,12 @@ Once you have named your breakpoints the way you want, you need a way to use the
 /// @param {String} $breakpoint - Breakpoint
 /// @requires $breakpoints
 @mixin respond-to($breakpoint) {
-  @if map-has-key($breakpoints, $breakpoint) {
-    @media #{inspect(map-get($breakpoints, $breakpoint))} {
+  $raw-query: map-get($breakpoints, $breakpoint);
+
+  @if $raw-query {
+    $query: if(type-of($raw-query) == 'string', unquote($raw-query), inspect($raw-query));
+
+    @media #{$query} {
       @content;
     }
   } @else {
@@ -104,8 +112,12 @@ Once you have named your breakpoints the way you want, you need a way to use the
 /// @param {String} $breakpoint - Breakpoint
 /// @requires $breakpoints
 =respond-to($breakpoint)
-  @if map-has-key($breakpoints, $breakpoint)
-    @media #{inspect(map-get($breakpoints, $breakpoint))}
+  $raw-query: map-get($breakpoints, $breakpoint)
+
+  @if $raw-query
+    $query: if(type-of($raw-query) == 'string', unquote($raw-query), inspect($raw-query))
+
+    @media #{$query}
       @content
 
   @else
@@ -116,8 +128,7 @@ Once you have named your breakpoints the way you want, you need a way to use the
 </div>
 
 <div class="note">
-  <p>Obviously, this is a fairly simplistic breakpoint manager that will not do the trick when dealing with custom and/or multiple-checks breakpoints.</p>
-  <p>If you need a slightly more permissive breakpoint manager, may I recommend you do not reinvent the wheel and use something that has been proven effective such as <a href="https://github.com/sass-mq/sass-mq">Sass-MQ</a>, <a href="http://breakpoint-sass.com/">Breakpoint</a> or <a href="https://github.com/eduardoboucas/include-media">include-media</a>.</p>
+  <p>Obviously, this is a fairly simplistic breakpoint manager. If you need a slightly more permissive one, may I recommend you do not reinvent the wheel and use something that has been proven effective such as <a href="https://github.com/sass-mq/sass-mq">Sass-MQ</a>, <a href="http://breakpoint-sass.com/">Breakpoint</a> or <a href="https://github.com/eduardoboucas/include-media">include-media</a>.</p>
 </div>
 
 

en/_sass.md

@@ -38,6 +38,7 @@ On non-Ruby projects that need a workflow integration, LibSass is probably a bet
 ### Further reading
 
 * [LibSass](https://github.com/sass/libsass)
+* [Getting to know LibSass](http://webdesign.tutsplus.com/articles/getting-to-know-libsass--cms-23114)
 * [Sass-Compatibility](http://sass-compatibility.github.io)
 * [Switching from Ruby Sass to LibSass](http://www.sitepoint.com/switching-ruby-sass-libsass/)
 
@@ -56,7 +57,7 @@ Since then, Sass (the preprocessor) has been providing two different syntaxes: S
 
 Sass’s whitespace-sensitive syntax relies on indentation to get rid of braces, semi-colons and other punctuation symbols, leading to a leaner and shorter syntax. Meanwhile, SCSS is easier to learn since it’s mostly some tiny extra bits on top of CSS.
 
-I, myself, prefer SCSS over Sass because it is closer to CSS and friendlier to most developers. Because of that, I will use SCSS rather than Sass throughout these guidelines.
+I, myself, prefer SCSS over Sass because it is closer to CSS and friendlier to most developers. Because of that, SCSS is the default syntax throughout these guidelines. You can switch to Sass indented syntax in the <span data-toggle="aside" class="link-like" role="button" aria-expanded>options panel</span>.