Improving Vim auto complete for CSS class names

Just a quick tip about Vim autocompletion.

I’ve been using the excellent SuperTab Vim Plugin for a couple years, it works reasonably well (autocompletes based on words from all buffers, file names, tags, context, etc…) but it doesn’t work really well for text that is split by dashes - CSS contains lots of these… - so I started to get frustrated with it.

You can change the auto complete behavior with set iskeyword which also changes the behavior of standard motion commands like w, e, b (it changes the word delimiters) – which a find a PITA since I got used to these motions. My quick and dirty solution to the problem was to keep iskeyword with the minimal value as possible and only change it during InsertEnter. That way I can still use cw, ve, db to edit each fragment, autocomplete will work properly for words like foo-bar__baz, and you can still use W, B and E if you want to quickly jump around. For me that’s the best of both worlds!

Read more…

Tags: , ,



CSS was meant to style academic documents and simple sites (eg. wiki, blogs) where the cascade and descendant selectors makes a lot of sense. Unfortunately many sites we build nowadays are way more complex than that, and what used to work on simple projects doesn’t scale very well. We need to find smarter ways to code CSS to avoid the common issues and re-think the way we do our work. We should learn from the experience of other devs working in different domains, and apply into our own domain. Things like separation of concerns, modularity, encapsulation, DRY can (and should) be applied to large scale CSS projects as well. The main problem is that most people who are good at CSS doesn’t necessarily have a Computer Science background, most of them started as designers and learned CSS by themselves (that was my case…). That’s the main reason why I’m writing this post.

I won’t get into too much details/examples but will try to explain briefly each concept. Some of the SOLID principles are open to multiple interpretations on the CSS context - since we are shoehorning the concepts - that’s one of the reasons why I decided to not give detailed examples. I also think we should understand the idea and not be tied to a specific implementation.

Read more…


The problem with CSS pre-processors

This post is very polemic, I thought a lot before publishing it, please try to be open-minded and read the whole thing before commenting, it is not supposed to become a flame war. Please read the about page to understand the objective of this blog and the way I think about it.

I’ve been considering to use a CSS pre-processor like SASS, LESS, Stylus, etc, for a very long time. Every time someone asked me if I was using any of these tools/languages I would say that I’m kinda used to my current workflow and I don’t really see a reason for changing it since the problems those languages solves are not really the problems I’m having with CSS. Then yesterday I read two blog posts which made me reconsider my point of view so I decided to spend some time today studying the alternatives (once again) and porting some code to check the output and if the languages would really help to keep my code more organized/maintainable and/or if it would make the development process easier (also if they evolved on the past few years).

Read more…


Pragmatic CSS: using JS and inline styles

I’ve been working on many different kinds of projects through the past years, some of them with a very short lifespan (3-6 months) and almost no maintenance after launch and others with constant updates and planned to last for many years, from facebook applications to mobile websites, microsites, intranets and large dotcoms… I committed a lot of mistakes and done a few things right as well. One thing that I’ve been realizing is that some things that are usually considered “bad practices” sometimes can be the most productive solutions and that the drawbacks from taking a “shortcut” may not exist if you do it with caution.

I’m a huge advocate of clean and maintainable code, I really believe that grouping things by context is usually the best approach – style should be stored on external stylesheets, JavaScript should be on external files as well and the HTML should only hold the markup and content… - But I also think that best practices exists for a reason and we can’t forget what kind of problems they solve and why they were created, following rules blindly is almost as bad as breaking them without a good reason.

I’m going to try to explain some cases where inline styles and using JavaScript to set styles can be the recommended approach. – To all the zealots out there, try to understand that each project have different goals and requirements and that what is often considered a bad practice can be a reasonable solution in some cases…
Read more…


How I structure CSS files

Yesterday I was having dinner with my coworkers (company party!!) and between some bottles of wine, Italian food and Bocce, Marcus Schaefer commented that my CSS are really organized and I briefly explained why I do this way to him and thought that it was a good subject for a blog post…

The purpose of this post is to explain a little bit my workflow and how I setup my CSS files and why I do this way. I’ve been using almost the same structure on the past 3-4 years and it has been working pretty well, it’s the way that I find more productive/organized for my way-of-thinking/workflow and I’ve never seen someone writing about and/or using the same approach.

Keep in mind: each person has their own opinions/preferences and my setup may not fit other people’s workflows…

Read more…