Complete Intro to Web Development, v2 Effective Patterns for Coding CSS

[00:00:00]
>> Brian Holt: We've kind of been talking about CSS in a vacuum, we've been using style tags, which I told you not to use. You should not be using style tags in your normal projects, just on these tiny little examples. But somehow you need to connect your CSS and your HTML together.

[00:00:14] And I feel like a lot of times for people that falls apart, like, how do I get these two disparate ideas working together? So we talked about the head tag in HTML, right? Inside of your head tag, you can definitely put these style tags, it works just the way that we've been working with them before.

[00:00:30] But the better thing you can do is put a link tag, that's what this is right here, link. You can use link technically for other things, but 99.99% of the time, and I don't think actually I'm exaggerating, I'm pretty sure it's accurate number, it's gonna be for stylesheets.

[00:00:49] So you're gonna say rel="stylesheet', that's how you let it know this is a stylesheet, this should be interpreted as CSS. And then you give it an href of where it is. So if I put ./style.css, that means wherever my intex.html file is, it's in the same folder, right?

[00:01:08] So look in the same folder, and look for a file called styles.css. That's what the ./style.css means. We'll talk more about paths once we get to working with the Bash, but just believe me for now when I say ./, it means look in the same directory. Does that make sense to people?

[00:01:30] Okay, you can actually just say style.css, without the ./, but I put the ./ in there to kinda get you thinking about that cuz you're gonna see a lot more, and for other things that ./ is required. So if that's new to you, just get used to seeing ./ meaning in the same folder,

[00:01:48]
>> Brian Holt: Okay?
>> Brian Holt: Our my-brand, right here I have a my-brand. And I'll write in my style.css file, which is a totally different file from my index.html file, I'll write this CSS rule, and it will affect this h1 right here, right? So if we follow how those things get connected, they're are two separate files.

[00:02:10] But because of this HTML, this index file will be the first one loaded, the browser will say, you have a link tag, I'm gonna go out and download this other file and bring that in, and then I am going to apply for all CSS here. In fact, what really happens if you browser reaches this, it stops, it stops doing everything and it waits for that to download.

[00:02:32] So you wanna be careful because that will slow down your site because obviously it's waiting for that stylesheet to load.
>> Brian Holt: Okay, any questions about that?
>> Speaker 2: Yeah, what is the difference between link and href?
>> Brian Holt: Between link and href?
>> Speaker 2: Yeah.
>> Brian Holt: So this is a link tag, right, it's a specific kind of HTML tag.

[00:02:54] And this is the href attribute, right? So it's describing something about link and it's telling you where the stylesheet is located.
>> Brian Holt: Do you follow, does that make sense?
>> Speaker 2: Yeah.
>> Brian Holt: Okay, good question.
>> Brian Holt: Cool,
>> Brian Holt: When to actually use the cascade? So I spent this time kind of telling you and drilling into your head, don't use the cascade, except sometimes when you use the cascade.

[00:03:28] [LAUGH] Now, imagine I have a website with these nice looking buttons, right? I have a Default Button, a Warn Button, and a Success Button, and they're all on my web page. I don't really wanna actually rewrite the styles for this three separate times. It'd be really nice if I could just reuse most of the styles that are the same, right?

[00:03:49] Because it's the same border, it's the same font, it's the font-weight, it's the same font-size. And later, if I wanna go in, it's like, you know what, I don't really like that this is bold, I'm just gonna get rid of that particular part of it. It'd be nice if it changed all of them at once rather than having to change it three different times.

[00:04:08] As programmers in general, we're generally striving to not repeat ourselves. DRY, do not repeat yourself.
>> Brian Holt: So,
>> Brian Holt: This is a occasion where you wanna lightly, very, very lightly, use the cascade. So I have these three buttons. I have the ex, just stands for example cuz I was uncreative at the time, and btn is a very common abbreviation you'll see for button, when people put them in classes.

[00:04:46] So I have one here that's the Default Button, and then I have one that's a Warn Button, like, hey, you're about to do something that you're gonna regret or whatever. And then I have one here for Success, like you successfully have done something, right? So what I do here is I have the Default Button.

