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).

It takes a couple hours for an experienced developer to learn most of the features present on these languages (after you learn the first couple languages the next ones are way easier) but if you have no programming skills besides CSS/HTML and/or don’t know basic programming logic (loops, functions, scope) it will probably take a while, the command line is another barrier to CSS/HTML devs… But that isn’t the focus of this post, I’m going to talk specifically about overused/misused features. I will try to explain the most common problems I see every time someone shows a code sample or I see a project written using any of these languages/pre-processors.

Mixins

What are mixins?

Mixin is a common name used to describe that an object should copy all the properties from another object. To sum up a mixin is nothing more than an advanced copy and paste. “All” the famous pre-processors have some kind of mixin.

Dumb code duplication is dumb

Following the SCSS syntax (sass), a mixin can be described and used as:

Note that the properties are duplicated, which is very bad, file size will increase a lot and overall performance will also be degraded if not used with care. – Imagine that on a large project with thousands of lines of code, the amount of duplicated code will beunacceptable(by my standards).

This problem isn’t specific to SASS, it is also present on LESS and Stylus and any other language/pre-processor which supports the same feature, by having a new layer of abstraction the developer won’t realize he is creating code that has lots of duplication…ALWAYS gzip CSS and JS files!! gzip is really good at compressing duplicate data, so this problem might be irrelevant/nonexistent in production code, just beware that the generated CSS will get harder to maintain in case you or future devs for some reason decide to stop using a pre-processor and simply update the generated CSS (maybe they don’t have access to the source files or have no experience with a pre-processor).

Extend

LESS and Stylus doesn’t have support for anything similar to an extend, that’s why I picked SCSS (Sass) to write the code samples. A extend is like a “smarter mixin”, instead of copying and pasting the properties it will set the properties to multiple selectors at once.

Way closer to what a normal person would do manually… “Only” use mixins if you need to pass custom parameters. If you see yourself using the same mixin multiple times passing the same values than you should create a base “type” that is inherited by other selectors. – Compass(nice SASS framework) have a lot of mixins which I think should be base classesinstead.

Extend isn’t enough

Note that extend avoids code duplication but it also causes other problems, the amount of selectors can become an issue, if you @extend the same base class multiple times you may end up with a rule that have thousands of selectors, which won’t be good for performance either and can even make the browser to crash.

Another issue is that every class you create to be used only by @extend is going to be included on the compiled file (even if not used) which can be an issue in some cases (name collisions, file size) and makes this process not viable for creating a framework likecompass.

I really wish that SASS improves the way that @extend works (and that the other pre-processors also implements a similar feature) so we could create many base classes for code reuse but don’t necessarily export them. Something like:

Extend and mixins can be bad for maintenance

Contrary to the common knowledge, extending other classes and creating mixins can degrade maintenance. Since the place where you are using the properties is far awayfrom where the properties are being defined there is a bigger chance that you will change properties without noticing you are affecting multiple objects at once, or not realizing which elements are being affected by the changes. This is called “tight coupling”:

Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages:

A change in one module usually forces a ripple effect of changes in other modules.

Assembly of modules might require more effort and/or time due to the increased inter-module dependency.

A particular module might be harder to reuse and/or test because dependent modules must be included.

I prefer to group all my selectors by proximity, that way I make sure that when someone update a selector/property they know exactly what is going to be affected by these changes, even if that imply some code duplication.

Avoid editing base classes as much as possible, follow the “open/closed principle” as much as you can. (Augment base classes, do not edit them).

Nesting

Another feature that a lot of people consider useful is selector nesting, so instead of repeating the selectors many times you simply nest the rules that should be applied to child elements.

By abstracting the selectors it becomes very easy to be over specific and specificity is hard to handle and a bad thing for maintainability. I’ve been following the OOCSSapproach and I don’t need child selectors that much so I don’t think that typing the same selector multiple times is a real problem (specially with good code completion), I know a lot of people don’t agree with that approach but for the kind of stuff I’m doing it’s been working pretty well.

Call me a weirdo but I also find nested code harder to read – since I’ve been coding non-nested CSS for more than 7 years.

Sum up

These tools have some cool features like the helper functions for color manipulation, variables, math helpers, logical operators, etc, but I honestly don’t think it would improve my workflow that much.

My feeling for these pre-processors is the same feeling I have for CoffeeScript, nice syntax and features but too much overhead for no “real” gain. Syntax isn’t the real problem in JavaScript for me the same way that it isn’t the real problem in CSS (and most of the languages). You still need to understand how the box-model works, specificity, cascading, selectors, floats, browser quirks, etc… you are just adding another layer of abstraction between you and the interpreted stylesheet, adding yet another barrier for future developers and increasing the chance of over-engineering. Markup may become simpler (with less classes/ids) but it comes with many drawbacks.

