6.S082 Lecture 6 More Foundational Concepts of CSS

Follow along at designftw.mit.edu/go/slides

Topics for today

Don’t
Repeat
Yourself

DRY Principle

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system

The Pragmatic Programmer, Andy Hunt and Dave Thomas

A big part of writing good code is avoidingcodeknowledgeduplication


			def right_triangle_perimeter(a, b, c):
				return a + b + c

			# ... later on
			p = right_triangle_perimeter(3, 4, 5)
  • Here, you can see a contrived example of WET Python code. c is dependent on a and b, so providing it is superfluous.
  • Not only is this an example of poor efficiency (both to write and to read), but also poor safety, since we may inadvertently provide arguments that are inconsistent.

			from math import sqrt

			def right_triangle_perimeter(a, b, c):
				return a + b + sqrt(a**2 + b**2)

			# ... later on
			p = right_triangle_perimeter(3, 4)

Keeping CSS DRY

Avoid presentational class names

Presentational class


				.red-button {
					background: hsl(0, 80%, 90%);
				}

Semantic class


				.primary-button {
					background: hsl(0, 80%, 90%);
				}

Keeping CSS DRY

Use font-relative units


				button {
					border-radius: 5px;
					padding: 5px 12px 6px;
					font-size: 24px;
					line-height: 24px;
				}
				button.large { font-size: 46px; }
			

				button {
					border-radius: .2em;
					padding: .2em .5em .25em;
					font-size: 100%;
					line-height: 1;
				}
				button.large { font-size: 200%; }

Keeping CSS DRY

Use shorthands wisely

Hardcover
Paperback
Audiobook

				.tab {
					border-radius: .3em .3em 0 0;
					padding: .1em .5em .1em .5em;
					margin: 0 .1em 0 .1em;
				}
Hardcover
Paperback
Audiobook

				.tab {
					border-radius: .3em;
					border-bottom-left-radius: 0;
					border-bottom-right-radius: 0;
					padding: .1em .5em;
					margin: 0 .1em;
				}
Note that the DRY version has more code. Short code is not the goal, maintainability is.

Overgeneralization

Rule of three Three strikes and you refactor

Duplication is far cheaper than the wrong abstraction

Sandy Metz

Selectors

h1 { font-size: 300%; line-height: 1; }
  • The selector tells the browser which elements the rule is about, in this case h1 headings.
* { margin: 0; padding: 0; box-sizing: border-box; }
  • The universal selector allows us to apply certain declarations to every element in the page.
  • It can be useful for undoing certain user agent styles, but also really dangerous. E.g. * {font-weight: normal} might seem like a reasonable default, but it means our strong elements also will start from the same non-bold baseline.

What if we want to use different criteria than element type?

#about

ID selector

Matches…

<section id="about"> <main id="about">

Doesn’t match…

<section id="about-me"> <input name="about">

.notice

Class selector

Matches…

<p class="tip notice"> <div class="notice"> <p class="important notice warning">

Doesn’t match…

<notice> <p class="foo"> <div class="warning-notice">

[href]

Attribute presence selector

Matches…

<a href="http://designftw.mit.edu"> <a href> <link rel="stylesheet" href="style.css">

Doesn’t match…

<a> <a hreflang="fr">

[type="range"]

Attribute equality selector

Matches…

<input type="range"> <yolo type="range">

Doesn’t match…

<input type="number">

First view:

  • Take a look at this list. The dividers between the list items are as prominent as the borders around the list itself, which is poor grouping.
  • How can we only target the ul? We could give it a different class name, OR we could concatenate two simple selectors (ul and .minimal) to intersect.

Second view:

  • This “minimal” class is a little presentational. We want to change it into something more semantic, e.g. “rules”, and we need to change it five times in our HTML. Furthermore, we need to remember to add this class with every new list item. Is there a better way?

Concatenating simple selectors intersects them

Compound selectors

p.notice.tip[title]#tip42 .notice.tip[title]p#tip42
button:hover { background: greenyellow; }
  • Pseudo-classes allow us to style states of an element, like an imaginary class that is added and removed automatically.

Pseudo-classes are simple selectors that allow us to style states of an element.

Here is a different style for this list. We want to eliminate the line on the last item. What can we do?

Pseudo-classes can be dynamic (activity-based) or structural (DOM tree-based)

Pseudo-classes

Dynamic

  • Mouse over element :hover
  • Currently focused :focus
  • Checked radio or checkbox :checked
  • Elements targeted by the url #hash :target

Structural

  • first child :first-child
  • last child :last-child
  • only child :only-child
  • odd children :nth-child(odd)
  • every 4th paragraph after the 8th from the end p:nth-last-of-type(4n + 8)
  • Structural pseudo-classes match elements based on their position among their siblings in the tree. Here we explore the :*-child family of pseudo-classes.
  • :first-child and :last-child match elements who are first and last among their siblings, respectively.
  • :only-child is equivalent to :first-child:last-child
  • :nth-child() is a generalization. It accepts an argument of the form An+B (e.g. 2n+1) and matches elements whose position among their siblings matches the argument for some non-negative integer n. A and B can be negative.
    • :nth-child(even) is equivalent to :nth-child(2n) and matches each 2nd, 4th, 6th etc child.
    • :nth-child(odd) is equivalent to :nth-child(2n+1) and matches each 1st, 3rd, 5th etc child.
    • :nth-child(3n+1) matches every 3rd child starting from the first.
    • :nth-child(1) is equivalent to :first-child
    • Activity: Select the first 4 items. Now select items 2-5!
  • :nth-last-child() is exactly the same as :nth-child() but starts counting from the end.
    • :nth-last-child(1) is equivalent to :last-child
    • Activity: Select the first item, only when the total count of its siblings is ≥3
  • There is also a :*-of-type family of pseudo-classes, with exactly the same syntax, that only counts elements of the same type. You can experiment with it here

