From 4b400c50995bbda3d226725a871ccf98d552a28f Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Mon, 26 Jan 2015 11:02:09 +0100 Subject: [PATCH 01/12] Added extra further readings --- en/_sass.md | 1 + en/_syntax.md | 2 ++ en/_tools.md | 1 + 3 files changed, 4 insertions(+) diff --git a/en/_sass.md b/en/_sass.md index e513f020..a6c1f468 100644 --- a/en/_sass.md +++ b/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/) diff --git a/en/_syntax.md b/en/_syntax.md index 7b319841..023f0f50 100644 --- a/en/_syntax.md +++ b/en/_syntax.md @@ -656,6 +656,7 @@ $shadows: $shadows, $shadow ### Further reading +* [Understanding Sass lists](http://hugogiraudel.com/2013/07/15/understanding-sass-lists/) * [SassyLists](http://sassylists.com) @@ -801,6 +802,7 @@ If you are interested in knowing the depth of the map, add the following functio * [Using Sass Maps](http://www.sitepoint.com/using-sass-maps/) * [Debugging Sass Maps](http://www.sitepoint.com/debugging-sass-maps/) +* [Extra Map functions in Sass](http://www.sitepoint.com/extra-map-functions-sass/) * [Real Sass, Real Maps](http://blog.grayghostvisuals.com/sass/real-sass-real-maps/) * [Sass Maps are Awesome](http://viget.com/extend/sass-maps-are-awesome) * [Sass list-maps](https://github.com/lunelson/sass-list-maps) diff --git a/en/_tools.md b/en/_tools.md index 94d1d6a9..bcd44740 100644 --- a/en/_tools.md +++ b/en/_tools.md @@ -32,6 +32,7 @@ Anyway, I do not forbid the use of Compass although I would not recommend it eit * [Compass](http://compass-style.org/) * [Sass Frameworks: Compass or Bourbon](http://www.sitepoint.com/compass-or-bourbon-sass-frameworks/) +* [Why I don't use Compass anymore](http://www.sitepoint.com/dont-use-compass-anymore/) * [Is Compass to Sass with jQuery is to JavaScript?](http://www.sitepoint.com/compass-sass-jquery-javascript/) From 5b3328e0ef6cd0d92cbfeb2f596b15ba4ef4c256 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Mon, 26 Jan 2015 11:05:05 +0100 Subject: [PATCH 02/12] Added something about the syntax toggle in the options panel --- en/_sass.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/_sass.md b/en/_sass.md index a6c1f468..24de9252 100644 --- a/en/_sass.md +++ b/en/_sass.md @@ -57,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 options panel. From 953c86847c9bc28cdf2518bf9db6dd91120c14c6 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Mon, 26 Jan 2015 11:06:33 +0100 Subject: [PATCH 03/12] Added something about randomly ordering CSS declarations --- en/_syntax.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/_syntax.md b/en/_syntax.md index 023f0f50..41e64afe 100644 --- a/en/_syntax.md +++ b/en/_syntax.md @@ -1054,7 +1054,7 @@ I must say I cannot decide myself. A [recent poll on CSS-Tricks](http://css-tric
Chart showing how developers order their CSS declarations
-Because of this, I will not impose a choice in this styleguide. Pick the one you prefer, as long as you are consistent throughout your stylesheets. +Because of this, I will not impose a choice in this styleguide. Pick the one you prefer, as long as you are consistent throughout your stylesheets (i.e. not the *random* option).

A recent study shows that using CSS Comb (which uses type ordering) for sorting CSS declarations ends up shortening the average file size under Gzip compression by 2.7%, compared to 1.3% when sorting alphabetically.