[00:05:01] I write all of the styles that I need for the Default Button, and then I will do just the bare minimum that has to change for the Warn Button and for the Success Button. So I change the color cuz this is black, I change the background color, and I change the border color, and nothing else.

[00:05:19] Everything else should go inside of the Default Button, right? So this is an occasion where you're technically using the cascade because these come lower on the page, right? So that's how it wins. Now, notice I'm not going crazy with these selectors, I'm not throwing a bunch of unnecessary stuff inside of the cascading tags, this is very, very minimalistic.

[00:05:41] The other thing that I will suggest that you do if you are using the cascade, make sure they all live in the same file next to each other so that you can read everything just by scrolling through one file. I will see a lot of times people will have them across multiple files.

[00:05:55] That's bad because whenever something breaks, you now have to look across multiple files. That's not a good thing.
>> Brian Holt: Questions about that, please.
>> Speaker 3: So is this an example where a comment saying, hey, it gets thee properties from this class would be useful?
>> Brian Holt: I like what you're thinking about, I think that's a good train of thought.

[00:06:19] I think the way I would do it is maybe here inside of ex-btn.warn I would put something like this, and it would say, inherits from ex-btn or something like that so people know it's like, hey, this is actually meant to always go with ex-btn.
>> Brian Holt: Yeah.
>> Speaker 3: Is that good practice?

[00:06:44] Is that how it would typically be done?
>> Brian Holt: I don't know if I'm gonna say typically. I don't know if there's necessarily any common practice around this. Every company that I've worked for, including Netflix, including LinkedIn, my fault, myself included as a party at fault, all the CSS has always been a hot mess.

[00:07:06] Just because over time, with like two dozen engineers working on the same thing, things just get out of control. Cuz people are going fast and they're iterating quickly, and that's just really common to happen. So anything that you can do to keep things clean and easy to digest and manage, really, really, really helps.

[00:07:25] So things like that would be helpful.
>> Brian Holt: Right now we're talking about writing raw CSS, and there's lots of companies that still write raw CSS. But there are higher level languages that you can write, like Sass and Less, and there's these other technologies that are very CSS-looking, that have additional features, that you can actually group all of these things together, and then it compiles out to CSS.

[00:07:52] And so a lot of times, you'll rely on tools like that to kind of help you to stay a little bit more honest
>> Brian Holt: It makes it hopefully a little bit more readable. Often the case is it makes it even less readable. So with great power comes great responsibility and everyone's like, no we'll just take the great power and shirk the responsibility so.

[00:08:13]
>> Brian Holt: Yeah. But I think this would be a useful pattern. If I walked into code base and I saw comments like that, I would be very pleased.
>> Brian Holt: Cuz it's like it's thoughtful.
>> Brian Holt: Cuz if I see this one here in a vacuum, just the ex-btn-warn, I don't know anything else about it right?

[00:08:33] Assuming that I can't see the ex-btn above it. So if I saw something right away says, this inherits from this, it's like, cool, I can immediately go look at that.
>> Brian Holt: Kind of closes that loop for me.
>> Brian Holt: Cool, other questions?
>> Brian Holt: I've kind of just been hinting at this quite a bit so far like I keep opening my devtools.

[00:09:03] But I want to formally introduce you to your devtools really quick. So I have a decent amount of familiarity with both Chrome's and Firefox's. They both have really different strengths and so I actually end up using both of them with some frequency. There's plenty of people, there's plenty that just use Chrome.

[00:09:25] But Firefox has some really good stuff too. They've really made some leaps and bounds. So the easiest way to open it, the easiest way to remember it, is just right-click on something and say, inspect element. This will not show up in Safari unless you turn on the developer tools, just so you know.

[00:09:44] So I say, Inspect Element, and notice that it takes me directly to that button that I right-clicked on, right? So if you want to just wonder what's going on with this element, I don't understand why the CSS is doing what it's doing. Just right click and inspect element.

[00:10:00] Takes me to here and notice that it tells me right here, it's getting the green color from this x button success, and it's also inheriting from this one. So, the top one will be the most specific one that it's inheriting from. The next one underneath that will be next most specific one, and notice that all these things here are crossed out.

[00:10:22] It means like hey it actually does, it's getting a background color of gray if that's what that color is. But it's not coming through because something above it is more specific. Now you can say that well, I wonder what happens if the background color wasn't set. And so you can click that and then it will show us like if this wasn't set, this is what it would look like.