For me the greatest problem are developers that code CSS without the knowledge required to build a maintainable and scalable structure. A stylesheet full of mixins, if/else, loops, variables, functions, etc, will be as hard to maintain as a bloated hand-crafted stylesheet, if not harder. Developers have an inherited desire to be “clever” and that is usually a red flag.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” – Brian Kernighan

Mixins are popular nowadays because of browser vendor prefixes, the real problem isn’t that CSS doesn’t support mixins or variables natively but that we have to write an absurd amount of vendor prefixes for no real reason since most of the implementations are similar and most of the features are only “cosmetic”. The real issue isn’t the language syntax, but the way that browsers are adding new features and people using them before they are implemented broadly (without prefixes). – This could be handled by a pre-processor that only adds the vendor prefixes (without the need of mixins or a special language) like cssprefixer. Try to find what is the real problem you are trying to solve and think about different solutions.

“It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.” – Peter-Paul Koch

I’ve been following the OOCSS approach on most of my latest projects, and probably will keep doing it until I find a better approach. For the kind of stuff I’m coding it is more important to be able to code things fast and make updates during the development phase than to maintain/evolve the project over many months/years. I find it very unlikely to make drastic design changes without updating the markup, on the last 100 projects I coded it probably only happened 2 or 3 times. – css zen garden is a cool concept but not really that practical – Features like desaturate(@red, 10%) are cool but usually designers already provides me a color palette to be used on the whole site and I don’t duplicate the same value that much, if I do duplicate it everywhere than I can simply do a “find and replace” inside all the CSS files and call it a day, by using a function that generates a color (which you have no idea which value it will be) you can’t simply do a find and replace since you don’t know what is the value you are looking for on the source code – I prefer to simply use a color picker…

I know my experience is very different from most people so that’s why my approach is also different, your mileage may vary… If I ever need to use any of these tools it won’t be an issue (I have no strong barrier against them), I just don’t think they will save me that much time right now that would outweigh the drawbacks. Pick the tools based on the project and your workflow, it isn’t because I listed a couple issues that you should discard using a pre-processor, for many cases it would be an awesome way of generating stylesheets, just think about the drawbacks and be responsible.

“With great power comes great responsibility.” – Uncle Ben to Peter Parker

PS: I love CSS, for me it’s one of the most rewarding tasks on a website development, it’s like solving a hard puzzle…

Background Info on Regular Expressions

This is what Wikipedia has to say about them:

In computing, regular expressions provide a concise and flexible means for identifying strings of text of interest, such as particular characters, words, or patterns of characters. Regular expressions (abbreviated as regex or regexp, with plural forms regexes, regexps, or regexen) are written in a formal language that can be interpreted by a regular expression processor, a program that either serves as a parser generator or examines text and identifies parts that match the provided specification.

Now, that doesn’t really tell me much about the actual patterns. The regexes I’ll be going over today contains characters such as \w, \s, \1, and many others that represent something totally different from what they look like.

If you’d like to learn a little about regular expressions before you continue reading this article, I’d suggest watching the Regular Expressions for Dummies screencast series.

