Plurrrr

When I started thinking about writing a post about web font loading my intention was to propose relatively sophisticated ideas that I've been playing with for a while. However, as I was trying to use them in real-world websites I realized that deployment of the more advanced techniques is de-facto impossible without the creation of new web standards.

With that the TL;dr of this post is: Use font-display: optional. However, I and many others really like our custom fonts. See the rest of the post for how we can get our cake and eat it, too–with a tool that automatically makes fallback fonts behave like their respective custom font counterpart.

At this point probably everybody has heard about Docker and most developers are familiar with it, use it, and therefore know the basics such as how to build a Docker image. It is as easy as running docker built -t name:tag ., yet there is much more to it, especially when it comes to optimizing both the build process and the final image that is created. So, in this article we will go beyond the basics and we will look at how we can influence the build process of Docker images to make it faster and to produce much slimmer and more secure images for our applications.

Most of the time you want to use class selector using CSS. That's the most obvious and recommended approach. If these selectors are properly combined with for example BEM methodology (or any other methodology), chances are high that your CSS is written in a clear and reusable way.

However, in long-term projects with legacy code you may find yourself in such situations:

• class names of elements cannot be changed,
• HTML can't be changed,
• elements can't be reorganized,
• elements are loaded dynamically and there's no easy way to add a class name,

The list is open. The point is, that you can encounter situations where the class, type, or id selectors are not enough. This is when the other CSS selectors come into play.