Weekly Recap

Hello everybody! It’s sunday again and this means it’s time for some link tips for you guys. A lot of good stuff this week. Let’s do this:

Using BEM Syntax with Sass 3.3

As you might know I’m a big fan of the BEM Syntax. If you haven’t heard of it, it’s basically a way to name your CSS classes in a way that makes sense and gives everybody involved with writing CSS for the site some knowledge of the structure. It really helps to write modular CSS and makes it easy to understand the code even if you get into a project later on.

BEM stands for Block Element Modifier. Here is an example to get you started:

.nav {
    // This is the BLOCK
    margin-bottom: 20px;
}

.nav__item {
    // This is the ELEMENT
    color: #000;
}

.nav__item--active {
    // this is the MODIFIER
    color: #1193e5;
}

Some people don’t like how the notation looks, but I assure you it works really well and even some people I first had to convince are totally stoked now.
Now let’s look at Sass 3.3 and what it has to offer.

With Sass you can use & to reference the selector which is already in place if you want to nest code. Just like this:

.nav {
    margin-bottom: 20px;

    & a {
        color: #000;
    }
}

This compiles to the following CSS:

.nav {
    margin-bottom: 20px;
}

.nav a {
    color: #000;
}

That’s pretty nice and straightforward and helps a lot in authoring CSS. With Sass 3.3 it gets even better if you are a BEM guy or gal. Now you can write our first example like this and get the exact same CSS output only that your Sass looks cleaner and you have less to write:

.nav {
    // This is the BLOCK
    margin-bottom: 20px;

    &__item {
        // This is the ELEMENT
        color: #000;
       
        &--active {
            // this is the MODIFIER
            color: #1193e5;
        }
    }
}

The CSS output looks as follows:

.nav {
    margin-bottom: 20px;
}
.nav__item {
    color: #000;
}
.nav__item--active {
    color: #1193e5;
}

I haven’t used that in production myself yet, but I will as soon as possible because I think it’s great. But I can imagine that if one would nest to deep it can get a little confusing. But the good thing is, just because you use it in one place doesn’t mean you have to use it every time. Nevertheless, make sure you Sass follows some kind of style guide.

Now if you ask yourself if you have Sass 3.3 installed you can check this by typing

$ sass -v

into you console of choice. If you are not on 3.3 you can update with

$ sudo gem install sass

After installing check if everything went well with

$ sass -v

As of writing this post Sass is at Version 3.3.4 (Maptastic Maple).

If you have any questions or suggestions, feel free to send me a tweet at @_martinwolf or write an email at martin@visuellegedanken.de

Hope this article helps some of you. Have a nice day!

wolf_20130824_001@2x

The Right Pseudo Elements Notation

Did you know that there is a difference between pseudo elements and pseudo classes and that they actually should be written differently?

Pseudo classes refer to the state of the selected element, like :hover, :focus or :last-child.

For example:

p:last-child {
    margin-bottom: 0;
}

Pseudo elements on the other hand are actual elements, that get somehow created by CSS. The newest Chrome Dev Tools are making a good job in demonstrating that with actually showing them in the code. To make the difference clear pseudo elements are since CSS3 notated with two colons.

blockqoute::before {
    content: '“';
}

blockqoute::after {
    content: '”';
}

(Be aware, if you need to support IE8 you have to write it in the wrong single-colon CSS 2.1 syntax with only one colon.)

You can read more on pseudo elements at the W3.

Why I didn’t switch to Jekyll

Two weeks back the idea of using Jekyll, a static site generator, to power this blog came back into my head after reading this article by Paul Stamatiou. I had experimented with it somewhen last year and liked it so far but then just forgot about it.

I like the idea that I have everything under control, that there is no database and I just serve static files. Plain and simple. No extra markup coming from a CMS or plugin. So the idea of switching to Jekyll began to take shape.

I wasn’t quite sure if it would be a good idea, so this past week I got up early everyday and started writing a new theme for Jekyll, which, shouldn’t I like my new “CMS”, would be easy to port over to WordPress. In the end that’s what I did. And here is why.

The basics of Jekyll are pretty simple, so after I had a baseline of what I wanted I started to read about how I could migrate all of my posts and metadata from WordPress to Jekyll. There are tons of articles, GitHub Gists and whatnot. But I had trouble making it work. But after hours of struggling and trying dozens of different techniques and scripts I finally had what I wanted. Dozens of markdown files with all the content. 2671 files to be exact. (I used Exitwp and did some cleaning up manually.)

Build Performance

But here lies the first problem. Performance. Building the static site takes relatively long with that amount of posts. And you have to go through that with every change you make on your site or when you write a new post – or when you preview a new post. While developing I only ever generated a handful of posts to speed up the process, but nevertheless, I could see that building performance is or would be a problem in the future. Static site generators might probably be better for smaller sites and blogs which don’t write a lot of posts. But I plan on keeping this blog for the coming years or maybe my whole life, who knows.

This is a good cue, because I have no idea what I want to do with this blog in the future. Maybe it stays small with just one author and not a lot of other features besides articles. But I don’t know, it could also be possible that one day I want to grow it into some kind of magazine or something. And what then? WordPress is capable of pulling that of, Jekyll or any other static site generator is probably not.

Writing and publishing

In the end the only thing that really matters is, are you writing blog posts or not. And to be honest, WordPress makes it pretty damn easy for anyone. You have internet and a browser? Fine, you can blog. You can even use an app on your phone or tablet to publish articles. It’s not that easy with Jekyll. You need a command line, you whole git repository, ruby and whatnot. So another plus for staying with my beloved WordPress. And with some easy tweaks you can write Markdown in WordPress, too. I use Markdown Extra Plugin.

