Back in 2012 we rolled out our new visual identity and website, but we didn’t change our blog much at the time. So we decided that it was time to give some love to our blog and work on a full redesign over the last couple of months. We are really excited to release this work for everybody who reads our posts.

Fonts are bigger, colors are brighter and everything looks much better on your smartphone than it used to. We focused on improving the reading experience and on a more up to date look for our blog.

The whole development process was a great experience, from design to code, and I want to share some of the story of how we got there:

The (re)design process

At first we started sketching everything with HTML and CSS trying to put together our new look with some elements of our existing layout. As things started coming into shape, the next step was to put together a Jekyll website with all of our blog posts (thanks to jekyll-import) so we could easily test the new design against our existing content, rather than against a bunch of “Lorem ipsum” posts. This was really useful when reviewing the code snippets in our posts and visualizing how we could improve the syntax highlight using something else than the previous WordPress plugin we were using.

As we designed and prototyped each piece of our new layout, people outside the redesign project jumped in and participated through the Pull Requests that we used for building those blocks. A good part of our team was part of the whole process helping out with design/code/copy feedback.

The Journey into WordPress

One of the first decisions was to keep using WordPress as our blog engine. Over the last years a lot of alternatives have surfaced (like Ghost), but WordPress still feels the most complete blogging solution for us, so we’re still using it for the time being.

Given that, one of our challenges was to learn how to work with WordPress and convert our design (built on top of a Jekyll site) into a WordPress theme that we could install in our blog. This task ended up being much easier than expected.

After finishing the first complete iteration of the layout, I spent a few days watching some of the WordPress courses on Treehouse to learn how to work with WordPress themes and the whole PHP API behind it. I’ve mixed together some Bash scripts, a proxy server built with rack-legacy and some Gulp tasks to automate a local WordPress environment and migrated our Jekyll templates into PHP ones and we were set!

This might sound a bit too complicated, but the idea of starting with Jekyll to focus on the design process and quick iterations to later worry about the theme “infrastructure” was a well payed bet so I didn’t have to juggle both problems at the same time.

The best is yet to come

The idea is to not stop here. There are still a lot of improvements we want to do on our blog and all the tooling we have put together makes it easy to jump back and iterate over the design and the code.

Let us know if you find anything broken around here and we will jump on it to fix it. We hope you enjoy this new look and feel while reading through our blog posts :heart:!

The post The brand new Plataformatec blog first appeared on Plataformatec Blog.

However, it is possible that with the growth of your application code base the number of CSS styles will surpass the limit rules supported by IE9 or above. The current limit is up to 4095 rules per file.

But it is good to note that only the overflowed styles will be ignored. So, considering this detail, you might take some time to figure out that your layout is broken unless you are aware of this issue, since other browsers like Chrome, Safari and Firefox does not have such limit.

The simplest way to fix that is to split your main stylesheet into multiple files. Using a pre-processor makes the job easy, just create another manifest and move some imports to the newest one and problem solved.

Easy, huh? Well, if you have a well organized CSS the job might be straightforward, but if you don’t, you may struggle with some difficulties.

Here are some experiences that we got when addressing this issue.

Prefer to use placeholders instead of classes

We had some CSS styles that used @extend .some-class and it caused some problems as the .some-class definition is written to the CSS file, even if it is never used. One options is to convert classes into placeholders so they can be reused without being generated.

To make matters worse, .some-class was often defined in another file, which led to the file being imported, duplicating its rules over different files. This takes us to our next tip.

Organize variables and mixins into separated files

As your codebase grows, it is possible that variables, mixins or placeholders get spread in different files. So, if you have to split a CSS file, or even reorganize it, you will have to carefully ensure that all variables, mixins and placeholders are ported over. Keeping them in their proper files like _variables.scss and _mixins.scss cleans up the code and makes future refactoring much easier.

Use tools to break the compiled CSS file

There are projects that try to address the problem of long CSS files using a CSS parser to count the number of styles and generating multiple files when necessary. It is another solution to be aware of, but if you have a well organized CSS structure and guidelines to keep them clean, you can achieve the same result without adding another dependency or step in your asset pipeline.

Ways to detect the number of styles

From the command line

$ curl --silent  | grep -o '{' | wc -l

or if dealing with a compressed asset

$ curl --silent -H 'Accept-encoding: gzip'  | \
> gunzip - | grep -o '{' | wc -l

For example:

$ curl --silent http://plataformatec.com.br/stylesheets/all.css | \
> grep -o '{' | wc -l
339

