The “C” in CSS: The Cascade

Following up from Geoff’s intro article on The Second “S” in CSS, let’s now move the spotlight to the “C” in CSS — what we call the Cascade. It’s where things start to get messy, and even confusing at times.

Have you ever written a CSS property and the value doesn’t seem to work? Maybe you had to turn to using !important to get it going. Or perhaps you resorted to writing the CSS inline on the element in the HTML file.

<div style="background:orange; height:100px; width:100px;"> Ack, inline!
</div>

Speaking of inline styles, have you wondered why SVG editors use them instead of a separate CSS file? That seems kinda weird, right?

<svg id="icon-logo-star" viewBox="0 0 362.62 388.52" width="100%" height="100%"> <style> .logo { fill: #ff9800; } </style> <title>CSS Tricks Logo</title> <path class="logo" d="M156.58 239l-88.3 64.75c-10.59 7.06-18.84 11.77-29.43 11.77-21.19 0-38.85-18.84-38.85-40 0-17.69 14.13-30.64 27.08-36.52l103.6-44.74-103.6-45.92C13 142.46 0 129.51 0 111.85 0 90.66 18.84 73 40 73c10.6 0 17.66 3.53 28.25 11.77l88.3 64.75-11.74-104.78C141.28 20 157.76 0 181.31 0s40 18.84 36.5 43.56L206 149.52l88.3-64.75C304.93 76.53 313.17 73 323.77 73a39.2 39.2 0 0 1 38.85 38.85c0 18.84-12.95 30.61-27.08 36.5l-103.61 45.91L335.54 239c14.13 5.88 27.08 18.83 27.08 37.67 0 21.19-18.84 38.85-40 38.85-9.42 0-17.66-4.71-28.26-11.77L206 239l11.77 104.78c3.53 24.72-12.95 44.74-36.5 44.74s-40-18.84-36.5-43.56z"></path>
</svg>

Well, the cascade has a lot to do with this. Read on to find out how styling methods affect what’s being applied to your elements and how to use the cascade to your advantage because, believe me, it’s a wonderful thing when you get the hang of it.

TL;DR: Jump right to the CSS order diagram for a visual of how everything works.

The cascade cares about how and where styles are written

There are a myriad of ways you can apply CSS rules to an element. Below is an example of how stroke: red; can be applied to the same element. The examples are ordered in ascending priority, where the highest priority is at the bottom:

<!-- Inheritance -->
<g style="stroke: red"> <rect x="1" y="1" width="10" height="10" /> <!-- inherits stroke: red -->
</g> <!-- Inline attributes -->
<rect x="1" y="1" width="10" height="10" stroke="red" /> <!-- External style sheet -->
<link rel="stylesheet" href="/path/to/stylesheet.css"> <!-- Embedded styles -->
<style> rect { stroke: red; }
</style> <!-- Different specificity or selectors -->
rect { stroke: red; }
.myClass { stroke: red; }
#myID { stroke: red; } <!-- Inline style -->
<g style="stroke: red"></g> <!-- Important keyword -->
<g style="stroke: red !important"></g>

Inheritance? Embedded? External? Inline? Specificity? Important? Yeah, lots of terms being thrown around. Let’s break those down a bit because each one determines what the browser ends up using when a web page loads.

Elements can inherit styles from other elements

Both HTML and SVG elements can inherit CSS rules that are applied to other elements. We call this a parent-child relationship, where the element the CSS is applied to is the parent and the element contained inside the parent is the child.

<div class="parent"> <div class="child">I'm the child because the parent is wrapped around me.</div>
</div>

If we set the text color of the parent and do not declare a text color on the child, then the child will look up to the parent to know what color its text should be. We call that inheritance and it’s a prime example of how a style cascades down to an element it matches… or “bubbles up” the chain to the next matched style.

However, inheritance has the lowest priority among styling methods. In other words, if a child has a rule that is specific to it, then the inherited value will be ignored, even though the inherited value may have an important keyword. The following is an example:

<div class="parent" style="color: red !important;"> <div class="child">I'm the child because the parent is wrapped around me.</div>
</div>

See the Pen Child ignores inline inheritance with !important by Geoff Graham (@geoffgraham) on CodePen.

SVG inline attributes

For SVG elements, we can also apply styles using inline attributes, where those have the second lowest priority in the cascade. This means the CSS rules in a stylesheet will be able to override them.

<rect x="1" y="1" width="10" height="10" stroke="red" />
rect { stroke: blue;
}

See the Pen Stylesheet overrides SVG inline attributes by Geoff Graham (@geoffgraham) on CodePen.

Most SVG editors use inline attributes for portability; that is, the ability to copy some elements and paste them elsewhere without losing the attributes. Users can then use the resultant SVG and style its elements using an external stylesheet.

Stylesheets

Stylesheets are divided into two flavors: external and embedded:

<!-- External style sheet -->
<link rel="stylesheet" href="/path/to/stylesheet.css"> <!-- Embedded styles -->
<style> div { border: 1px solid red }
</style>

Embedded styles have the same priority as external stylesheets. Therefore, if you have the same CSS rules, ordering rules applies.

See the Pen Embedded styles override stylesheet rules by Geoff Graham (@geoffgraham) on CodePen.

All stylesheets follow ordering rules, where files that are defined later, will have higher priority than those defined earlier. In this example, stylesheet-2.css will take precedence over the stylesheet-1.css file because it is defined last.

<link rel="stylesheet" href="/path/to/stylesheet-1.css">
<link rel="stylesheet" href="/path/to/stylesheet-2.css">

Specificity or selectors

How you select your elements will also determine which rules are applied, whereby tags (e.g. <p>, <div>), classes (e.g. .my-class) and IDs (e.g. #myI-id) have ascending priorities.

See the Pen Specificity by selectors by Geoff Graham (@geoffgraham) on CodePen.

In the example above, if you have a div element with both .my-class and #my-id, the border will be red because IDs have higher priority than classes and tags.

*Specificity has higher priority than ordering rules, therefore, irrespective if your rule is at the top or bottom. Specificity still has higher priority and will be applied.

Ordering

CSS rules always prioritize from left-to-right, then from top-to-bottom.

<!-- Blue will be applied because it is on the right -->
<div style="border: 1px solid red; border: 1px solid blue;"></div> <style> div { border: 1px solid red; border: 1px solid blue; /* This will be applied because it is at the bottom */ }
</style>

Inline styles

Inline styles have the second highest priority, just below the !important keyword. This means that inline styles are only overridden by the important keyword and nothing else. Within inline styles, normal ordering rules applies, from left-to-right and top-to-bottom.

<div style="1px solid red;"></div>

The important keyword

Speaking of the !important keyword, it is used to override ordering, specificity and inline rules. In other words, it wields incredible powers.

Overriding inline rules

<style> div { /* This beats inline styling */ border: 1px solid orange !important; /* These do not */ height: 200px; width: 200px; }
</style> <div style="border: 1px solid red; height: 100px; width: 100px;"></div>

In the example above, without the important keyword, the div would have a red border because inline styling has higher priority than embedded styles. But, with the important keyword, the div border becomes orange, because the important keyword has higher priority than inline styling.

Using !important can be super useful, but should be used with caution. Chris has some thoughts on situations where it makes sense to use it.

Overriding specificity rules

Without the important keyword, this div border will be blue, because classes have higher priority than tags in specificity.

<style> /* Classes have higher priority than tags */ .my-class { border: 1px solid blue; height: 100px; width: 100px; } div { border: 1px solid red; height: 200px; width: 200px; }
</style> <div class="my-class"></div>

See the Pen Classes beat tags by Geoff Graham (@geoffgraham) on CodePen.

But! Adding the important keyword to the tag rules tells the element to ignore the cascade and take precedence over the class rules.

<style> .my-class { border: 1px solid red; } /* The important keyword overrides specificity priority */ .my-class { border: 1px solid blue !important; }
</style> <div class="my-class"></div>

See the Pen !important ignores the cascade by Geoff Graham (@geoffgraham) on CodePen.

Overriding ordering rules

OK, so we’ve already talked about how the order of rules affects specificity: bottom beats top and right beats left. The surefire way to override that is to put !important into use once again.

In this example, the div will take the red border, even though the blue border is the bottom rule. You can thank !important for that handiwork.

<style> div { border: 1px solid red !important; } /* This wins, despite the ordering */ div { border: 1px solid blue; }
</style> <div></div>

See the Pen Important wins over ordering by Geoff Graham (@geoffgraham) on CodePen.

Visualizing the cascade

Who knew there was so much meaning in the “C” of CSS? We covered a ton of ground here and hopefully it helps clarify the way styles are affected and applied by how we write them. The cascade is a powerful feature. There are opinions galore about how to use it properly, but you can see the various ways properties are passed and inherited by elements.

More of a visual learner? Here’s a chart that pulls it all together.

Download chart

The post The “C” in CSS: The Cascade appeared first on CSS-Tricks.

What’s the difference between ./dogs.html and /dogs.html?

They are both URL paths. They have different names, though.

<!-- root-relative -->
<a href="./dogs.html">Dogs</a> <!-- absolute -->
<a href="/dogs.html">Dogs</a>

There are also fully-qualified URLs that would be like:

<!-- fully qualified -->
<a href="https://website.com/dogs.html">Dogs</a>

Fully-qualified URL’s are pretty obvious in what they do — that link takes you to that exact place. So, let’s look those first two examples again.

Say you have a directory structure like this on your site:

public/
├── index.html
└── animals/ ├── cats.html └── dogs.html

If you put a link on cats.html that links to /dogs.html (an “absolute” path), it’s going to 404 — there is no dogs.html at the base/root level of this site! The / at the beginning of the path means “start at the very bottom level and go up from there” (with public/ being the very bottom level).

That link on cats.html would need to be written as either ./dogs.html (start one directory back and work up) or /animals/dogs.html (explicitly state which directory to start at).

Absolute URLs get longer, naturally, the more complex the directory structure.

public/
├── animals/ └── pets/ ├── c/ | └── cats.html └── d/ └── dogs.html

With a structure like this, for dogs.html to link to cats.html, it would have to be either…

<!-- Notice the TWO dots, meaning back up another folder level -->
<a href="../c/cats.html">cats</a> <!-- Or absolute -->
<a href="/animals/pets/c/cats.html">cats</a>

It’s worth noting in this scenario that if animals/ was renamed animal/, then the relative link would still work, but the absolute link would not. That can be a downside to using absolute links. When you’re that specific, making a change to the path will impact your links.

We’ve only looked at HTML linking to HTML, but this idea is universal to the web (and computers, basically). For example, in a CSS file, you might have:

body { /* Back up one level from /images and follow this path */ background-image: url(./images/pattern.png);
}

…which would be correct in this situation:

public/
├── images/
| └── pattern.png
├──index.html
└── style.css

But if you were to move the CSS file…

public/
├── images/
| └── pattern.png
├── css/
| └── style.css
└── index.html

…then that becomes wrong because your CSS file is now nested in another directory and is referencing paths from a deeper level. You’d need to back up another folder level again with two dots, like ../images/pattern.png.

One URL format isn’t better than another — it just depends on what you think is more useful and intuitive at the time.

For me, I think about what is the least likely thing to change. For something like an image asset, I find it very unlikely that I’ll ever move it, so linking to it with an absolute URL path (e.g. /images/pattern.png) seems the safest. But for linking documents together that all happen to be in the same directory, it seems safer to link them relatively.

The post What’s the difference between ./dogs.html and /dogs.html? appeared first on CSS-Tricks.

Helping a Beginner Understand Getting a Website Live

I got a great email from a fellow named Josh Long the other day. He is, in his words, “relatively new to web design” and was a bit stuck on the concept of getting a site live. I should say that I’m happy to get emails like this an I always read them, but I typically can’t offer tech support over email. If I can respond at all, I normally point people to other community resources.

In this case, it struck me what a perfect moment this is for Josh. He’s a little confused, but he knows enough to be asking a lot of questions and sorting through all this stuff. I figured this was a wonderful opportunity to dig into his questions, hopefully helping him and just maybe helping others in a similar situation.

Here’s one of the original paragraphs Josh sent me, completely unedited:

I’m relatively new to web design, but I’ve taken a few courses on HTML and CSS and I’ve done a Codecademy course on JavaScript. But, (jumping forward probably quite a while here!) after having fully designed and coded a HTML/CSS/JS website or webpage, I don’t fully understand the full process of going from a local site hosted with mamp/wamp to publishing a public site using wordpress(?) or some other host (is WordPress even a host?!) and also finding a server that’s suitable and some way of hosting images/videos or other content. (If that sounded like I didn’t know what half of those meant, it’s because unfortunately I don’t!.. but I’d really like to!)

Can you sense that enthusiasm? I love it.

We worked together a bit to refine many of his questions for this post, but they are still Josh’s words. Here we go!


What is a Domain Registrar? I get they are for registering domain names, but what’s the difference between them? How do you know which one is right for you? A quick search for “best domain hosts” on Google gave me 5 ads for companies who are domain registrars/hosts and 9 “Top 10” style pages that look as though they have some sort of affiliation with at least one company they’re suggesting. Am I just looking for the cheapest one?

You’re exactly right, domain registrants are for registering domain names. If you want joshlongisverycool.com, you’re going to have to buy it, and domain registrants are companies that help you do that.

Searching for a domain name

It’s a bummer that web search results are so saturated by ads and affiliate-link-saturated SEO-jacked pages. You’ll never get total honesty from that because those pages are full of links promoting whoever will pay them the most to send new customers. Heck, even Google themselves will sell you a domain name.

The truth is that you can’t go too wrong here. Domain names are a bit of a commodity and the hundreds of companies that will sell you one largely compete on marketing.

Some things to watch out for:

  • Some companies treat the domain as a loss leader. Like a grocery store selling cheap milk to hope you buy some more stuff while you are there. The check out process at any domain registrant will almost certainly try to sell you a bunch of extra stuff. For example, they might try to sell you additional domain names or email hosting you probably don’t need. Just be careful.
  • Web hosts (which we’re getting to next) will often sell them to you along with hosting. That’s fine I suppose, but I consider it a bit of a conflict of interest. Say you choose to move hosts one day. That hosting company is incentivized in the wrong direction to make that easy for you. If the domain is handled elsewhere, that domain registrant is incentivized the right direction to help you make changes.

I hate to add to the noise for you, but here are some domain registrants that I’ve used personally and aren’t paying for sponsorship here nor are affiliate links:

  • Hover
  • GoDaddy
  • Google Domains
  • Network Solutions
  • Amazon Route 53

Our own Sarah Drasner recommends looking at ZEIT domains, which are super interesting in that you buy and manage them entirely over the command line.

I might suggest, if you can see yourself owning several domain names in your life, keeping them consolidated to a single registrant. Managing domains isn’t something you’ll do very often, so it’s easy to lose track of what domains you registered on what registrant, not to mention how/where to change all the settings across different registrants.

I’d also suggest it’s OK to experiment here. That’s how all of us have learned. Pick one with a WP Engine is a web host that focuses specifically on WordPress.

  • Media Temple has WordPress-specific hosting, but has a wider range of services from very small and budget friendly to huge and white-glove.
  • BlueHost is has very inexpensive hosting choices, but has essentially the same capabilities as those others.
  • Now here some other web hosts that are a little less traditional. Forgive the techy terms here — if they don’t mean anything to you, just ignore them.

    • Netlify does static site hosting, which is great for things like static site generators and JAMstack sites.
    • Zeit is a host where you interact with it only through the command line.
    • Digital Ocean has their own way of talking about hosting. They call their servers Droplets, which are kind of like virtual machines with extra features.
    • Heroku is great for hosting apps with a ready-to-use backend for things like Node, Ruby, Java, and Python.
    • Amazon Web Services (AWS) is a whole suite of products with specialized hosting focuses, which are for pretty advanced users. Microsoft Azure and Google Cloud are similar.

    Again, I’d say it’s OK to, in a sense, make some mistakes here. If you aren’t hosting something particularly mission-critical, like your personal website, pick a host that seems to fit the bill and give it a go. Hopefully, it works out great — if not, you can move. Moving isn’t always super fun, but everybody ends up doing it, and you’ll learn as you go.

    When you buy web hosting, that host is going to tell you how to use it. One common way is that the host will give you WordPress and CraftCMS. They don’t really have anything directly to do with that connection between working locally on a site and getting that site live. But they do rather complicate it.

    The reason that you’d use a CMS at all is to make working on your site easier. Consider this site you’re looking at right now. There are tens of thousands of pages on this site. It would be untenable for each of them to be a hand-authored file.html file.

    Instead, a CMS allows us to craft all those pages by combining data and templates.

    Let’s consider the technology behind WordPress, a CMS that works pretty good for CSS-Tricks. In order for WordPress to run, it needs:

    1. PHP (the back-end language)
    2. MySQL (the database)
    3. Apache (the web server)

    You can do all that locally!

    I use Local by Flywheel for that (Mac and Windows), but there are a number of ways to get those technologies running: MAMP, Docker, Vagrant, etc.

    That’ll get you up and running locally with your CMS. That’s a beautiful thing. Having a good local development environment for your site is crucial. But it doesn’t help you get that site live.

    We’ll go over getting all this to a live site a bit later, but you should know this: the web server that you run will need to run these same technologies. Looking at the WordPress example from above, your web server will also need to run PHP, MySQL, and Apache. Then you’ll need to set up a system for getting all your files from your local computer to your web server like you would for any other site, but also probably have a system for dealing with the database. The database is a bit tricky as it’s not a “flat file” like most of the rest of your site.

    A CMS could be built from any set of technologies, not just the ones listed above. For example, see KeystoneJS. Instead of PHP, Keystone is Node.js. Instead of MySQL for the database, it uses MongoDB. Instead of Apache, it uses Express. Just a different set of technologies. Both of which you can get running locally and on a live web server.

    A CMS could even have no database at all! Static site generators are like this. You get the site running locally, and they produce a set of flat files which you move to your live server. A different way to do things, but absolutely still a CMS. What I always say is that the best CMS is one that is customized to your needs.


    What is “Asset Hosting”? Are assets not content? What is the difference between a CMS and an asset hosting service? What does an asset host do?

    Let’s define an asset: any “flat” file. As in, not dynamically generated like how a CMS might generate an HTML file. Images are a prime example of an “asset.” But it’s also things like CSS and JavaScript files, as well as videos and PDFs.

    And before we get any further: you probably don’t need to worry about this right away. Your web host can host assets and that’s plenty fine for your early days on small sites.

    One major reason people go with an asset host (probably more commonly referred to as a CDN or Content Delivery Network) is for a speed boost. Asset hosts are also servers, just like your web host’s web server, but they are designed for hosting those flat file assets super fast. So, not only do those assets get delivered to people looking at your site super fast, but your web server is relieved of that burden.

    You could even think of something like YouTube as an asset host. That 100 MB video of a butterfly in your garden is a heavy load for your little web server, and potentially a problem if your outgoing bandwidth is capped like it often is. Uploading that video to YouTube puts your video into that whole social universe, but a big reason to do it other than the social stuff is that it’s hosting that video asset for you.


    I’ve heard of “repositories”, but don’t really get what they are. I hear stuff like “just upload it to my Git Repository.” What the heck does that mean? I feel like a moron for asking this. What is Git? What is it for? Do I need to use it? Is it involved in the “local to live” process at all?

    Sorry you got hit with a “just” there. There is an epidemic in technology conversations where people slip that in to make it seem like what they are about to say is easy and obvious when it could be neither depending on who is reading.

    But let’s get into talking about Git repositories.

    Git is a specific form of version control. There are others, but Git is so dominant in the web industry that it’s hardly worth mentioning any others.

    Let’s say you and me are working on a website together. We’ve purchased a domain and hosting and gotten the site live. We’ve shared the SFTP credentials so we both have access to change the files on the live site. This could be quite dangerous!

    Coda is a code editor that let’s you edit files directly on a sever you’ve connected to over SFTP. Cool, but dangerous!

    Say we both edit a file and upload it over SFTP… which change wins? It’s whoever uploaded their file last. We have no idea who has done what. We’re over-writing each other and have no way of staying in sync with each other’s changes, changes immediately affect the live site which could break things and we have no way of undoing changes in case we break things. That’s a situation so unacceptable that it’s really never done.

    Instead, we work with version control, like Git. With Git, when we make changes, we commit them to a repository. A repository can be hosted anywhere, even on your local machine. But to make them really useful, they are hosted on the internet somewhere everyone has access to. You’ve surely seen GitHub, which hosts these repositories and adds a bunch of other features like issue tracking. Similar are GitLab and Bitbucket.

    Now let’s say you and me are working on that same site, but we’ve set up a Git repository for it. When I make a change, I commit it to the repository. If you want to make a change as well, you have to pull my changes down which merges them into your own copy of the code. Then you can push your changes up to the repository. Like anything, it gets more complicated, but that’s the gist of it.

    But a Git repository isn’t the live website. You’re on your own for getting the files from a Git repository to a live site. Fortunately, that’s a situation that everyone faces, so there are lots of options. Good thing your last question is about this!


    OK. So now with all that straight… where do you start with going from local to live? Where do you “upload” your HTML, CSS and JavaScript files? How do you link your shiny new domain name to those files and see it out in the wild? Which service is in charge of adding new content to your site, or updating it? Does it get really confusing if you have different companies for each service?

    Let’s start with a very simple website on what I’d consider typical web hosting. Say you have just index.html, style.css, and script.js files on your local computer which is your entire website. You’ve purchased a domain name and pointed the DNS settings at a web host. That host has given you SFTP credentials. You’ll use those credentials in an app that allows SFTP connections to log in:

    Your host will also tell you which folder is the “public root” of your website. The files there will be out on the public internet for the world to see!

    You might hear people refer to the “live” website as a “production” site. When someone asks something like, Did that bug make it to production?” they mean whether the bug is on the live website. “Development” is your local computer. You might also have a “Staging” site, which is a clone of the live website on the same hardware/software of the live site for testing.

    Remember earlier when we talked about Git repositories? While the repositories themselves don’t directly help you get the files in them to your web server, most systems that help you with the local-to-live process work with your repositories.

    The phrase “local-to-live” refers to deployment. When you have changes that you want to go out to your production website, you deploy them. That’s the process of moving your work from “development” to “production.”

    One service that helps with this idea of deployment is Beanstalk. Beanstalk hosts your Git repository, plus you give it the SFTP credentials for your server — that way it can move the files to your web server when you make commits. Cool right? Say you wanted to host that Git repo elsewhere though, like GitHub, Bitbucket, or Gitlab. Check out DeployBoy, which does the same thing, only it can connect to those sites as well. It probably comes as no surprise by now that there are lots of options here, ranging in price and complexity.

    Let’s go back to our WordPress example.

    1. You’ve got it running locally (on your computer) just perfectly and now want to go live with it.
    2. You’ve bought a domain name from a registrar.
    3. You’ve purchased hosting that meets WordPress requirements.
    4. You’ve pointed the DNS of the domain name at the web host.
    5. You’ve verified it’s all working (easy way: upload an index.html file in the public root via SFTP and verify that it loads when you type you type the domain name into a browser.)

    Now, you’ve still got some work to do:

    1. Set up a Git repository for the site.
    2. Set up a deployment service to move the files from the repository to the live site.
    3. Configure/Set up the live site as needed. For example, you’ll need a database on the live site. You’ll have to create that (your host will have instructions) and do things like run the WordPress installer and update configuration files.
    4. If you have things in your local database that you want to move to the live site, you might be exporting/importing things. That can happen at the raw MySQL level using WordPress’ native import/export features, or a fancy plugin like WP DB Migrate Pro.

    It’s a non-trivial amount of work! Sorry. This process is pretty similar for any site though. It’s a matter of configuring and setting up your production web server exactly how it should be, then deploying files to it. Every site is a bit different, but you’ll get the hang of this whole dance.

    It really is a big dance. I’ve only painted one picture for you here. I tried to pick one that was generic and broad enough that it shows the landscape of what needs to be done. But, at every step in this dance, there are different ways you can do things, different services you can pick, companies trying to help you at different pain points… it’s an ever-changing world.

    Right now, Netlify is enjoying a lot of popularity because they are one of the only web hosts that actually helps you with deployment. They’ll watch your Git repositories and do deployment for you! Netlify is for static sites only, but that can be a whole world onto itself. ZEIT also is massively innovative in how it helps with deploying and hosting web projects, including directly connecting with GitHub.


    Good luck!

    I hope this was helpful. Remember, you aren’t alone in all this. Zillions of other developers have done this before you and there is help to be found on the internet.

    Oh, and remember: the best way to learn anything at all is to…


    https://css-tricks.com/wp-content/uploads/2018/08/jbw.mp3

    The post Helping a Beginner Understand Getting a Website Live appeared first on CSS-Tricks.

    Methods, Computed, and Watchers in Vue.js

    One of the reasons I love working with Vue is because of how useful methods, computed, and watchers are, and the legibility of their distinction. Until understanding all three, it’s difficult to leverage the functionality of Vue to its full potential. Still, the majority of people I see confused about this framework tend to also be confused about the differences here, so let’s dig in.

    In case you need a quick answer and don’t have time to read through the entire article, here’s a small TL;DR:

    • Methods: These are exactly what they sound like they might be (yay, naming!). They’re functions that hang off of an object—typically the Vue instance itself or a Vue component.
    • Computed: These properties may at first look like they’d be used like a method, but are not. In Vue, we use data to track changes to a particular property that we’d like to be reactive. Computed properties allow us to define a property that is used the same way as data, but can also have some custom logic that is cached based on its dependencies. You can consider computed properties another view into your data.
    • Watchers: These are allowing you a peek into the reactivity system. We’re offered some hooks with which to observe any properties that are stored by Vue. If we want to add a bit of functionality each time something changes, or respond to a particular change, we could watch a property and apply some logic. This means that the name of the watcher has to match what we’re trying to observe.

    If any of this sounds confusing, don’t worry! We’ll dive in further below and hopefully address any confusion. If you’re familiar with vanilla JavaScript already, methods may be pretty obvious to you, aside from one or two caveats. It might then behoove you (I love that phrase) to skip to the Computed and Watchers sections.

    Methods

    Methods are likely something you’re going to use a lot while working with Vue. They’re aptly named as, in essence, we’re hanging a function off of an object. They’re incredibly useful for connecting functionality to directives for events, or even just creating a small bit of logic to be reused like any other function. You can call a method within another method, for example. You can also call a method inside a lifecycle hook. They’re very versatile.

    Here’s a simple demo to demonstrate:

    See the Pen Slim example of methods by Sarah Drasner (@sdras) on CodePen.

    <code class="language-css"><div id="app"> <button @click="tryme">Try Me</button> <p>{{ message }}</p>
    </div>
    new Vue({ el: '#app', data() { return { message: null } }, methods: { tryme() { this.message = Date() } }
    })

    We could have also executed the logic in the directive itself like <button @click="message = Date()">Try Me</button>, which works very well for this small example. However, as the complexity of our application grows, it’s more common to do as we see above to break it out to keep it legible. There’s also a limit to the logic that Vue will allow you to express in a directive—for instance, expressions are allowed but statements are not.

    You may notice that we’re be able to access this method within that component or Vue instance, and we can call any piece of our data here, in this case, this.message. You don’t have to call a method like you’d call a function within a directive. For example, @click=”methodName()” is unnecessary. You can reference it with @click=”methodName”, unless you need to pass a parameter, such as @click=”methodName(param)”.

    Using directives to call methods is also nice because we have some existing modifiers. One such example that’s very useful is .prevent, which will keep a submit event from reloading the page, used like this:

    <form v-on:submit.prevent="onSubmit"></form>

    There are many more, here are just a few.

    Computed

    Computed properties are very valuable for manipulating data that already exists. Anytime you’re building something where you need to sort through a large group of data and you don’t want to rerun those calculations on every keystroke, think about using a computed value.

    Some good candidates include, but are not limited to:

    • Updating a large amount of information while a user is typing, such as filtering a list
    • Gathering information from your Vuex store
    • Form validation
    • Data visualizations that change depending on what the user needs to see

    Computed properties are a vital part of Vue to understand. They are calculations that will be cached based on their dependencies and will only update when needed. They’re extremely performant when used well and extraordinarily useful. There are many large libraries that handle this kind of logic that you can now eliminate with only a few lines of code.

    Computed properties aren’t used like methods, though at first, they might look similar- you’re stating some logic in a function and returning- but the name of that function becomes a property that you’d then use in your application like data.

    If we needed to filter this big list of names of heroes based on what the user was typing, here’s how we would do it. We’re keeping this really simple so you can get the base concepts down. Originally our list would output in our template using names, which we store in data:

    new Vue({ el: '#app', data() { return { names: [ 'Evan You', 'John Lindquist', 'Jen Looper', 'Miriam Suzanne', ... ] } }
    })
    <div id="app"> <h1>Heroes</h1> <ul> <li v-for="name in names"> {{ name }} </li> </ul>
    </div>

    Now let’s create a filter for those names. We’ll start by creating an input with v-model that will originally be an empty string, but we’ll eventually use to match and filter through our list. We’ll call this property findName and you can see it referenced both on the input and in the data.

    <label for="filtername">Find your hero:</label>
    <input v-model="findName" id="filtername" type="text" />
    data() { return { findName: '', names: [ 'Evan You', 'John Lindquist', ... ] }
    }

    Now, we can create the computed property that will filter all of the names based on what the user has typed into the input, so anything in our findName property. You’ll note that I’m using regex here to make sure that mismatched capitalization doesn’t matter, as users will typically not capitalize as they type.

    computed: { filteredNames() { let filter = new RegExp(this.findName, 'i') return this.names.filter(el => el.match(filter)) }
    }

    And now we’ll update what we’re using in the template to output from this:

    <ul> <li v-for="name in names"> {{ name }} </li>
    </ul>

    …to this:

    <ul> <li v-for="name in filteredNames"> {{ name }} </li>
    </ul>

    And it filters for us on every keystroke! We only had to add a couple of lines of code to make this work, and didn’t have to load any additional libraries.

    See the Pen Filter a list with Computed- end by Sarah Drasner (@sdras) on CodePen.

    I can’t tell you how much time I save by using them. If you’re using Vue and haven’t explored them yet, please do, you’ll thank yourself.

    Watchers

    Vue has nice abstractions, and anyone who has been a programmer for a while will usually tell you that abstractions can be a pain because you’ll eventually get to a use case they can’t solve. However, this situation is accounted for, because Vue grants us some deeper access to into the reactivity system, which we can leverage as hooks to observe anything that’s changing. This can be incredibly useful because, as application developers, most of what we’re responsible for are things that change.

    Watchers also allow us to write much more declarative code. You’re no longer tracking everything yourself. Vue is already doing it under the hood, so you can also have access to changes made to any properties it’s tracking, in data, computed, or props, for example.

    Watchers are incredibly good for executing logic that applies to something else when a change on a property occurs (I first heard this way of putting it from Chris Fritz, but he says he might have also heard it from someone else ☺️). This isn’t a hard rule- you can absolutely use watchers for logic that refers to the property itself, but it’s a nice way of looking at how watchers are immediately different from computed properties, where the change will be in reference to the property we intend to use.

    Let’s run through the most simple example possible so you get a taste of what’s happening here.

    new Vue({ el: '#app', data() { return { counter: 0 } }, watch: { counter() { console.log('The counter has changed!') } }
    })

    As you can see in the code above, we’re storing counter in data, and by using the name of the property as the function name, we’re able to watch it. When we reference that counter in watch, we can observe any change to that property.

    Transitioning State With Watchers

    If the state is similar enough, you can even simply transition the state with watchers. Here’s an example I built from scratch of a chart with Vue. As the data changes, the watchers will update it and simply transition between them.

    SVG is also good for a task like this because it’s built with math.

    See the Pen Chart made with Vue, Transitioning State by Sarah Drasner (@sdras) on CodePen.

    watch: { selected: function(newValue, oldValue) { var tweenedData = {} var update = function () { let obj = Object.values(tweenedData); obj.pop(); this.targetVal = obj; } var tweenSourceData = { onUpdate: update, onUpdateScope: this } for (let i = 0; i < oldValue.length; i++) { let key = i.toString() tweenedData[key] = oldValue[i] tweenSourceData[key] = newValue[i] } TweenMax.to(tweenedData, 1, tweenSourceData) }
    }

    What happened here?

    • First we created a dummy object that will get updated by our animation library.
    • Then we have an update function that is invoked on each tween step. We use this to push the data.
    • Then we create an object to hold the source data to be tweened and the function pointer for update events.
    • We create a for loop, and turn the current index into a string
    • Then we can tween over the our target dummy object, but we’ll only do this for the specific key

    We could also use animation in watchers to create something like this time difference dial. I travel a bit and all my coworkers are in different areas, so I wanted a way to track what local time we were all in, as well as some signification of the change from daytime/nighttime as well.

    See the Pen Vue Time Comparison by Sarah Drasner (@sdras) on CodePen.

    Here we’re watching the checked property, and we’ll fire different methods that contain timeline animations that change the hue and saturation and some other elements based on the relative association to the current time. As mentioned earlier- the change occurs on the dropdown, but what we’re executing is logic that’s applied elsewhere.

    watch: { checked() { let period = this.timeVal.slice(-2), hr = this.timeVal.slice(0, this.timeVal.indexOf(':')); const dayhr = 12, rpos = 115, rneg = -118; if ((period === 'AM' && hr != 12) || (period === 'PM' && hr == 12)) { this.spin(`${rneg - (rneg / dayhr) * hr}`) this.animTime(1 - hr / dayhr, period) } else { this.spin(`${(rpos / dayhr) * hr}`) this.animTime(hr / dayhr, period) } }
    },

    There are also a number of other interesting things about watchers, for instance: we’re given access to both the new and old versions of the property as parameters, we can specify deep if we’d like to watch a nested object. For more detailed information, there’s a lot of good information in the guide.

    You can see how watchers can be incredibly useful for anything that’s updating—be it form inputs, asynchronous updates, or animations. If you’re curious how reactivity in Vue works, this part of the guide is really helpful. If you’d like to know more about reactivity in general, I really enjoyed Andre Staltz’ post and the Reactivity section of Mike Bostock’s A Better Way to Code.

    Wrapping Up

    I hope this was a helpful breakdown on how to use each, and speeds up your application development process by using Vue efficiently. There’s a stat out there that we spend 70% of our time as programmers reading code and 30% writing it. Personally, I love that, as a maintainer, I can look at a codebase I’ve never seen before and know immediately what the author has intended by the distinction made from methods, computed, and watchers.

    The post Methods, Computed, and Watchers in Vue.js appeared first on CSS-Tricks.

    CSS Basics: Fallback Font Stacks for More Robust Web Typography

    In CSS, you might see a ruleset like this:

    html { font-family: Lato, "Lucida Grande", Tahoma, Sans-Serif;
    }

    What the heck, right? Why don’t I just tell it what font I want to use and that’s that? The whole idea here is fallbacks. The browser will try to use the font you specified first (Lato, in this case), but if it doesn’t have that font available, it will keep going down that list. So to be really verbose here, what that rule is saying is:

    1. I’d like to use the Lato font here, please.
    2. If you don’t have that, try “Lucida Grande” next.
    3. If you don’t have that, try Tahoma.
    4. All else fails, use whatever you’ve got for the generic keyword Sans-Serif

    So in what situation would a browser not have the font you’re asking for? That’s pretty common. There are only a handful of fonts that are considered “web safe”—meaning that it’s likely most computers visiting your site have that font installed and so the browser can use it. Think: Arial, Times New Roman, Courier, Georgia, Verdana, and a handful of others.

    But most websites, these days, use custom web fonts. They load up a font as a resource (just as a website loads CSS itself as a resource, or an image, or JavaScript), then that font is available to use. The widely popular Google Fonts makes that pretty clear:

    Load this font first, then you can use it in CSS.

    Even when you load a font in this way, it’s still possible that the font doesn’t load. While Google is a generally very reliable host, you don’t control their servers; they do. Even more commonly, poor network connections may prevent a font from loading. In any font loading failure scenario, that’s another situation where a fallback font stack comes in handy.

    Say I’m using the custom font Merriweather, and I set up my font stack like this:

    html { font-family: Merriweather, Impact, Serif;
    }

    If Merriweather fails to load (or does load, but loads in such a way that it pops into place after it does—also known as FOUT), we’d see something like this:

    A fallback font, in this case Impact, is seen. It’s incredibly awkward and doesn’t match the desired look at all.

    Better to have your font fall back to something close to your top choice than to something totally unrelated! There is a fantastic tool by Monica Dinculescu call Font style matcher where you can play with fallbacks (that’s how I made that GIF above).

    In the example above, we can see that Georgia is a much nicer fallback font than Impact is! The example is a little bit more fancy than just changing the font though. A couple of other settings were changed to make them match as closely as they are. To take advantage of that, you’re in font loading territory, which gets a bit complex. Your best bet there is consulting Zach Leatherman’s A Comprehensive Guide to Font Loading. In any case, picking a nice fallback font alone is worth doing.

    Individual Characters

    An interesting note about fallback fonts is that it’s not all-or-nothing. Individual characters in a font can fall down the stack if the specified font doesn’t have that character available.

    As an extreme example, I’ll load the custom font Source Code Pro from Google Fonts but I’ll force it to only contain a handful of letters.

    You can see in the first sentence how the fallback fonts took over and the end result wasn’t disastrous (like the second sentence) even though the custom font didn’t have some of the characters available. This will be more likely to happen with things like uncommon ASCII characters or even accented characters like ü, ā, or ñ.

    As some side fun, here’s using that character fallback ability of CSS to do something unique:

    See the Pen Ransom Note With Google Font Subsets by Heydon (@heydon) on CodePen.

    More Reading

    • Font Stack Snippets: Some common font stacks
    • CSS Font Stack: A collection of web safe CSS font stacks
    • System Font Stack: A snippet that uses the computer’s default system font

    CSS Basics: Fallback Font Stacks for More Robust Web Typography is a post from CSS-Tricks

    CSS Basics: Styling Links Like a Boss

    The web was founded on links. The idea that we can click/tap a link and navigate from one web page to another is how surfin’ the web become a household phrase.

    Links in HTML even look different from regular text without any CSS styling at all.

    See the Pen Default Link by CSS-Tricks (@css-tricks) on CodePen.

    They are blue (purple if visited). They are underlined. That’s a link in it’s purest form.

    But what if we want to change things up a bit? Perhaps blue doesn’t work with your website’s design. Maybe you have an aversion to underlines. Whatever the reason, CSS lets us style links just we can any other element. All we need to do is target the <a> element in our stylesheet.

    Want to use a different font, change the color, remove the underline and make it all uppercase? Sure, why not?

    a { color: red; text-decoration: none; text-transform: uppercase;
    }

    See the Pen Link With Some Style by Geoff Graham (@geoffgraham) on CodePen.

    Now we’re cooking with gas! But why stop there? Let’s look at a few other ways we can style links to complete the experience.

    Style Each Link State

    Links have different states, meaning they adapt when we interact with them on a webpage. There are three additional states of a link that are worth considering anytime we change the default style of links:

    • Hover (:hover): When the mouse cursor is place on top of the link without a click
    • Visited (:visited): The appearance of a link that the user has clicked on the page before when the mouse cursor is not on top of it
    • Active (:active): When the link is in the process of being clicked. It might be super quick, but this is when the mouse button has been depressed and before the click is over.

    Here is the same link we have been looking at. First, try hovering your mouse on top of it without clicking and notice that it becomes underlined. Then, click on the link, but leave your mouse button clicked down for a little bit to see how the active style changes the color of the link to black. Finally, let up on the mouse button and the link should turn purple before it’s technically been visited.

    See the Pen Link With Styled States by Geoff Graham (@geoffgraham) on CodePen.

    Links seem like a simple concept, but boy do they have a lot going on—and CSS gives us some incredible power to customize the experience!

    Links as Buttons

    While there is some debate about it, we can use CSS to make a text link look like a button.

    Like other HTML elements, CSS can add background colors and padding to links that allow us to create the appearance of a button. Here’s our link using those techniques:

    a { background-color: red; color: white; padding: 1em 1.5em; text-decoration: none; text-transform: uppercase;
    }

    See the Pen Link as a Button by CSS-Tricks (@css-tricks) on CodePen.

    Great! Now, let’s use the state-altering powers we learned in the last section to make our faux-button more interactive. We’ll make the button dark gray on hover, black on active, and light gray on visit:

    a { background-color: red; color: white; padding: 1em 1.5em; text-decoration: none; text-transform: uppercase;
    } a:hover { background-color: #555;
    } a:active { background-color: black;
    } a:visited { background-color: #ccc;
    }

    See the Pen Link as a Button With Styled States by Geoff Graham (@geoffgraham) on CodePen.

    Styling a link as a button and taking advantage of the states allows us to make some pretty cool effects. For example, let’s create a button with some depth that appears to get pressed when it’s active and pop back up when the click is done.

    See the Pen Link as a 3D Button by Geoff Graham (@geoffgraham) on CodePen.

    Oh, and Cursors!

    We’ve gone into pretty great depth on style links, but there is one more component to them that we cannot ignore: the cursor.

    The cursor indicates the position of the mouse on the screen. We’re pretty used to the standard black arrow:

    The standard mouse cursor arrow

    We can change the arrow to a hand pointer on it’s hover (:hover) state so that it’s easier to see that the link indicates it is an interactive element:

    Using cursor:
    pointer;
    provides an interactive cue.
    a:hover { cursor: pointer;
    }

    See the Pen Link as a 3D Button With Pointer by Geoff Graham (@geoffgraham) on CodePen.

    Whew, that’s much nicer! Now, we have a pretty fancy link that looks like a button with proper interactive cues.

    Leveling Up

    We’ve covered quite a bit of ground here, but it merely scratches the surface of how we can control the style of links. If you’re ready to level up, then here are a few resources you can jump into from here:

    • Mailto Links – A good reference for linking up email addresses instead of webpages.
    • The Current State of Telephone Links – Did you know you can link a phone number? Well, here’s how.
    • Cursor – The CSS-Tricks reference guide for customizing the cursor.
    • When to Use the Button Element – If you’re wondering about the difference between a link button and a traditional form button, then this is a good overview with suggestions for which is better for specific contexts.
    • Button Maker – A free resource for generating the CSS for link buttons.

    CSS Basics: Styling Links Like a Boss is a post from CSS-Tricks

    CSS Basics: Using Multiple Backgrounds

    With CSS, you can control the background of elements. You can set a background-color to fill it with a solid color, a background-image to fill it with (you guessed it) an image, or even both:

    body { background-color: red; background-image: url(pattern.png);
    }

    Here’s an example where I’m using an SVG image file as the background, embedded right in the CSS as a data URL.

    See the Pen background color and image together by Chris Coyier (@chriscoyier) on CodePen.

    That’s just a single image there, repeated, but we can actually set multiple background images if we want. We do that by separating the values with commas.

    body { background-image: url(image-one.jpg), url(image-two.jpg);
    }

    If we leave it like that, image-one.jpg will repeat and entirely cover image-two.jpg. But we can control them individually as well, with other background properties.

    body { background-image: url(image-one.jpg), url(image-two.jpg); background-position: top right, /* this positions the first image */ bottom left; /* this positions the second image */ background-repeat: no-repeat; /* this applies to both images */
    }

    See how background-position also has comma-separated values? Those will apply individually to each image respectively. And then how background-repeat has only one value? We could have done two values in the same way, but by using just one value, it applies to both.

    Here’s an example using four separate images, one in each corner, offset by a smidge:

    See the Pen Example of multiple backgrounds by Chris Coyier (@chriscoyier) on CodePen.

    It’s too bad you can’t rotate or flip background images or else we could have used just one. We can rotate and flip entire elements (or psuedo elements) though, so in cases like that, we can get away with using a single image!

    See the Pen Flipping Image So You Can Use Just One by Chris Coyier (@chriscoyier) on CodePen.

    Just a few other things to be aware of here:

    1. The stacking order of multiple background is “first is on top.”
    2. Gradients are applied through background-image, so they can be used as part of all this. For example, you could set a transparent gradient over a raster image.

    See the Pen Tinted Image w/ Multiple Backgrounds by Chris Coyier (@chriscoyier) on CodePen.


    CSS Basics: Using Multiple Backgrounds is a post from CSS-Tricks

    CSS Basics: The Second “S” in CSS

    CSS is an abbreviation for Cascading Style Sheets.

    While most of the discussion about CSS on the web (or even here on CSS-Tricks) is centered around writing styles and how the cascade affects them, what we don’t talk a whole lot about is the sheet part of the language. So let’s give that lonely second “S” a little bit of the spotlight and understand what we mean when we say CSS is a style sheet.

    The Sheet Contains the Styles

    The cascade describes how styles interact with one another. The styles make up the actual code. Then there’s the sheet that contains that code. Like a sheet of paper that we write on, the “sheet” of CSS is the digital file where styles are coded.

    If we were to illustrate this, the relationship between the three sort of forms a cascade:

    The sheet holds the styles.

    There can be multiple sheets all continuing multiple styles all associated with one HTML document. The combination of those and the processes of figuring out what styles take precedence to style what elements is called the cascade (That first “C” in CSS).

    The Sheet is a Digital File

    The sheet is such a special thing that it’s been given its own file extension: .css. You have the power to create these files on your own. Creating a CSS file can be done in any text editor. They are literally text files. Not “rich text” documents or Word documents, but plain ol’ text.

    If you’re on Mac, then you can fire up TextEdit to start writing CSS. Just make sure it’s in “Plain Text” mode.

    If you’re on Windows, the default Notepad app is the equivalent. Heck, you can type styles in just about any plain text editor to write CSS, even if that’s not what it says it was designed to do.

    Whatever tool you use, the key is to save your document as a .css file. This can usually be done by simply add that to your file name when saving. Here’s how that looks in TextEdit:

    Seriously, the choice of which text editor to use for writing CSS is totally up to you. There are many, many to choose from, but here are a few popular ones:

    • Sublime Text
    • Atom
    • VIM
    • PhpStorm
    • Coda
    • Dreamweaver

    You might reach for one of those because they’ll do handy things for you like syntax highlight the code (colorize different parts to help it be easier to understand what is what).

    Hey look I made some files completely from scratch with my text editor:

    Those files are 100% valid in any web browser, new or old. We’ve quite literally just made a website.

    The Sheet is Linked Up to the HTML

    We do need to connect the HTML and CSS though. As in make sure the styles we wrote in our sheet get loaded onto the web page.

    A webpage without CSS is pretty barebones:

    See the Pen Style-less Webpage by Geoff Graham (@geoffgraham) on CodePen.

    Once we link up the CSS file, voila!

    See the Pen Webpage With Styles by Geoff Graham (@geoffgraham) on CodePen.

    How did that happen? if you look at the top of any webpage, there’s going to be a <head> tag that contains information about the HTML document:

    <!DOCTYPE html>
    <html> <head> <!-- a bunch of other stuff --> </head> <body> <!-- the page content --> </body> </html>

    Even though the code inside the <head> might look odd, there is typically one line (or more, if we’re using multiple stylesheets) that references the sheet. It looks something like this:

    <head> <link rel="stylesheet" type="text/css" href="styles.css" />
    </head>

    This line tells the web browser as it reads this HTML file:

    1. I’d like to link up a style sheet
    2. Here’s where it is located

    You can name the sheet whatever you want:

    • styles.css
    • global.css
    • seriously-whatever-you-want.css

    The important thing is to give the correct location of the CSS file, whether that’s on your web server, a The Sheet is Not Required for HTML
    You saw the example of a barebones web page above. No web page is required to use a stylesheet.
    Also, we can technically write CSS directly in the HTML using the HTML style attribute. This is called inline styling and it goes a little something like this if you imagine you’re looking at the code of an HTML file:
    <h1 style=”font-size: 24px; line-height: 36px; color: #333333″>A Headline</h1>
    <p style=”font-size: 16px; line-height: 24px; color: #000000;”>Some paragraph content.</p>
    <!– and so on –>
    While that’s possible, there are three serious strikes against writing styles this way: If you decide to use a stylesheet later, it is extremely difficult to override inline styles with the styles in the HTML. Inline styles take priority over styles in a sheet.
    Maintaining all of those styles is tough if you need to make a “quick” change and it makes the HTML hard to read.
    There’s something weird about saying we’re writing CSS inline when there really is no cascade or sheet. All we’re really writing are styles. There is a second way to write CSS in the HTML and that’s directly in the <head> in a <style> block:
    <head> <style> h1 { color: #333; font-size: 24px; line-height: 36px; } p { color: #000; font-size: 16px; line-height: 24px; } </style>
    </head>
    That does indeed make the HTML easier to read, already making it better than inline styling. Still, it’s hard to manage all styles this way because it has to be managed on each and every webpage of a site, meaning one “quick” change might have to be done several times, depending on how many pages we’re dealing with.
    An external sheet that can be called once in the <head> is usually your best bet.
    The Sheet is Important
    I hope that you’re starting to see the importance of the sheet by this point. It’s a core part of writing CSS. Without it, styles would be difficult to manage, HTML would get cluttered, and the cascade would be nonexistent in at least one case.
    The sheet is the core component of CSS. Sure, it often appears to play second fiddle to the first “S” but perhaps that’s because we all have an quiet understanding of its importance.
    Leveling Up
    Now that you’re equipped with information about stylesheets, here are more resources you jump into to get a deeper understanding for how CSS behaves: Specifics on Specificity – The cascade is a confusing concept and this article breaks down the concept of specificity, which is a method for how to manage it.

  • The latest ways to deal with the cascade, inheritance and specificity – That’s a lot of words, but the this article provides pro tips on how to manage the cascade, including some ideas that may be possible in the future.
  • Override Inline Styles with CSS – This is an oldie, but goodie. While the technique is probably not best practice today, it’s a good illustration of how to override those inline styles we mentioned earlier.
  • When Using !important is The Right Choice – This article is a perfect call-and-response to the previous article about why that method may not be best practice.

  • CSS Basics: The Second “S” in CSS is a post from CSS-Tricks