The eight regular expressions we’ll be going over today will allow you to match a(n): username, password, email, hex value (like #fff or #000), slug, URL, IP address, and an HTML tag. As the list goes down, the regular expressions get more and more confusing. The pictures for each regex in the beginning are easy to follow, but the last four are more easily understood by reading the explanation.

The key thing to remember about regular expressions is that they are almost read forwards and backwards at the same time. This sentence will make more sense when we talk about matching HTML tags.

Note: The delimiters used in the regular expressions are forward slashes, “/”. Each pattern begins and ends with a delimiter. If a forward slash appears in a regex, we must escape it with a backslash: “\/”.

1. Matching a Username

Pattern:

/^[a-z0-9_-]{3,16}$/

Description:

We begin by telling the parser to find the beginning of the string (^), followed by any lowercase letter (a-z), number (0-9), an underscore, or a hyphen. Next, {3,16} makes sure that are at least 3 of those characters, but no more than 16. Finally, we want the end of the string ($).

String that matches:

my-us3r_n4m3

String that doesn’t match:

th1s1s-wayt00_l0ngt0beausername (too long)

2. Matching a Password

Pattern:

/^[a-z0-9_-]{6,18}$/

Description:

Matching a password is very similar to matching a username. The only difference is that instead of 3 to 16 letters, numbers, underscores, or hyphens, we want 6 to 18 of them ({6,18}).

String that matches:

myp4ssw0rd

String that doesn’t match:

mypa$$w0rd (contains a dollar sign)

3. Matching a Hex Value

Pattern:

/^#?([a-f0-9]{6}|[a-f0-9]{3})$/

Description:

We begin by telling the parser to find the beginning of the string (^). Next, a number sign is optional because it is followed a question mark. The question mark tells the parser that the preceding character — in this case a number sign — is optional, but to be “greedy” and capture it if it’s there. Next, inside the first group (first group of parentheses), we can have two different situations. The first is any lowercase letter between a and f or a number six times. The vertical bar tells us that we can also have three lowercase letters between a and f or numbers instead. Finally, we want the end of the string ($).

The reason that I put the six character before is that parser will capture a hex value like #ffffff. If I had reversed it so that the three characters came first, the parser would only pick up #fff and not the other three f’s.

String that matches:

#a3c113

String that doesn’t match:

#4d82h4 (contains the letter h)

4. Matching a Slug

Pattern:

/^[a-z0-9-]+$/

Description:

You will be using this regex if you ever have to work with mod_rewrite and pretty URL’s. We begin by telling the parser to find the beginning of the string (^), followed by one or more (the plus sign) letters, numbers, or hyphens. Finally, we want the end of the string ($).

String that matches:

my-title-here

String that doesn’t match:

my_title_here (contains underscores)

5. Matching an Email

Pattern:

/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/

Description:

We begin by telling the parser to find the beginning of the string (^). Inside the first group, we match one or more lowercase letters, numbers, underscores, dots, or hyphens. I have escaped the dot because a non-escaped dot means any character. Directly after that, there must be an at sign. Next is the domain name which must be: one or more lowercase letters, numbers, underscores, dots, or hyphens. Then another (escaped) dot, with the extension being two to six letters or dots. I have 2 to 6 because of the country specific TLD’s (.ny.us or .co.uk). Finally, we want the end of the string ($).

String that matches:

john@doe.com

String that doesn’t match:

john@doe.something (TLD is too long)

6. Matching a URL

Pattern:

/^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/

Description:

This regex is almost like taking the ending part of the above regex, slapping it between “http://” and some file structure at the end. It sounds a lot simpler than it really is. To start off, we search for the beginning of the line with the caret.

The first capturing group is all option. It allows the URL to begin with “http://”, “https://”, or neither of them. I have a question mark after the s to allow URL’s that have http or https. In order to make this entire group optional, I just added a question mark to the end of it.

Next is the domain name: one or more numbers, letters, dots, or hypens followed by another dot then two to six letters or dots. The following section is the optional files and directories. Inside the group, we want to match any number of forward slashes, letters, numbers, underscores, spaces, dots, or hyphens. Then we say that this group can be matched as many times as we want. Pretty much this allows multiple directories to be matched along with a file at the end. I have used the star instead of the question mark because the star says zero or more, not zero or one. If a question mark was to be used there, only one file/directory would be able to be matched.

Then a trailing slash is matched, but it can be optional. Finally we end with the end of the line.

7. Matching an IP Address

Pattern:

Description:

Now, I’m not going to lie, I didn’t write this regex; I got it from here. Now, that doesn’t mean that I can’t rip it apart character for character.

The first capture group really isn’t a captured group because

?:

was placed inside which tells the parser to not capture this group (more on this in the last regex). We also want this non-captured group to be repeated three times — the {3} at the end of the group. This group contains another group, a subgroup, and a literal dot. The parser looks for a match in the subgroup then a dot to move on.

The subgroup is also another non-capture group. It’s just a bunch of character sets (things inside brackets): the string “25″ followed by a number between 0 and 5; or the string “2″ and a number between 0 and 4 and any number; or an optional zero or one followed by two numbers, with the second being optional.

After we match three of those, it’s onto the next non-capturing group. This one wants: the string “25″ followed by a number between 0 and 5; or the string “2″ with a number between 0 and 4 and another number at the end; or an optional zero or one followed by two numbers, with the second being optional.

We end this confusing regex with the end of the string.

String that matches:

73.60.124.136 (no, that is not my IP address :P)

String that doesn’t match:

256.60.124.136 (the first group must be “25″ and a number between zero and five)

8. Matching an HTML Tag

Pattern:

Description:

One of the more useful regexes on the list. It matches any HTML tag with the content inside. As usually, we begin with the start of the line.

First comes the tag’s name. It must be one or more letters long. This is the first capture group, it comes in handy when we have to grab the closing tag. The next thing are the tag’s attributes. This is any character but a greater than sign (>). Since this is optional, but I want to match more than one character, the star is used. The plus sign makes up the attribute and value, and the star says as many attributes as you want.

Next comes the third non-capture group. Inside, it will contain either a greater than sign, some content, and a closing tag; or some spaces, a forward slash, and a greater than sign. The first option looks for a greater than sign followed by any number of characters, and the closing tag. \1 is used which represents the content that was captured in the first capturing group. In this case it was the tag’s name. Now, if that couldn’t be matched we want to look for a self closing tag (like an img, br, or hr tag). This needs to have one or more spaces followed by “/>”.

Windows phone is new to the market, but it hasn’t missed the chance to leave an impression with its cool new metro design. And what makes it alive are its Live tiles.

The live tiles, on the home screen are really a charm in the phone, all the information on one screen, no swiping pages.
What makes it more awesome is the cool new animation effects that the tiles bring while entering and exiting the homescreen. Its just so cool.
(Don’t have a windows phone? Never worry. Check a demo of the windows phone here online – http://www.windowsphone.com/en-us/cmpn/demo#home )

But what if you ever wanted to have such an animation in your website? maybe for a menu, or a list of products, or anything. It can be applied to anything grid-dy.

Sharing the pure-CSS3 code for a similar tile animation of a windows phone homescreen.

If your application requires dragging of elements, creating scrollbars, or anything that can make your app look sexy sticky and dragging, here’s the thing for you.

Unlike Jquery UI’s draggable plugin, that is heavy for your application, (and that requires you to download the pre-requisites to use just the dragging functionality, this one is lightweight (just 1.1Kb minified).

In order to use the plugin, simply bind the “draggable” event to an element.

A BEGINNER’S JOURNEY

HTML5

So, it is pretty obvious that you are going to need to learn HTML5 if you are doing to do front-end web development. From my experience most developers regardless of their language of choice know the basics of HTML. What they may or may not know are all the newer semantic tags, cross-browser tricks, and native JavaScript APIs.

There is plenty to learn in HTML5 without getting into the JavaScript APIs just yet. Once you learn JavaScript and feel comfortable in it, that may be the best time to tackle topics such as Geolocation, Web Sockets, Canvas, IndexDB, Web Workers, etc…

JAVASCRIPT

Even if you think you know JavaScript it might behoove you to go back and learn it from the beginning. A common danger is that developers think it looks just like their back-end language of choice (C, C++, C#, or Java) that they don’t invest time to learn how it is different.

JavaScript is a dynamic and functional language, which is considerably different than C# or Java for example. So, please take your time and pick up the language. If you don’t learn it appropriately you will invariably run into barriers down the road due to lack of understanding.

JQUERY

The jQuery library has been around for several years and has catapulted as one of the most used tools in the web developer’s belt. The reason for its vast usage is that it solves many of the cross-browser issues that creep up during development. The library is popular for both web developers and web designers. The community around jQuery is amazing and there are tons of jQuery plugins to choose from.

Resources

BACKBONE.JS

If you find yourself writing more and more JavaScript and jQuery then you may want to consider picking up Backbone.js to help you organize your web application. This library is also a great fit for Single Page Applications (SPA). Backbone.js uses the familiar MVC/MVP concepts of Models, Collections, Views, and Routers. In addition there is a nice Event model, History support, and a Sync mechanism. The community for Backbone.js is also very large and you can find many extensions and plugins to fit your needs.

CSS3

You may or may not have experience with CSS. Brushing up on CSS concepts would be a good thing. If you already feed proficient at CSS1-2, then you should pick up CSS3 as well. A lot of features have been added recently that is in most modern browsers. There are many things that you can do in CSS3 now where you used to use JavaScript or custom images.

FEATURE DETECTION

Inevitably you’ll need to support browsers that don’t support the native feature you are trying to use. Thankfully you can use Feature Detection to determine if the browser you are in implements that feature and if it doesn’t then you can provide functionality to mimic that feature (a.k.a. a polyfill or shim).

Resources

RESPONSIVE WEB DESIGN

Instead of implementing a different UI for mobile devices, tablets, and desktop browsers you can use responsive web design techniques to provide one experience that restructures the UI according to its size.

CONCLUSION

Hopefully the above resources will get you started in your transition to front-end web development. There is a lot to learn, but it is an exciting space that changes frequently. Having a desire to learn is a good trait to have in this field.

If you have any resources that you think I missed please add them in the comments and I’ll try to update the lists above if I think they are appropriate.