Feature Queries in CSS. How do they work?

In recent months, we have been experiencing certain changes in web design thanks to CSS Grid. But with this type of progress, sometimes we have the fear of start using them, since we will be leaving behind all those users who cannot enjoy them for several reasons: outdated browsers, old operating systems, etc. In fact, even in our article appear some comments that, with reason, refuse to put these new tools in your workflow, despite knowing that they would optimize your work time clearly in addition to many other benefits. And for all these reasons, we wanted to show you the use of Feature Query, a CSS tool that some may not know, but that surely will give you many satisfactions in the future.

But what’s the use of Feature Query? Well, it simply tells the browser that if it supports a certain property or CSS value, it has to apply it. If it does not support it, it will not read anything that the Feature Query tells it. So it will save verifying all that cascade of useless information.

It is very important before continuing. In this article we are going to see certain parts with CSS code. If you are not familiar with this language, I recommend you go through this article of introduction to CSS that we wrote some time ago.

Feature Query compatibility

As you know, before entering a subject, I always like to look before in the Can I use website…to check the compatibility with the different browsers of the tools we are going to use. And if you see the image, the compatibility is somewhat greater than 94%. A joy, we will not deny it. Although as often happens, we still leave out our beloved Internet Explorer 11. But we will explain that with a small example later.

Using Feature Query

The syntax of Feature Query is very similar to that of Media Query, as we see in the following image. If you do not know what a Media Query is, I recommend you take a look at the article we wrote about this topic.

It is not very difficult to use. If the browser understands the property that we put in the Feature Query, then all the style that is inside the brackets will be applied. But if you do not understand it, you will directly skip all that piece of code.

We must also make clear that this tool does not serve to fix possible errors that we have in our code or on a website. It simply serves to ask the browser whether or not it uses a certain property and that, depending on its response, it uses it or not.

But as we usually say, what better way to understand the operation of a tool than using it directly.

Example of using Feature Query

We are going to do a little exercise to see how Feature Query works. We want to use the CSS property initial-letter. This property causes the first letter of the first word of a text to be displayed larger. It is very useful if we are designing the web of a newspaper or we want to give a more literary touch to a text.

But we face a problem: currently, the only compatible web browser is Safari. So if we write those lines of code in our style sheet, it will only be shown in Safari; and the rest of browsers, not knowing them, will directly obviate it. So, let’s write a little Lorem ipsum and let’s apply this CSS:

p::first-letter {
     initial-letter: 4;
     color: red;
     font-weight: bold;
     margin-right: 0.5em;
}

If we are in Safari, it must appear as follows:

And if we are in any other web browser, such as Firefox, we will see this:

As you can see, it is not ideal. Firefox is still not compatible with this property, so it is impossible to apply it. The problem comes when we apply part of what we have written, such as the colour of the font or what is in bold. It makes us half the work and this is not what we are looking for. Ideally, if a web browser is compatible with initial-letter, we should use it normally, but if it is not compatible, we should not use any of its values.

will say, not without some reason, that to be shown in this way, it is better not to use initial-letter. But let’s think differently. Maybe the ideal thing is to be able to use all the new tools that are coming out from the beginning, and be able to include them in our stylesheet. And as the browsers are updated and compatible with them, they will automatically be displayed. And this is where Feature Query comes into play.

@supports (initial-letter: 4) {
  p::first-letter {     
     initial-letter: 4;
     color: red;
     font-weight: bold;
     margin-right: 0.5em;
  }
}

With this piece of code, we are telling the browser that if it supports initial-letter, it has to apply everything that is inside the Feature Query. And if it does not support it, it should ignore all the content that is inside. With this we gain two things. On the one hand, we use a new tool that perhaps, due to design issues, we need. Besides, when we are in a browser that does not support it, it does not show us weird things. And on the other hand, browsers that are not compatible today, but that will be in the future, will automatically use the property, without having to worry about changing our style sheet.

As we said at the beginning, we can apply all this to other properties, such as CSS Grid. We can design our web with its floats as we have done so far, making sure that it will work correctly in any browser. But in addition, we added a Feature Query with its Grid. Thus, modern browsers take advantage of the benefits of these new tools. The ancients will continue to have support. And the web browsers that are updated over time will go from using the classic floats to work with Grid without having to do anything extra at the time they start to be compatible.

We leave you this little example in Codepen, so you can see firsthand how this Feature Query works. Remember that you are only going to see the initial red letter if you enter from Safari!

@supports not, or why we should not use it?

Let’s take a closer look at why we should ignore the use of @support not, when at first glance it may seem like a good idea. With @support not, what we are saying to the browser is that if it does not support certain CSS property, it can use the code that we have inside the Feature Query. It is perfect, since we can group all the CSS code that we know they will be read by even the less updated browsers, and the rest, we put it out. But of course, we have not taken into account a variable in this equation.

Let’s imagine a small example. As we see in the image above, the CSS property Flexbox is compatible with virtually all browsers, including IE11, Blackberry and IE Mobile. So we could perfectly decide to use CSS Grid in the design of a website, and make use of Flexbox for all other browsers. If you want more information about Flexbox, do no miss the article we wrote about it.

body {
	display: grid;
}

@supports not (display: grid) {
	body {display: flex;}
}

It seems all right at the beginning. If my browser is compatible with CSS Grid, it will be applied correctly.

And if it is not compatible with CSS Grid, it will apply Flexbox. But, what happens if our browser is compatible with Flexbox, but is not compatible with Feature Querie? This is the case of IE11, for example. When reading our style sheet, IE11 will not apply CSS Grid, as we already know. But the problem is that, since it is not compatible with the Feature Queries either, it will not be able to apply it either. So it is not going to use CSS Grid, as we have foreseen, but it is also not going to be able to apply Flexbox, since it does not know how to read everything inside the Feature Query. And this is the problem. We have created some lines of code thinking specifically about the less updated browsers, and perhaps due to an incorrect use of the Feature Query, it is not going to be applied. It is an absolute failure.

So the correct provision we should have is:

body {
	display: flex;
}

@supports (display: grid) {
	body {
              // código para nuevos navegadores
             }
}

With this, what we want to show you are the four situations that we face when using Feature Queries.

• If the browser is compatible with Feature Query and with the property, the code that is inside will be applied correctly.
• If the browser supports Feature Query but not the property, the code inside is not going to be applied. But nothing happens, because in that browser you will use the code that is not inside the Feature Query.
• If the browser does not support Feature Query or the property, again, the code inside will not be applied. It is a case similar to the previous one.
• If the browser is not compatible with Feature Query but it is compatible with the property, the code that is inside is not going to be applied. So we are creating some styles for that browser compatible with the property, but the Feature Query prevents you from reading it. And since everything outside the Feature Query cannot read it either, we are definitely not getting anything.

In short, Feature Query is a very useful property for these moments of transition and update of browsers, in which new methods to work with our web designs that are being implanted little by little arise. Thus, on the one hand, we are using the most current tools to work and to make a better web. And on the other hand, we do not leave out those users who, for whatever reason, cannot yet enjoy browsing these new options.