As a beginner in any specific web tech, your first concern is "what is this and how does it work?" As you level up, those concerns change. You may still learn about about how it works as you dive deeper, but other concerns will emerge the more you know, the more you use it, and the more work of others you are exposed to.

CSS

Beginner

• How do I make stuff look how I want?

Intermediate

• How can I keep this under control?
• Can/should I use frameworks/libraries?
• How do I deal with cross-browser problems?
• Should I be using a preprocessor?

Expert

• How can I write less of this?
• Can/should I create frameworks/libraries?
• Is testing possible?
• How can I improve the tooling?

JavaScript

Beginner

• How do I make stuff happen?

Intermediate

• How can I organize this?
• What are the best practices regarding speed and efficiency?
• What jobs are best left to other web tech?

Expert

• How can I write less of this?
• Are Preprocessors appropriate for this?
• How can I keep this really fast?
• How does a team write this?
• How do we make less mistakes?

HTML

Beginner

• What tags do I use for what?

Intermediate

• How can I write this really efficiently?
• Am I being as semantic as I can be?
• Am I being as accessible as I can be?

Expert

• What tags do I use for what? lol.

Back End Languages

Beginner

• What is the syntax?
• How do I perform basic loops and logic?

Intermediate

• How do I organize this?

Expert

• How can I keep this fast?
• How can I keep this secure?
• Am I using the right languages for the right jobs?

Databases

Beginner

• How can I store and get stuff?

Intermediate

• How do I structure this intelligently?

Expert

• How can I scale this?
• How can I predict our future needs?
• What types of databases are right for what kind of data?

What does it mean?

I'm not sure exactly. It's just interesting to think about. Here's some maybes:

From an education perspective it would be interesting to know how many people there are out there at each level and how interested they are in getting help on those questions.

From a hiring perspective it may help identify the relative skill level of hires by seeing what kind of things they are concerned about at the moment in a particular area.

From a self improvement perspective it may help you understand what is in store for you as you level up.

How Web Tech Concerns Change is a post from CSS-Tricks

The CSS clearfix has been a must-have in our web design toolkit for quite some time, and until new layout features like flexbox become more stable, we’ll always need some form of clearfix in float based layouts. There are several ways we can clear floats with plain CSS, but each requires repeating either a class in the markup or the same properties and values throughout the CSS.

Thankfully, Sass has our back, with alternative clearing methods that save us time and many lines of code. In this article, we’ll target the most efficient approach to clearing floats with Sass.

Clearfix Nesting

Nesting seems like a convenient method for clearing floats because we can simply nest the clearfix wherever necessary and refer to the parent selector.

.wrap {
      &:after {
        content: "";
        display: table;
        clear: both;
      }
    }

While nesting is a handy Sass feature and it gets the job done, it’s not entirely efficient for clearing floats because it isn’t reusable or modular. We’ll need to nest the clearfix inside every rule that requires it, which may result in excessive CSS output. So there is a cost in code size and maintainability.

Using a Mixin

A different approach is to create a mixin for the clearfix:

@mixin clearfix {
      &:after {
        content: "";
        display: table;
        clear: both;
      }
    }

Then include it wherever necessary:

.wrap {
      ...
      @include clearfix;
    }

My issue with this approach is that everywhere @include is used the entire block of code is repeated in the output, so it produces extra CSS.

Extending It

On a large-scale project, it’s best to use the @extend directive instead of a mixin, as it will output less CSS.

First we nest the clearfix inside a class selector:

.clearfix {
      &:after {
        content: "";
        display: table;
        clear: both;
      }
    }

We can then extend the .clearfix class wherever necessary.

.wrap {
      ...
      @extend .clearfix;
    }
    .main-header {
      ...
      @extend .clearfix;
    }

@extend will output one CSS rule that groups the selectors with .clearfix.

.clearfix,
    .wrap,
    .main-header {
      &:after {
        content: "";
        display: table;
        clear: both;
      }
    }

Using a Placeholder Selector

We can still improve things by creating a placeholder––or silent class––selector. This way nothing gets compiled to CSS unless we actually use it.

Placeholder selectors are defined by a %, so we’ll need to replace the class with:

%clearfix {
      &:after {
        content: "";
        display: table;
        clear: both;
      }
    }

Now we can extend it anywhere without repeating any CSS.

.wrap {
      ...
      @extend %clearfix;
    }
    .main-header {
      ...
      @extend %clearfix;
    }

Conclusion

Using the @extend directive is more efficient and maintainable, which should always be our goal when writing CSS. Even though we should be minifying and Gzipping CSS in production, and the difference in file size and performance is hardly––if at all––noticeable, this approach just feels better overall.

Is there another clearfix method you use? Let us know in the comments below.

The post CSS Tip: A Better Clearfix with Sass appeared first on Treehouse Blog.