# The Cascade & Global Scope

:floppy\_disk: **Inheritance and** `font-family` 

**CSS has a global scope and a local scope**. Just as in JavaScript, the **local scope has access to the parent and global scope.** In CSS, this facilitates **inheritance**.

For instance, if I apply a `font-family` declaration to the root (read: global) `html` element, I can ensure that this rule applies to all ancestor elements within the document (with a few exceptions, to be addressed in the next section).

```css

html { 
  font-family: sans-serif;
}

/* 
This rule is not needed ↷
p { 
  font-family: sans-serif;
}
*/
```

Like in JavaScript, if I declare something within the local scope, it is not available to the global — or, indeed, any ancestral — scope, but it is available to the child scope (elements within `p`). In the next example, the `line-height` of `1.5` is not adopted by the `html` element. However, the `a` element inside the `p` does respect the `line-height` value.

```css

html {
  font-family: sans-serif;
}

p {
  line-height: 1.5;
}

/* 
This rule is not needed ↷
p a {
  line-height: 1.5;
}
*/
```

:thinking: The great thing about inheritance is that you can establish the basis for a consistent visual design with very little code. And these styles will even apply to HTML you have yet to write. Talk about future-proof!

**THE ALTERNATIVE**

There are other ways to apply common styles, of course. For example, I could create a `.sans-serif` class…

```css

.sans-serif {
  font-family: sans-serif;
}
```

… and apply it to any element that I feel should have that style:

```css

<p class="sans-serif">Lorem ipsum.</p>
```

This affords me some control: I can pick and choose exactly which elements take this style and which don’t.

Any opportunity for control is seductive, but there are clear issues. Not only do I have to manually apply the class to any element that should take it (which means knowing what the class is to begin with), but in this case I’ve effectively forgone the possibility of supporting dynamic content: Neither WYSIWYG editors nor Markdown parsers provide `sans-serif` classes to arbitrary `p` elements by default.

That `class=“sans-serif”` is not such a distant relative of `style=“font-family: sans-serif”` — except that the former means adding code to both the style sheet *and* the HTML. Using inheritance, we can do less of one and none of the other. Instead of writing out classes for each font style, we can just apply any we want to the `html` element in one declaration:

```css
html {
  font-size: 125%;
  font-family: sans-serif;
  line-height: 1.5;
  color: #222;
}
```

#### The `inherit` Keyword <a href="#the-inherit-keyword" id="the-inherit-keyword"></a>

Some types of properties are not inherited by default, and some elements do not inherit some properties. But you can use `[property name]: inherit` to force inheritance in some cases.

For example, the `input` element doesn’t inherit any of the font properties in the previous example. Nor does `textarea`. In order to make sure all elements inherit these properties from the global scope, I can use the universal selector and the `inherit` keyword. This way, I get the most mileage from inheritance.

```css
* {
  font-family: inherit;
  line-height: inherit;
  color: inherit;
}

html {
  font-size: 125%;
  font-family: sans-serif;
  line-height: 1.5;
  color: #222;
}
```

Note that I’ve omitted `font-size`. I don’t want `font-size` to be inherited directly because it would override user-agent styles for heading elements, the `small` element and others. This way, I save a line of code and can defer to user-agent styles if I should want.

Another property I would not want to inherit is `font-style`: I don’t want to unset the italicization of `em`s just to code it back in again. That would be wasted work and result in more code than I need.

Now, everything either inherits or is *forced* to inherit the font styles I want them to. We’ve gone a long way to propagating a consistent brand, project-wide, with just two declaration blocks. From this point onwards, no developer has to even think about `font-family`, `line-height` or `color` while constructing components, unless they are making exceptions. This is where the cascade comes in.

#### Exceptions-Based Styling <a href="#exceptions-based-styling" id="exceptions-based-styling"></a>

I’ll probably want my main heading to adopt the same `font-family`, `color` and possibly `line-height`. That’s taken care of using inheritance. But I’ll want its `font-size` to differ. Because the user agent already provides an enlarged `font-size` for `h1` elements (and it will be relative to the `125%` base font size I’ve set), it’s possible I don’t need to do anything here.

However, should I want to tweak the font size of any element, I can. I take advantage of the global scope and only tweak what I need to in the local scope.

```css

* {
  font-family: inherit;
  line-height: inherit;
  color: inherit;
}

html {
  font-size: 125%;
  font-family: sans-serif;
  line-height: 1.5;
  color: #222;
}

h1 { 
  font-size: 3rem; 
}
```

If the styles of CSS elements were encapsulated by default, this would not be possible: I’d have to add *all* of the font styles to `h1` explicitly. Alternatively, I could divide my styles up into separate classes and apply each to the `h1` as a space-separated value:

```

<h1 class="Ff(sans) Fs(3) Lh(1point5) C(darkGrey)">Hello World</h1>
```

Either way, it’s more work and a styled `h1` would be the only outcome. Using the cascade, I’ve styled *most* elements the way I want them, with `h1` just as a special case, just in one regard. The cascade works as a filter, meaning styles are only ever stated where they add something new.<br>

## Element Styles

We’ve made a good start, but to really leverage the cascade, we should be styling as many common elements as possible. Why? Because our compound components will be made of individual HTML elements, and a screen-reader-accessible interface makes the most of semantic markup.

&#x20;:thinking: Element selectors are low in specificity, so they won’t override any class-based styles you might incorporate later.

The first thing you should do is style all of the elements that you know you’re going to need:

```css
a { … }
p { … }
h1, h2, h3 { … }
input, textarea { … }
/* etc */
```

The next part is crucial if you want a consistent interface without redundancy: Each time you come to creating a new component, **if it introduces new elements, style those new elements with element selectors**. Now is not the time to introduce restrictive, high-specificity selectors. Nor is there any need to compose a class. Semantic elements are what they are.

For example, if I’ve yet to style `button` elements (as in the previous example) and my new component incorporates a button element, this is my opportunity to style button elements **for the entire interface**.

```css
button {
  padding: 0.75em;
  background: #008;
  color: #fff;
}

button:focus {
  outline: 0.25em solid #dd0;
}
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://irena-popova.gitbook.io/boost-your-css-skills/the-cascade/the-cascade-and-global-scope.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.