Negation pseudo-class: :not()

With overrides


				a {
					text-decoration: none;
				}

				a:hover {
					text-decoration: underline;
				}

With negation


				a:not(:hover) {
					text-decoration: none;
				}
  • In the future there will be more logical pseudo-classes, e.g. :is
We have now added a nested ordered list, and our rule seems to be applying to that too. What can we do?

Combinators allow us to match on relationships between elements

footer a

Descendant combinator

a anywhere inside footer
  • footer
    • a
    • ul
      • li
        • a
      • li
        • a
      • li
        • a

ol.tasks > li

Child combinator

  • ol class="tasks"
    • li
    • li
    • ul
      • li

:checked + label

Next sibling combinator

label directly after a or

label that contains a or

label after or

h1 ~ h2

Subsequent Sibling combinator

any h2 that comes after a sibling h1 

				<section>
					<h2>
			

				<h2>
				<h1>

Why can’t any combinators look backwards?

🤔🤔🤔

CSS Selectors are just logical expressions

CSS Variables

  • CSS variables (aka Custom Properties) start with -- and behave like normal CSS properties.
  • We read their value via the var() function and we can use that anywhere (including inside calc()), except inside url().
  • They are dynamic, and can be set in the inline style or even via JavaScript!
  • They help reduce repetition, and thus make code more maintainable. They also help encapsulation: Other people can use your components and style them via the variables you have exposed, without having to know and override the internal structure of your CSS.
  • Notice the repetition here: We have to repeat the button color 3 times! And changing it requires repeating so much code. How can CSS variables help us reduce this repetition and create themes more easily?

Keeping CSS DRY

Use CSS variables custom properties

Pseudo-elements

Pseudo-elements allow us to style parts of an element

  • ::marker allows us to style list markers
  • Note that some pseudo-elements can be very limited in what properties they support. In this case, the attempt to apply filter: hue-rotate(240deg) fails, because ::marker does not support filter. (Applying it on the li works fine)
  • Pseudo-elements can also generate new content (aptly called generated content)
  • ::before emulates a text node inserted in the beginning of an element and ::after a text node inserted after every other child.
  • You cannot nest pseudo-elements to generate multiple bits of content, i.e. ::before::before is invalid (though there are discussions about enabling it in the future).

Cascading & Inheritance

CSS

The Cascade is an algorithm that defines how to combine property values originating from different sources.

Components of the Cascade

Origin

  • We have already overridden many User Agent styles and didn't think much of it. In this case, the cascade follows expectations: author stylesheets (i.e. from websites) generally have higher priority than UA stylesheets (i.e. from the browser).
  • Note that even the universal selector (*) has higher priority than any UA styles
  • This is by design: UA styles are merely a fallback for pages that have not defined any CSS.
  • There is also a third origin: user stylesheets, with higher priority than UA styles and lower than author styles. The idea was that users would write CSS to customize the websites they visit. This never really caught on, and user stylesheets are fairly rare.

Any author styles
on a given element
override any UA styles

Inheritance

First view:

  • Notice how the li, strong and em elements have the same font, font size, color as the entire list, but not the same background or padding. Why?

Second view:

  • Notice how even though there is an inherited font-weight, the strong element doesn't inherit it.
  • We can apply a different color on a list item and it takes precedence over the inherited one

    • Third view:

    • Use the value inherit to inherit from a non-inherited property.
    • However, then they are considered explicitly specified, and have the same priority as a directly applied value
    • Want the opposite? You can reset an inherited property with initial.

    Some properties are inherited, and some aren’t. Why? It's a heuristic.

    Inherited values have lower priority than directly applied values

    • Let's make a CSS speech bubble with generated content!
    • Once we get it working, how can we make it more DRY?
    • This is an example of how the inherit keyword can come in handy.
    • Note that explicitly inherited values via the inherit
    • CSS variables are inherited properties
    • Notice how we have our main colors defined on the root, and they just inherit
    • Notice how we define colors for the section on it, and they are available on its descendants too
    • What happens when there are conflicting declarations about the same element?
    • Here it’s quite obvious, since the selector is the same, so last one wins.
    • But what about here?

    Selector specificity is a heuristic for inferring importance from querying logic

    Calculating specificity

    1. If one declaration comes from a style attribute, it wins
    2. The selector with the most #id selectors wins
    3. If those are tied, count the number of .classes, :pseudo-classes (except :not()), [attributes]. The selector with the most wins.
    4. If those are also tied, count the number of element (tag) selectors. The selector with the most wins.
    5. If all of the above are tied, the specificities are equal, and conflicts are resolved in source order.
    • CSS resolves conflicts via selector specificity, not source order.
    • Specificity is calculated as follows:
      1. Count the number of ids in the selector (= A)
      2. Count the number of classes, attribute selectors, pseudo-classes (except :not()) (= B)
      3. Count the number of tag selectors (= C)
      4. Specificities are compared by comparing the three components in order: the specificity with a larger A value is bigger; if the two A values are tied, then the specificity with a larger B value is bigger; if the two B values are also tied, then the specificity with a larger C value is bigger; if all the values are tied, the two specificities are equal.
    • If specificity is the same, then the conflict is resolved based on source order.

    🤺 Specificity battle! 🤺

    >

    Selector specificity is a heuristic for inferring importance from querying logic
    So what do we do when it’s wrong?

    Adjusting specificity

    Increasing specificity

    • Repetition: .foo.foo.foo
    • Negation: :not(#nonexistent)

    Decreasing specificity

    • #foo to [id="foo"]
    • …and that's about it
    • Future: :where()