diff --git a/posts/2008-04-08-impressum.markdown b/posts/2008-04-08-impressum.markdown new file mode 100644 index 0000000..3c00aa1 --- /dev/null +++ b/posts/2008-04-08-impressum.markdown @@ -0,0 +1,28 @@ +--- +title: Impressum +slug: impressum +author: tim_schneider +published: true +author_name: Tim +author_email: tim@railslove.com +author_url: http://railslove.com +wordpress_id: 13 +wordpress_url: http://blog.railslove.com/?page_id=13 +published_at: 2008-04-08 10:43:48.000000000 +02:00 +categories: +- railslove +--- +Railslove GbR +Michael Bumann, Jan Kus, Tim Schneider + +Gothaer Allee 2 +50969 Köln + +Tel.: +49 176 - 22 74 78 93 +Fax: +49 1803 622229 12790 + +E-Mail: team@railslove.com + +Inhaltlich Verantwortliche gemäß TMG und § 55 Abs. 2 RStV: Michael Bumann, Jan Kus und Tim Schneider (Anschrift wie oben) + +Haftungshinweis: Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich. diff --git a/posts/2012-03-28-smacss-and-sass-the-future-of-stylesheets.markdown b/posts/2012-03-28-smacss-and-sass-the-future-of-stylesheets.markdown index 3f07c3b..2d40262 100644 --- a/posts/2012-03-28-smacss-and-sass-the-future-of-stylesheets.markdown +++ b/posts/2012-03-28-smacss-and-sass-the-future-of-stylesheets.markdown @@ -1,30 +1,29 @@ ---- -title: SMACSS and SASS - The future of stylesheets -slug: smacss-and-sass-the-future-of-stylesheets -author: jakob_hilden -featured_image: http://smacss.com/img/book-covers.png -published: true -author_name: jakob -author_email: jakob@railslove.com -wordpress_id: 1318 -wordpress_url: http://blog.railslove.com/?p=1318 -published_at: 2012-03-28 18:15:20.000000000 +02:00 -categories: -- railslove -- rails -- oss -- css -- sass -tags: - keyword: - - smacss - - sass - - css - - stylesheets - - frontend - - modular - - conventions ---- +--- +title: SMACSS and SASS - The future of stylesheets +slug: smacss-and-sass-the-future-of-stylesheets +author: jakob_hilden +published: true +author_name: jakob +author_email: jakob@railslove.com +wordpress_id: 1318 +wordpress_url: http://blog.railslove.com/?p=1318 +published_at: 2012-03-28 18:15:20.000000000 +02:00 +categories: +- railslove +- rails +- oss +- css +- sass +tags: + keyword: + - smacss + - sass + - css + - stylesheets + - frontend + - modular + - conventions +--- I just had the the pleasure of attending the SMACSS workshop in Essen by Jonathan Snook (@snookca) and wanted to share my impression of the "SMACSS approach" to CSS and some considerations on using it together with SASS.

Overview: The philosophy behind SMACSS

@@ -54,67 +53,49 @@ Secondly, the SMACSS approach was born out of experiences building Yahoo Mail an

Themes

When I was talking about SMACSS having 4 categories earlier, I actually left out the 5th category which is "theme".  I did this because, when using SASS, theming can easily be handled by defining variables for the style properties that you want to be themeable (e.g. $themable-border-color), instead of having to apply special classes to all the themable elements (.theme-border).  Here at Railslove we just had to create a new theme (basically a re-branding with different colors) on short notice for our client 9flats.com and we were amazed how quickly we could complete this task on a SASS-based website, which would have taken much longer in "the old days".

Submodules

-The best and most straightforward application of SASS functionality to the SMACSS approach is for submodules.  Whenever you need a variation of one of your modules, you are supposed to create a submodule, e.g. .dialog-wide is a submodule of .dialog.  While in traditional SMACSS you would need to apply both classes to your element (`
`), using SASS you have the perfect use case for the (underutilized) @extend feature and you would simply do it this way: - -~~~css -.dialog +The best and most straightforward application of SASS functionality to the SMACSS approach is for submodules.  Whenever you need a variation of one of your modules, you are supposed to create a submodule, e.g. .dialog-wide is a submodule of .dialog.  While in traditional SMACSS you would need to apply both classes to your element (
), using SASS you have the perfect use case for the (underutilized) @extend feature and you would simply do it this way: +
.dialog
   width: 300px
   color: blue
 
 .dialog-wide
   @extend .dialog
-  width: 600px
-~~~
-
+  width: 600px
The only thing you need to be aware of, is to never to extend across modules, which would violate the concept of SMACSS and could easily lead to unwanted side effects.

Module component syntax

One thing that I haven't quite made up my mind about is the syntax within modules.  SMACSS proposes that every component within a module should have a) its own selector (for performance) and b) be prefixed with the module name (for clarity). Like this: - -~~~css -.dialog +
.dialog
   width: 500px
 
 .dialog-header
   font-weight: bold
 
 .dialog-body
