Viewers: in countries Watching now:
Take a tour of a workflow that optimizes CSS code for easier navigation, organization, and readability. In this course, author Justin Seeley covers best practices for writing CSS in an easy-to-read format, commenting code, developing a table of contents, and adopting other methods that help produce "cleaner" code. The course also contains tips for speeding up development with some online tools and simplification techniques.
Now that we hopefully understand the importance of writing quote-unquote clean code, let's take a look at a couple of examples of clean code versus some not so clean code and why one is more readable and more useful that the other. So I've got two documents here: one is called Good CSS and one is called Bad CSS, and I'm going to take a look at both of these. We're going to explore exactly what makes one good versus the other. So I've got an opened bad.CSS here, and inside of this document you can see it's not well organized at all. I've got a header div that's declared up here, and it's written out all in one line.
Then I've got the body tag defined, and it goes line by line, but nothing is indented. Then I've got the h1, h2, h3, and p tags here all in separate lines, although they both share some common things like the color, which could have been put into a selector group. I mean, there's all different types of things that make this not readable. Not to mention the fact that it's not organized in any rhyme or reason. For instance, the body tag is here in the middle. It needs to be towards the top. There's no CSS reset present here which means that the browser is going to be adding on its own type of style. So I haven't overwritten that at all.
Then nothing is really organized in any way, shape, or form in this CSS document. This unfortunately is how a lot of people tend to write their code. When a lot of people sit down to write out their CSS, and this includes myself when I first started writing CSS, I would just come and just stream of consciousness write down whatever came to mind or whatever I had in my brain that I needed to do, and that's perfectly fine when you're first developing your CSS. That's perfectly okay. This is your starting point. That's okay. This should not be your end point, however.
What you need to do is take some time once you have all of your ideas down inside of this document and then reorganize it so that it looks and feels a little bit better than this, because if I came back into this a week or a month later to make some changes I will be searching for all of the values and all of the different things that I needed to take care of in here, and it would just be a big mess. Whereas if I go over here into the good.CSS document, you'll see here I have a very clean, very well organized, very well commented and documented bit of code here that I can go through and take a look at. So I've got--what website is this for-- okay, it's for the Roux Academy Blog.
This is their URL, here's the author, and copyright information. I've got a color guide here towards the top. So it let's me know when I see this color, it's that. When I see this it's that and so forth, and so on. So I can relate these to actual colors that I see throughout the CSS document. I've got a nice table of contents here that tells me oh, okay, so the first part that I'm going to run into is the CSS reset which affects all the files then number 1 is going to be header, number 2 is going to be body, 3 sidebar, 4 footer, 5 comments. So if I need to find any of these like if I need to find the header styles, I can just scroll down, and I can find where that starts. So header style starts right there.
Directly underneath that would be where the header styles would be or if need to change something in the CSS reset, I scroll back up, okay, there's the reset and so there we go. So having code that is organized, well commented, and put into a structure of sorts is very useful, because I could find one of these section headings, look for the number that I'm looking for, and then automatically find the section that I need and then hopefully target the elements that I'm looking to target a little bit faster and a little bit easier by doing so. Hopefully, these two documents give you a better understanding of what makes good CSS versus bad CSS, and I'm not necessarily talking about how the code itself is written.
I'm just talking about from an organizational perspective. What makes it readable versus not readable? So when I open up a document like this, very easy to read, very fast for me to find what I'm looking for. Whereas if I open up a document like this, I'm going to spend a lot of time using the find and replace command as oppose to just being able to scroll and fix whatever I came to fix.
There are currently no FAQs about CSS: Visual Optimization.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.