[00:10:44] And you can kind of toggle that on and off to see what that looks like. It's pretty powerful. And I can even go as far to say, well, you know, I wonder if the color was orange. Okay, that's what it would look like or I wonder if the background color was crimson?

[00:11:07]
>> Brian Holt: And you can kind of just tool around with things and kind of like experiment and like rapidly iterate, I do this literally all the time, right? So when I'm writing CSS, I usually don't go straight to my editor, I go straight to my browser I kind of figure out what I want it to do, just by messing around with it like this, and then I just copy everything that worked, and paste it into my editor.

[00:11:29] And that's a really good way just to go fast.
>> Brian Holt: You can,
>> Brian Holt: Write additional rules, so I could say,
>> Brian Holt: What happens if this is on hover, oops, :hover. And I want the background color to be cyan whenever I hover over it.
>> Brian Holt: And then I have to unset these as well.

[00:12:10] So now whenever I hover over it it's cyan, right? So you can actually just like to write these things right directly in the dev tools. I can go as far as, now I can go to computed and I can go and see, this is 128 by 25 pixels with 4 padding on top and bottom and 15 padding on left and right.

[00:12:37] I can see that it has two pixel border top, two pixel border left, bottom, and right. And it has no margins. I was like, you know what? I wonder what this looks like if I just change this to be 25 pixels margin right there and just directly modify there as well.

[00:12:56]
>> Brian Holt: If you really wanna get into the weeds of why something is, you can come in here to the computed and you just scroll down and you can see everything that it has, including all the defaults. So I can see here,
>> Brian Holt: Text align some of the stuff down here.

[00:13:19] And you can see this is coming from forms.css, and this is coming from in line and a bunch of stuff like that. Yeah, that's layout. If you're using CSS grid, it has some useful stuff here. The box model properties are all right here. Animations, we're not doing any animations at all in this course, but It has really useful tools for like, visualizing how animations are happening and timelines for animations.

[00:13:47] Stuff that was really difficult to do before, that makes it a lot easier. You can see, it's just using the system font but you can see where those are coming from. What else?
>> Brian Holt: Yeah, admin class so that is really useful stuff all to be used from the Firefox, devtools but everything I showed you is like 80% the same in Chrome.

[00:14:13] So questions about that?
>> Brian Holt: The easy way to open and close these is Alt+Cmd+I. And I don't know what it is in Windows.
>> Speaker 4: Ctrl+Shift+I.
>> Brian Holt: I'm going Ctrl+Shift+I. Cool. I think that opens it in most browsers. And as you hit F12.
>> Speaker 5: What would you say the strengths are, comparing Firefox and Chrome devtools, like in what cases would you use one or the other?

[00:14:54]
>> Brian Holt: They've converged a lot. There was a lot of stuff that Chrome used to be able to do that Firefox couldn't, and Firefox has greatly caught up. The reason being is they totally reworked everything in Firefox. Now the Firefox devtools are built in React, which I think is pretty cool.

[00:15:09] And so they're able to iterate really quickly. The grid inspector for Firefox is really cool, if you're using CSS grid. If you're doing performance profiling of your JavaScript applications, you still can't really beat Chrome. Chrome is a lot better at doing profiling for that kind of stuff. Like if you're looking, well I mean, they both do memory leak kind of stuff.

[00:15:29] I guess this does have performance
>> Brian Holt: Yeah, I haven't actually too much tooled with that. This one has this new style editor thing that you can actually see everything that's coming in as CSS. So for all the code highlighting stuff here, you can see here I have this codemirror.css, it actually gives me the whole CSS document, and I can edit the CSS directly in my devtools here.

[00:15:58] And I can actually save, and it will save back, so I didn't even have to go open my editor. You can pretty much use your browser as your editor. Chrome does the same thing, too, so,
>> Brian Holt: Really, really cool stuff.
>> Brian Holt: Yeah, right there, thanks, CodeMirror. U is important for library stuff.

[00:16:23] The problem is if I ever had to override the library, which occasionally happens, I I have to do really crazy stuff if I wanna override important things that you're not proud of, things you have to take a shower afterwards.
>> Brian Holt: Honestly, they're both fantastic browsers, and just use the one that you're comfortable with.