-  font-size: 13px
-~~~
-
+  font-size: 13px
This syntax is in some conflict with the way I have gotten used to authoring stylesheets with SASS, making heavy (sometimes too heavy) use of its nesting capabilities & syntax.  Using my traditional SASS style, it would probably look something like this: - -~~~css -.dialog +
.dialog
   width: 500px
   .header
     font-weight: bold
   .body
-    font-size: 13px
-~~~
-
+    font-size: 13px
I feel that all the prefixing adds a lot of distracting verbosity to the stylesheet and by nesting all the components underneath the module selector it actually gives it a nice visual closure.  The important requirement here is that you keep the component number and nesting depth of your module to a minimum.  But I think in this case applying the modular SMACSS philosophy is actually one of the best things that could happen to SASS, because the best practice to minimize your nesting has been pushed too little and therefore been overlooked far too often by SASS practitioners.  However, the big downside with this approach is that you loose a lot of clarity in the markup, because now it's not obvious anymore to which module a component class such as .header belongs to.  One idea to alleviate this problem could be to have a more obvious naming convention for module selectors (e.g. .module-dialog), so it's easier to trace your way up in the markup from a component class to the next module selector it belongs to. The other more minor downside of nesting would be the loss in CSS performance due to longer selectors caused by nesting.  However, unless you are not working on a super high performance website with massive reflows, lots of old browsers and complex mobile requirements, most  sources [1, 2, 3, 4] make me believe that heavily optimizing for CSS performance, isn't really worth the effort, especially in a startup environment. So, if we say that, on the one side we don't care so much about CSS performance and we do like the visual clarity of SASS nesting, but on the other side we also like the idea of always knowing which components belong to each other based on prefixes, a syntax like this could actually be a compromise: - -~~~css -.dialog +
.dialog
   width: 500px
   .dialog-header
     font-weight: bold
   .dialog-body
-    font-size: 13px
-~~~
-
+    font-size: 13px
If you then should start to worry about performance at some point you can easily convert to pure SMACSS.  However, I myself am not really sure yet what syntax I really prefer.  What do you think? File structure SMACSS already includes quite sensible naming conventions for selectors, but coming from the Rails/SASS world we obviously also value conventions for our file structure.  My suggestion for a SMACSS+SASS file structure would probably look something like this: - -~~~ -+ applications.sass // @imports +
+ applications.sass                  // @imports
 + base/
 |    _settings.css.sass              // SASS config variables
 |    _reset.css.sass
@@ -126,9 +107,7 @@ SMACSS already includes quite sensible naming conventions for selectors, but com
 |    _settings.css.sass              // SASS layout/grid variables
 |    _containers.css.sass
 + modules/
-+ non-modular/
-~~~
-
++ non-modular/
I guess there is nothing too surprising in there.  The only thing that I would add is the folder/area for non-modular styles.  As I said earlier there are always cases for pages/styles that are not very long-lived, not "fully baked", and so on.  Those should go to the non-modular folder.  Here it probably also makes sense to write highly specific (maybe even controller/view-specific) styles.  With that I would just want to prevent any half-assed styling attempts to bleed into the modular styles.  If styles in there last longer than expected, you can always go back and "graduate" them to proper SMACSS modules. Concerning file structure there is a little shell script by Wynn Netherland to create a (much simpler) SMACSS folder structure for SASS, maybe this could be extended for further integration between the two. @@ -136,4 +115,4 @@ Concerning file structure there is a little -
  • Cologne.js User Group: Am Dienstag trifft sich wieder die Cologne.js UserGroup im Coworking Cologne Space Gasmotorenfabrik. Es werden wieder verschiedene Talks rund um das Thema Javascript, Backbone, Node.js behandelt. Los gehts am 10.04.2012 um 19:00 im Coworking Cologne Space Gasmotorenfabrik in der Deutz-Mülheimerstr. 129, 51063 Köln. Mehr Infos unter: http://colognejs.de/.
    • -
  • Limited WIP Society Cologne: Am Mittwoch Abend trifft sich die Limited WIP Society Cologne - oder kurz - Kanban User Group. Hier treffen sich die Leute aus Köln und Umgebung, die sich für Lean und Kanban im Bereich der Wissensarbeit interessieren. Los geht es am 11.04.2012 um 19:00 Uhr im Coworking Cologne Space Gasmotorenfabrik in der Deutz-Mülheimerstr. 129, 51063 Köln. Mehr Infos unter: http://lwscologne.wordpress.com/.
    • -
  • Echtzeit Köln III: Am Donnerstag findet die dritte Echtzeit Köln statt. Es ist ein exklusives Netzwerktreffen im Rheinland. Die Veranstaltung richtet sich an Gründer, Business Angels und Investoren. Zugang ist nur über persönliche Einladung durch das Team von deutsche-startups.de - bewerben kann man sich per E-Mail (Betreff: Echtzeit Köln) an echtzeit@deutsche-startups.de.
    • +Hi Everybody, +this week you can meet the Railslove-Crew at the following events (sorry for the germany description): + +