Another easy way is just opening the CSS file in your browser and search for {.

Note that if you want to check the resulting CSS file in development you need to enable assets concatenation. One options is to set config.assets.debug to false in your development.rb file.

Summary

Preprocessors help a lot but it also requires discipline like any other code that you write. If you need inspiration to organize your files, you can take a look on Bourbon and even the well known Bootstrap project.

Do you know any other cases where a well structured CSS saved you?

The post Splitting long CSS files to overcome IE9 4095 rules limit first appeared on Plataformatec Blog.

After working on different projects with different styles of CSS, we wrote some Guidelines of what kind of code we would like to work with. These guidelines and some other practices have proven to be successful so far, and I want to tell you a bit about how we are doing this here.

Quick Facts

• We use SCSS.
• We usually just have Normalize.css (and sometimes Bootstrap) as third party dependencies.
• Every developer in our team can jump through the codebase and work on our front end code.

Preprocessors and the Pipeline

We have always used Sass (with the SCSS syntax), using most of the Sass features wherever seemed fit and without making the code too complex to grasp so developers outside the project – or without a long experience with preprocessors – could get things done right after jumping in the code.

We do our best to use the most of the Rails Asset Pipeline. I know that it isn’t the most beloved Rails feature out there, but we are pretty happy with it. The Sprockets + Rails integration in Rails 4 is way better than it was before (you can read a bit about what was done on this post), thanks to the work of Guillermo, Rafael and Richard (the Sprocket heroes) and everybody else who contributed to sprockets-rails, and things will only get better on future releases. If you had a hard time with a Rails 3 app, I recommend that you try it out the latest releases and see what have improved.

Architecture

We don’t have strict guidelines about how we should organize and architect our CSS code, but we have some general rules and conventions. We organize most of our code into isolated partial stylesheets under something like modules or components. And we also break functions, mixins and generic placeholders into specific files and @import everything on the application application.css.scss file.

We do our best to keep our selectors small and using only classes, somewhat based on Wealthfront post on Functional CSS and OOCSS-ish. With this setup we can avoid complex nested blocks and keep things quite readable for everybody.

Linting

We don’t have a specific guideline on linting, but I have been experimenting with SCSS Lint on the project that I’m current working on, and I want to evolve this into a default configuration for future projects.

Frameworks

We have some different setup across our projects, but we usually just have Normalize.css as our “reset” stylesheet and everything else is custom made – buttons, grids, typography rules, etc. And of all the existing CSS frameworks out there, we had some encounters with Bootstrap and Foundation once.

Documentation

We love documentation – not obvious code comments, but real documentation that makes easier to understand how to use a specific piece of code.

We started writing docs for our CSS to make more sense out of a SCSS partial, so through a single file we can understand how the application can use those styles. We have adopted some loose form of the KSS syntax, because we currently don’t care about generating pretty styleguides with live examples of the styles in use. But the KSS format is human-readable enough and does the job of explaining the purpose of a set of classes to someone.

Sprites

Last year I created a gem called Spriteful to help us manage the image sprites in some projects without having to bring Compass and compass-rails as dependencies to our pipeline. Spriteful has proven useful to me and my coworkers, and now we can generate sprites and SCSS partials out of icons and SVG images with just a single command.

Some close friends from outside the company have used it on their projects and it’s awesome that someone else has found our little tool handy for this task.

Who’s in charge?

One important aspect of how we work is that every developer in the team is capable to work with the front end code of the application and build new things or fix existing bugs, not just turn some static markup into ERB blocks. This provides a higher sense of collective ownership of the code, instead of enlisting one or two programmers who are in charge of half of the application while everybody else works elsewhere without caring about that layer.

The post CSS at Plataformatec first appeared on Plataformatec Blog.

A capa do livro “HTML5 e CSS3: Domine a web do futuro”

E a melhor evidência de que eu também acredito em multi-disciplinaridade é o meu recém lançado livro: “HTML5 e CSS3: Domine a web do futuro” publicado pela Casa do Código. Sou desenvolvedor há algum tempo e sempre me interessei por front-end. No começo eu tive dúvidas em qual assunto me aprofundar, mas entre escolher um caminho ou outro acabei optando em aprofundar em ambos. Confesso que eu não me arrependo em nada da minha escolha e estou muito contente em ter aprendido bastante ao longo do caminho e hoje eu poder compartilhar o que aprendi em HTML e CSS através deste livro.

Escrevi este livro pensando em desenvolvedores web que desejam aprimorar os seus conhecimentos em front-end e profissionais que estejam dedicando exclusivamente a estes assuntos. Aprendi muitas coisas ao ‘fazer’, por isso eu tentei replicar este tipo de aprendizado no livro com vários tutoriais e lições sobre técnicas clássicas de CSS e HTML (utilizando float, pseudo elementos e outros) e combinações de CSS3 para componentes visuais.

Para quem se interessar, o livro está a venda online na Casa do Código (versões impressa, .mobi, .epub e .pdf).

Plataformatec na QCon SP

Aproveito para fazer o convite para assitirem o meu lightning talk sobre CSS3 Transitions e a palestra do José Valim “Uma abordagem moderna para programação na Erlang VM: Elixir” na QCon SP, neste final de semana, no dia 04 de Agosto.

Fora a minha palestra, eu estarei no stand da Casa do Código (lá na QCon). Passe por lá para bater um papo. Será um prazer!

The post Lançamos mais um livro! \o/ “HTML5 e CSS3: Domine a web do futuro” first appeared on Plataformatec Blog.