Check out a free preview of the full Intermediate HTML & CSS course

The "Introduction" Lesson is part of the full, Intermediate HTML & CSS course featured in this preview video. Here's what you'd learn in this lesson:

Jen Kramer begins the course by sharing a few misconceptions about HTML and CSS and outlining the benefits of writing clean, semantic code. The course will utilize CodePen for most of the exercises. Links to all examples and resources can be found on the course website.


Transcript from the "Introduction" Lesson

>> Welcome everyone, my name is Jen Kramer. Today, we are going to be talking about HTML semantics and CSS specificity and selectors. So we have a lot of topics to cover today, we're gonna talk all about the various types of semantic HTML that can hopefully introduce you to a few elements you might not have heard before.

We're going to talk a lot about CSS selectors and forming them, and what they mean. We're even going to get to some of the new ones like where n is and has, and some other various ones along the way, we're gonna talk about inheritance, specificity, and the cascade.

So these are the three most misunderstood concepts in CSS. And as such, this is really a course about mechanics of CSS as opposed to how to make things pretty, and so more on that in just a moment. So as you follow along here, the course website is at

Everything that I talked about today will be there including a copy of the slides, all of the code pins that we're going to work with, and links to GitHub. We'll actually only use GitHub and VS Code towards the end of the course, where we get to the cascade and we have to talk about different sources for stylesheets.

Other than that, we're just pretty much going to work in CodePen today. So as I said, this is a course on CSS mechanics. And I have a number of other courses here in the front-end masters library if you want to work more on making it pretty. So if you wanna work on that, making it pretty stuff, the getting started with CSS course sounds pretty simple, it is a project-based course where we start with an Adobe XD, picture of how the site should look.

We break it down into smaller pieces, and we put together the whole webpage as a portfolio site. We're not really going to focus so much on layouts or responsive design, they come up peripherally, but it's not a focus of this course, if you want to learn more about that, I have a course called CSS Grid and Flexbox for responsive layouts version two.

If you watch my initial version of it, it was from like five years ago, the new version is completely updated with all kinds of new material, and you will learn new things in that one. And then, finally, advanced techniques in web dev specifically related to HTML and CSS, I have a course on that as well, the advanced CSS layouts course.

And, of course, that is from 2019, so it's not going to have the very latest CSS selectors in it, but it does cover things like CSS variables and calkin, doing all kinds of crazy math to create different kinds of layouts for webpages, okay? Hopefully, that gives everybody a pretty good overview of where else you can go if there are other things you wanna learn about CSS.

So let's start with what I see on Twitter and probably what you see on Twitter too, which is that <div> is totally awesome and we don't need anything else. It just does everything we need it to do, maybe the only other element that we need is a span element.

And there is a place for absolutely everything on the web, you can find excuses to do absolutely anything with the right kind of website. Even though, that blinking spinning stuff does a really great thing on a hypnotist's website, so yes, there may be plenty of use for divs and spans, but there are better ways of doing things.

And we should be making those choices because HTML and CSS are two-thirds of the front-end, when we ignore them in favor of just JavaScript, you're ignoring two-thirds of the tools that you have to work with when working on the front-end. Other things that I hear online and Twitter are that pick div and span are good enough to give me everything that I want, and HTML styling sucks.

I agree with you, we'll talk about how we can get around that today. HTML is a relic of the 90s and we should redesign the web to get rid of it, good luck with that, 30 years after launch. HTML and CSS should be in JavaScript, I'll show you why they shouldn't.

And also, code should be efficient and performant, Mine is. A lot of people like to hinge on the topic of performance as to why their JavaScript is superior, and that HTML and CSS are somehow dragging down the webpage, but they are probably not the source of your multi-megabyte files and all of the things that have to execute to make your webpage work.

I also hear things like CSS is stupid, it's unpredictable, I never know what I'm going to get. I hope that by the end of today that will no longer be an issue for you, it is very predictable, you can indeed predict what you're going to get. Specificity and the cascade should die.

They are one of the most wonderful parts of CSS once you understand how they work and how to leverage them, it's amazing the tricks that you can do with CSS. And long live classes, the only part of CSS that makes sense, yes, classes are very useful on occasion.

But I'm going to show you that when you expand your repertoire in terms of CSS selectors that are based on HTML semantics, you actually expand your depth of what you can do on the front-end. You stick to just classes and divs and spans, it's like having an old whole orchestra, but we're just gonna focus on the violin section.

Let's focus on the whole range and depth of what we can do. And then, finally, CSS selectors are deficient or performant like my classes, this has also been debunked, I have some references for you on this, you can go do some more reading. If your page is not performing well, a good place to sort of resize your images and all of the stuff that's in your JavaScript files.

Probably, those are going to be the things that are causing your page to slow down long before your HTML and CSS. So as a result, because people put so much emphasis on JavaScript, so little emphasis on HTML and CSS, we wind up with examples like this, this is a CodePen that codes a link.

And look how much code we had to write in order to code a link because we did not know the a element in HTML. And we have made it even accessible here with our roll designation and so forth. I'm not saying this is good code but this is why this happens, because people do not understand HTML and do not know what's available to them.

A good analogy to this is if we think about the construction industry in a very high level, we start with architecture and planning. They go in and play in a building, they pass it over to the construction people via blueprints. The blueprints describe what is going to be built, the construction people actually build it.

If you take a look, the architecture and planning and the blueprints are on one side of this equation, the blueprints are the product of what they do when they plan. And the construction people that is where they start, so they overlap, they're in the middle of blueprints. The same thing is true here when we think about the continuum of web development, we start with UX and UI and writing content, then we go into HTML, CSS, and JavaScript, and so on and so forth.

We have the same kind of overlaps happening. We tend to think of UX UI and content all together as a unit. So those people are producing this content, along with their Figma prototypes and whatever else, they're gonna pass that on over to the development team that are going to put these things together.

The overlapping part in the middle is the content of the webpage. Content is the moment that we transition from planning a website into building that website. And so we as developers, have a really bad habit of not reading the content. It is whatever it is, we don't care because we are so busy writing the code, and we are all guilty of this including me.

I would actually start to argue at this point in time that content may be better delivered if it's actually marked up by the UX UI team first, and then pass to the development team. And the reason why is we wind up getting more semantics into it. And, of course, the development team could add any additional dudes or classes that are needed in order to completely lay out the page and so forth.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now