From c05b985e631ac1422496d3ffa88439f71e5699bc Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Wed, 4 Feb 2015 22:50:24 +0100 Subject: [PATCH 04/12] Added something about reversed conditional statements --- en/_conditions.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/en/_conditions.md b/en/_conditions.md index 9f05cb74..1dc2e807 100644 --- a/en/_conditions.md +++ b/en/_conditions.md @@ -76,6 +76,35 @@ When testing for a falsy value, always use the `not` keyword rather than testing
+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. + +
+
+{% highlight scss %} +// Yep +@if $value == 42 { + // ... +} + +// Nope +@if 42 == $value { + // ... +} +{% endhighlight %} +
+
+{% highlight sass %} +// Yep +@if $value == 42 + // ... + +// Nope +@if 42 == $value + // ... +{% endhighlight %} +
+
+ 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.
From 3eb5594406a80d4828633d30042e026f661b978e Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Mon, 26 Jan 2015 11:25:00 +0100 Subject: [PATCH 05/12] Added a link to open the options panel on the 'options panel' expression --- en/_sass.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/_sass.md b/en/_sass.md index 24de9252..352f0bc7 100644 --- a/en/_sass.md +++ b/en/_sass.md @@ -57,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, SCSS is the default syntax throughout these guidelines. You can switch to Sass indented syntax in the options panel. +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 options panel. From b970155aaca772c124caf48635328fa72b311715 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Mon, 9 Feb 2015 22:56:01 +0100 Subject: [PATCH 06/12] Added something about strings containing quotes --- en/_syntax.md | 29 ++++++++++++++++++++++++++++- en/_toc.md | 2 ++ 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/en/_syntax.md b/en/_syntax.md index 41e64afe..56267186 100644 --- a/en/_syntax.md +++ b/en/_syntax.md @@ -55,7 +55,7 @@ CSS does not require strings to be quoted, not even those containing spaces. Tak Because of this, Sass *also* does not require strings to be quoted. Even better (and *luckily*, you’ll concede), a quoted string is strictly equivalent to its unquoted twin (e.g. `'abc'` is strictly equal to `abc`). -That being said, languages that do not require strings to be quoted are definitely a minority and so, **strings should always be wrapped with single quotes** in Sass (single being easier to type than double on *qwerty* keyboards). Besides consistency with other languages, including CSS’ cousin JavaScript, there are several reasons for this choice: +That being said, languages that do not require strings to be quoted are definitely a minority and so, **strings should always be wrapped with single quotes** (`'`) in Sass (single being easier to type than double on *qwerty* keyboards). Besides consistency with other languages, including CSS’ cousin JavaScript, there are several reasons for this choice: * color names are treated as colors when unquoted, which can lead to serious issues; * most syntax highlighters will choke on unquoted strings; @@ -93,6 +93,33 @@ $font-stack: Helvetica Neue Light, Helvetica, Arial, sans-serif

In the previous example, sans-serif is not being quoted because it is a specific CSS value that needs to be unquoted.

