- So in the previous video I explained how you can use
feature queries to create a block of text
that will only run if a certain feature
is supported in the browser.
There's a couple things I want to explain
a little bit more advanced about feature queries
including why you might not want to use
the nots in text, at least not for the next several years.
@Supports not display grid, for example
is probably not a good idea.
Instead you should just write code
that's going to be used in all the browsers,
including the browsers that don't support grid
and then write code for the browsers that do support grid
and put that in a feature query.
So why is that?
Well that's because not all the browsers
understand what a feature query is.
If we look here on can I use, we can see that
IE 11, actually every version of IE
does not understand what a feature query is.
Safari up until version 8,
Blackberry browser, the IE mobile browser,
Opera mobile browser up until version 12,
they don't understand what a feature query is.
So what they'll do is simply reject all of the code total.
If you go into Safari 8 and you put a block of code in,
and it just sees the feature query,
it's going to skip the whole thing
whether or not it supports the actual feature.
We can see here, for example, I could say something like:
@supports not display grid with hopes, perhaps,
that this code, that layout will run
in all the browsers that don't support grid.
The problem is that feature queries
are not supported in every browser, right?
Feature queries, themselves, are fairly new.
So what will happen is this code is not being applied.
In this case, I've got paragraph colour red just to
change the colour of all the words to red.
It doesn't work because it doesn't understand
what the feature query is, it skips the whole thing.
This is why the not is probably not very helpful.
If you think about the browsers
that support feature queries,
the browsers that don't support feature queries,
the browsers that support a new feature like grid,
and the browsers that don't support a new feature like grid,
you end up with four different possible combinations
of whether or not there's support happening.
So let's look at a little chart that will help us
kind of picture this in our mind.
If it understands feature queries
and it does support the property,
then yes the code will be written.
A feature query will work,
yes, the property being tested is being supported,
so run the code, yes that's what we want.
Everything's good to go.
If it understands a feature query and
knows that it does not support
that thing that you're testing,
oh you're in a process that supports feature queries
but it doesn't support this new thing,
it doesn't run the code.
That's great, that's exactly what we want.
If a browser does not understand the feature query,
it rejects the entire feature query,
but it's fine if it also does not support
the property that you're testing for
or the value that you're testing for.
Why?
Because the result is that the code does not get run
and that's what we want, we want the block
to be skipped and the block is skipped.
It's skipped because the browser
doesn't understand the block of code.
Kind of not the right reason but it doesn't really matter.
We get the result that we want.
The problem comes when a browser
does not understand the feature query
but it actually does support
the feature that you're testing for.
You want it to run the code but it's not going to run the code.
We're not going to get code when we in fact wanted it.
That's the one situation that you kind of want to avoid.
So, for example, display flex.
I don't really use feature queries with Flexbox much at all.
Why?
Because there's browsers where,
specifically Safari 8 and earlier,
where Safari 8 doesn't know what a feature query is
and it does know what Flexbox is
and I wanted to get my Flexbox structured code.
So I just don't use a feature query in that case.
You could use a feature query,
you just need to know that in fact
you're sort of excluding some of these older browsers,
Safari 6, 7, 8, from getting the Flexbox code.
That might be a fine result.
Totally depends on your use case.
Just know that that's what's going to happen.
It does mean that some of the properties that are
a little bit older, like Flexbox
have been around for several years,
they've actually been around longer than feature queries,
we might not want to use feature queries for those properties.
Any of the new properties, things coming out today,
like Initial Letter or like display grid,
it's perfectly fine to use feature queries.
Going forward they're going to be a big part of our toolbox
to help us write robust CSS that works everywhere.