Site Performance

One thing that’s bugging me since I think a lot more about performance is that WordPress can get a little cluttered, code wise. It’s easy to install plugins which inject stylesheets and scripts on every page resulting in extra requests even if you don’t need them. But you can make WordPress really slim if you want to. You can remove code from wp_head and you can edit plugins or simply deactivate a bunch that you just don’t need.
And to further boost the performance, you can even serve static html files with tools like Cachify. Or automatically generate and deliver webp images with Optimus. Both awesome plugins written by my friend Sergej.

So in the end I stayed with WordPress. It’s extremely flexible, future-proof and fast if you treat it the right way. And although  I’m by all means no PHP expert, I know how to customise WordPress and I like to build sites with it.

New Blog Design

The new design is a tad simpler than the old one, but I might be putting comments back in and link an archive page and something like that. Also visual tweaks will always happen on the fly. But for now I like it as it is. Clean and simple. If you like to see the source code. It’s on GitHub. Enjoy!

If you have any further questions or feedback, feel free to tweet my at @_martinwolf or send me an e-mail.

Cheers,
Martin

Weekly Recap

Hello everyone, feeling good today? You should, it’s Weekly Recap day! There was actually plenty of things going on the past week. Julia Ann Horvath talking about why she had to leave GitHub, an indiegogo campaign for implementing picture in Blink and much more. Enjoy!

.widget:media(max-width: 30em) {
    /* styles */
}

A Follow Up On The Minimal-UI Viewport Meta Tag

My post on the new viewport meta tag minimal-ui was quite popular, but equally controversial. Some love the addition by Apple and some expressed their concerns regarding the users experience.

I for one was pretty excited about minimal-ui at first but after some thinking about it I have to say it might not be the best choice for the average site. And here is why.

It just confuses the user who has no idea what is happening to him and his browser. There is no hint on how you get back the browser ui and if we are honest, you don’t gain that much either. Just a little bit more screen real estate, which – by the way – you’re getting anyway if you start to scroll. But then it’s the known behaviour and you’re initiating it by yourself. That’s much better.

Nevertheless I think minimal-ui can be a used if you’re building a web app and there might be some other edge cases in which it might make sense.

In my opinion this option should be on the client side. It would be a perfect setting for mobile Safari. So the user could switch to minimal-ui-mode on purpose.

Another code-related problem is that Chrome is showing a Javascript error if you use minimal-ui. That doesn’t alter your sites behaviour but is by all means not a nice thing and does actually bother me a lot. And I’m probably not the only dev who thinks that way.

The key "minimal-ui" is not recognized and ignored. 

But the Chrome team is already on that one. Chrome Canary isn’t showing the error any more.

So before blindly adding minimal-ui to you site think about what you gain and what you might lose. Worst case: Your users.

Weekly Recap

Hey fellow developers and who else might enjoy these lists. Welcome!
The feedback for the Weekly Recap has been great so far. That makes me really happy and keeps me going. This week is a particular good one, I think. That said, let’s not waste any more time and get right into it. Enjoy!

Services I happily pay for

I use a whole lot of different service. Some are free, some require a one time only payment and some have subscription models. Today I want to talk about the latter. So let’s see which services I use and what they do.

CodePen Pro (codepen.io)

CodePen is a code playground. You can show off your skills or just try something very quickly. You get three textareas, one for HTML, one for CSS and another one for Javascript. And you always see the results updating live in a fourth box. I often use it to isolate problems I have while developing whole sites. This helps me getting to the underlying problem and thus solving it. But it’s also great to present something you did or just get inspired and see what others are doing. I just love it and use it almost every day.

GitHub (github.com)

I probably don’t have to say much about GitHub. You can host your git repositories there, privately which I happily pay for, or just use the free plan and open source your code and work together with others. We all love GitHub, right?

Spotify (spotify.com)

A few bucks a month and I get access to – what feels like – all the music the world has to offer. Couldn’t imagine living without Spotify – or Rdio, which is basically the same. Other than that I often go to Soundcloud to listen to music.

IRCCloud (irccloud.com)

After not using IRC for a few years, I’m back and it’s better than ever. IRCCloud makes sure I’m always online and thus I don’t miss anything in my favourite channels. I use the IRCCloud website as a fluid app on the Mac, which works really great and there is also an iOS app if I’m on the go.

Feedbin (feedbin.com)

Many claim that RSS is dead. And while I’m definitely don’t use it as much as I used to, I still like it and after the Shutdown of Google Read, Feedbin is my new home. A lot of apps are able to sync with it, but I mainly use the website which has a nice, clean interface and is blazing fast.

Typekit (typekit.com)

Currently I use Typekit for serving webfonts to this blog. There are good alternatives out there but Typekit was the first I took notice of and I stuck with it. But I have to say that I often look at the fast growing Google webfonts library and also love the fonts by H&FJ. So while I’m content at the moment, I might switch some day.

Which services do you use and are happily paying for?

Viewport Meta Tag: Minimal-UI

With the introduction of iOS 7.1 Safari understands a new viewport meta tag which automatically reduces the mobile Safari ui to a minimum. I think it’s a great addition and hope other browsers will support it in the future, too.

<meta name="viewport" content="width=device-width, minimal-ui">

Here is my blog before and after adding minimal-ui:

minimal-ui-example

Hint: As a user you can get the menu bar back by tapping on the url.

Update: I wrote a follow up post explaining why minimal-ui might not be such a good idea.