[00:16:55]
>> Brian Holt: If I go back to the inspector,
>> Brian Holt: Yeah, you can also dock to the side. That's a useful thing to know.
>> Brian Holt: This one's useful as well. Let's see, let's dock to the side. So I can actually look at this website as if it was being loaded in, let's say, an iPhone 6s.

[00:17:20] So it makes it the correct height and width. It will actually send headers to the servers like, hey, I'm an iPhone. Send me the iPhone version. And so it kinda tricks the server into sending you the iPhone version. So you can actually debug what your phone stuff will look like directly in your browser, really, really useful to do.

[00:17:39] Something else you can do is you can say, hey, make this act like I'm on a cellphone or make it slow down my website to the point. If I say good 2G and try and refresh this page, it's gonna take a little bit to load the page. Hey, I actually did okay, go team.

[00:17:57] I did not write this website for performance. But you can see now, it's still loading, which is crazy.
>> Brian Holt: Make sure you always turn off throttling,
>> Brian Holt: Or else you're gonna have a bad time browsing the Internet.
>> Brian Holt: So you can use this color dropper to, hey, I wonder what shade of blue that is.

[00:18:22] So you can drag it around and see, that's this hex number or this hex number. Occasionally useful if you need to figure out a color.
>> Brian Holt: Yeah, good stuff.
>> Brian Holt: Please.
>> Speaker 3: So do you typically, when you're writing real websites, do you have rules? Say, okay, so if this is an iPhone, we're gonna do this, and then you have to write certain rules for the iPhone?

[00:18:49] Or is it all supposed to work in every single format, whether it's web or mobile or whatever else?
>> Brian Holt: I'll give you two answers that, as a general rule, you want to not target specific browsers. Because whenever you target specific browsers, things change. And then the things that you wrote to target the specific browser no longer work anymore.

[00:19:10] And that creates more work for me, and in general, I do not like doing work, [LAUGH] so I try and minimize that. The practical answer to that, so the ideological, the ideal answer to that would be, everything should work perfectly in every browser. The practical answer to that is you should really know who your audience is.

[00:19:36] You should figure out, looking at Google Analytics or something like that. This website is being browsed by 95% people that are using Windows 10 Edge. I'm gonna spend a whole lot more time debugging in Windows 10 Edge. Iif only 0.001% of them are using Samsung Internet, probably will never look at Samsung Internet.

[00:19:58] So know your user base, respond to your user base. Also recognize that you might have 95% in Windows Edge, because that's the only one that works. [LAUGH] And so, people are coming on Firefox, like this is ugly and then bounce out. So you have to kind of question your assumptions as well.

[00:20:15] But the example I always give is if you're making a website that you can hail helicopters in Brooklyn, you need to work on high end iPhones and that's about it. You're probably not gonna have too many people hailing it on Windows XP, for example. So, you kind of have to figure out where you are.

[00:20:37]
>> Brian Holt: But idealistically, you're gonna base things on the width of the page. That's generally the thing, you use these things called media queries. If this is less than 200 pixels wide, apply this style. This is less than 500 pixels wide, apply this style. If this is less than 800 pixels wide, then apply these styles and see how these break points, that when it gets this big, then it changes.

[00:21:00] When it gets this big, it changes again. You're just usually messing with widths, font sizes, paddings, margins, those sorts of things. Good question, yeah.
>> Speaker 5: So you said with font size, when you specify a pixel, it's not actually a pixel, but is it a pixel when you're using margins and borders?

[00:21:22]
>> Brian Holt: Once upon a time, it actually used to be a physical pixel. At some point in time, we realized that a pixel is not a pixel anymore. That what is a pixel for an iPhone is far tinier than what is a pixel for a CRT from the 80s or whatever, right?

[00:21:40] So at some point, they decided a pixel is this readable unit for this monitor. And so it's some fixed width, that it's ideally some amount of inches wide, I don't actually know what it is. But now it's like an inch, right? What is an inch? An inch is an inch, right?

[00:22:02] It's kinda the same thing, a pixel is just a pixel. There might be a better answer for that, but I don't actually know.