+### Strings containing quotes + +If a string contains one or several single quotes, one might consider wrapping the string with double quotes (`"`) instead, in order to avoid escaping too many characters within the string. + +
+
+{% highlight scss %} +// Okay +@warn 'You can\'t do that.'; + +// Okay +@warn "You can't do that."; +{% endhighlight %} +
+
+{% highlight sass %} +// Okay +@warn 'You can\'t do that.' + +// Okay +@warn "You can't do that." +{% endhighlight %} +
+
+ +### URLs + URLs should be quoted as well, for the same reasons as above:
diff --git a/en/_toc.md b/en/_toc.md index 7a50345e..c0881680 100644 --- a/en/_toc.md +++ b/en/_toc.md @@ -13,6 +13,8 @@ * [Key Principles](#key-principles) * [Syntax & Formatting](#syntax-&-formatting) * [Strings](#strings) + * [Strings containing quotes](#strings-containing-quotes) + * [URLs](#urls) * [Numbers](#numbers) * [Zeros](#zeros) * [Units](#units) From 3c86c3670163dd3e4b1e526454a37b3255296e11 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Fri, 13 Feb 2015 14:55:20 +0100 Subject: [PATCH 07/12] Added a distinction between CSS strings and Sass strings --- en/_syntax.md | 45 +++++++++++++++++++++++++++++++++++---------- en/_toc.md | 1 + 2 files changed, 36 insertions(+), 10 deletions(-) diff --git a/en/_syntax.md b/en/_syntax.md index 56267186..a0de1dd4 100644 --- a/en/_syntax.md +++ b/en/_syntax.md @@ -66,32 +66,57 @@ That being said, languages that do not require strings to be quoted are definite
{% highlight scss %} // Yep -$font-stack: 'Helvetica Neue Light', 'Helvetica', 'Arial', sans-serif; +$direction: 'left'; // Nope -$font-stack: "Helvetica Neue Light", "Helvetica", "Arial", sans-serif; +$direction: left; +{% endhighlight %} +
+
+{% highlight sass %} +// Yep +$direction: 'left' + +// Nope +$direction: left +{% endhighlight %} +
+
+ +### Strings as CSS values + +Specific CSS values such as `initial` or `sans-serif` require not to be quoted. Indeed, the declaration `font-family: 'sans-serif'` will silently fail because CSS is expecting an identifier, not a quoted string. Because of this, we do not quote those values. + +
+
+{% highlight scss %} +// Yep +$font-type: sans-serif; // Nope -$font-stack: Helvetica Neue Light, Helvetica, Arial, sans-serif; +$font-type: 'sans-serif'; + +// Okay I guess +$font-type: unquote('sans-serif'); {% endhighlight %}
{% highlight sass %} // Yep -$font-stack: 'Helvetica Neue Light', 'Helvetica', 'Arial', sans-serif +$font-type: sans-serif // Nope -$font-stack: "Helvetica Neue Light", "Helvetica", "Arial", sans-serif +$font-type: 'sans-serif' -// Nope -$font-stack: Helvetica Neue Light, Helvetica, Arial, sans-serif +// Okay I guess +$font-type: unquote('sans-serif') {% endhighlight %}
-
-

In the previous example, sans-serif is not being quoted because it is a specific CSS value that needs to be unquoted.

-
+Hence, we can make a distinction between strings intended to be used as CSS values (CSS identifiers) like in the previous example, and strings when sticking to the Sass data type, for instance map keys. + +We don't quote the former, but we do wrap the latter in single quotes. ### Strings containing quotes diff --git a/en/_toc.md b/en/_toc.md index c0881680..fecd8d59 100644 --- a/en/_toc.md +++ b/en/_toc.md @@ -13,6 +13,7 @@ * [Key Principles](#key-principles) * [Syntax & Formatting](#syntax-&-formatting) * [Strings](#strings) + * [Strings as CSS values](#strings-as-css-values) * [Strings containing quotes](#strings-containing-quotes) * [URLs](#urls) * [Numbers](#numbers) From 8fcd96d4bef61006ec34f6e34a3c8676f8fa4463 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Fri, 13 Feb 2015 15:12:10 +0100 Subject: [PATCH 08/12] Reworked the rules for Sass lists --- en/_mixins.md | 16 ++++++++-------- en/_naming.md | 8 ++++---- en/_syntax.md | 39 +++++++++++++++++++++------------------ 3 files changed, 33 insertions(+), 30 deletions(-) diff --git a/en/_mixins.md b/en/_mixins.md index 2748388e..5fdf4362 100644 --- a/en/_mixins.md +++ b/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 %} @@ -246,14 +246,14 @@ Then using this mixin should be very straightforward:
{% highlight scss %} .foo { - @include prefix(transform, rotate(90deg), webkit ms); + @include prefix(transform, rotate(90deg), ('webkit', 'ms')); } {% endhighlight %}
{% highlight sass %} .foo - +prefix(transform, rotate(90deg), webkit ms) + +prefix(transform, rotate(90deg), ('webkit', 'ms')) {% endhighlight %}
diff --git a/en/_naming.md b/en/_naming.md index 610f537f..dfab5175 100644 --- a/en/_naming.md +++ b/en/_naming.md @@ -61,19 +61,19 @@ As for many languages, I suggest all-caps snakerized variables when they are con
{% 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 %}
{% 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 %}
diff --git a/en/_syntax.md b/en/_syntax.md index a0de1dd4..dc9cba53 100644 --- a/en/_syntax.md +++ b/en/_syntax.md @@ -627,28 +627,30 @@ Lists are the Sass equivalent of arrays. A list is a flat data structure (unlike Lists should respect the following guidelines: -* unless it is too long to fit on an 80-character line, always display it on a single line; -* unless it is used as is for CSS purposes, always use comma as a delimiter; -* unless it is empty or nested within another list, never write the parenthesis; -* never add a trailing comma. +* either inlined or multilines; +* necessarily on multilines if too long to fit on an 80-character line; +* unless used as is for CSS purposes, always comma separated; +* always wrapped in parenthesis; +* trailing comma if multilines, not if inlined.
{% highlight scss %} // Yep -$font-stack: 'Helvetica', 'Arial', sans-serif; +$font-stack: ('Helvetica', 'Arial', sans-serif); -// Nope -$font-stack: +// Yep +$font-stack: ( 'Helvetica', 'Arial', - sans-serif; + sans-serif, +); // Nope $font-stack: 'Helvetica' 'Arial' sans-serif; // Nope -$font-stack: ('Helvetica', 'Arial', sans-serif); +$font-stack: 'Helvetica', 'Arial', sans-serif; // Nope $font-stack: ('Helvetica', 'Arial', sans-serif,); @@ -657,22 +659,23 @@ $font-stack: ('Helvetica', 'Arial', sans-serif,);
{% highlight sass %} // Yep -$font-stack: 'Helvetica', 'Arial', sans-serif +$font-stack: ('Helvetica', 'Arial', sans-serif) -// Nope (since it is not supported) -$font-stack: +// Nope (not supported) +$font-stack: ( 'Helvetica', 'Arial', - sans-serif + sans-serif, +) // Nope -$font-stack: 'Helvetica' 'Arial' sans-serif +$font-stack: 'Helvetica' 'Arial' sans-serif; // Nope -$font-stack: ('Helvetica', 'Arial', sans-serif) +$font-stack: 'Helvetica', 'Arial', sans-serif; // Nope -$font-stack: ('Helvetica', 'Arial', sans-serif,) +$font-stack: ('Helvetica', 'Arial', sans-serif,); {% endhighlight %}
@@ -682,7 +685,7 @@ When adding new items to a list, always use the provided API. Do not attempt to
{% highlight scss %} -$shadows: 0 42px 13.37px hotpink; +$shadows: (0 42px 13.37px hotpink); // Yep $shadows: append($shadows, $shadow, comma); @@ -693,7 +696,7 @@ $shadows: $shadows, $shadow;
{% highlight sass %} -$shadows: 0 42px 13.37px hotpink +$shadows: (0 42px 13.37px hotpink); // Yep $shadows: append($shadows, $shadow, comma) From dbc68ea8ef78c745f29899454cedc3932a68a693 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Mon, 16 Feb 2015 22:31:40 +0100 Subject: [PATCH 09/12] Added something about UTF-8 encoding --- en/_syntax.md | 21 +++++++++++++++++++++ en/_toc.md | 2 ++ 2 files changed, 23 insertions(+) diff --git a/en/_syntax.md b/en/_syntax.md index dc9cba53..dbe393aa 100644 --- a/en/_syntax.md +++ b/en/_syntax.md @@ -51,6 +51,27 @@ We will not tackle the question of file organization in this section. It is the ## Strings +Believe it or not, strings play quite a large role in both CSS and Sass ecosystems. Most CSS values are either lengths or strings (usually unquoted), so it actually is quite crucial to stick to some guidelines when dealing with strings in Sass. + +### Encoding + +To avoid any potential issue with character encoding, it is highly recommended to force [UTF-8](http://en.wikipedia.org/wiki/UTF-8) encoding in the [main stylesheet](#main-file) using the `@charset` directive. Make sure it is the very first element of the stylesheet and there is no character of any kind before it. + +
+
+{% highlight scss %} +@charset 'utf-8'; +{% endhighlight %} +
+
+{% highlight sass %} +@charset 'utf-8' +{% endhighlight %} +
+
+ +### Quotes + CSS does not require strings to be quoted, not even those containing spaces. Take font-family names for instance: it doesn’t matter whether you wrap them in quotes for the CSS parser. Because of this, Sass *also* does not require strings to be quoted. Even better (and *luckily*, you’ll concede), a quoted string is strictly equivalent to its unquoted twin (e.g. `'abc'` is strictly equal to `abc`). diff --git a/en/_toc.md b/en/_toc.md index fecd8d59..1375ece5 100644 --- a/en/_toc.md +++ b/en/_toc.md @@ -13,6 +13,8 @@ * [Key Principles](#key-principles) * [Syntax & Formatting](#syntax-&-formatting) * [Strings](#strings) + * [Encoding](#encoding) + * [Quotes](#quotes) * [Strings as CSS values](#strings-as-css-values) * [Strings containing quotes](#strings-containing-quotes) * [URLs](#urls) From a27553e0051e35d7d64ad595b4e3e9aea2232fa9 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Wed, 18 Feb 2015 14:01:59 +0100 Subject: [PATCH 10/12] Improved respond-to mixin to make it slightly more robust --- en/_rwd.md | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/en/_rwd.md b/en/_rwd.md index 5abf2b50..01268e9e 100644 --- a/en/_rwd.md +++ b/en/_rwd.md @@ -62,6 +62,10 @@ $breakpoints: ('seed': (min-width: 800px), 'sprout': (min-width: 1000px), 'plant
+
+

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. '(min-width: 800px)').

+
+ @@ -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
-

Obviously, this is a fairly simplistic breakpoint manager that will not do the trick when dealing with custom and/or multiple-checks breakpoints.

-

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 Sass-MQ, Breakpoint or include-media.

+

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 Sass-MQ, Breakpoint or include-media.

From 3e5743c31f3e5909fdbf497b75687b834b95ec17 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Thu, 19 Mar 2015 22:34:46 +0100 Subject: [PATCH 11/12] Updated author bio --- en/_author.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/_author.md b/en/_author.md index 4a971b26..d6e70d94 100644 --- a/en/_author.md +++ b/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). From 3e303c2641e47c9e997a034d1d2f19926298e865 Mon Sep 17 00:00:00 2001 From: Hugo Giraudel Date: Sat, 11 Apr 2015 22:53:08 +0200 Subject: [PATCH 12/12] Bumped version to 1.1.0 --- _data/languages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_data/languages.yml b/_data/languages.yml index efea62bc..045c9e71 100644 --- a/_data/languages.yml +++ b/_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