Why Few People Ever Master CSS

CSS is a simple technology, right? Not exactly. Many web developers know it well enough to make regular style updates to a website. But to master CSS takes more than practice, it takes an effective strategy.

sunglasses on a rocky beach

Recently I came across this article on Stack Overflow about how to make a div the same height as the browser window. The top answer is mercifully simple – apply the 100vh rule:

See the Pen KRYaVX by Float Nine (@floatnine) on CodePen.

vh stands for viewport height, the height of the drawable region of a browser window. This is a cool trick, but it’s not always what we want to achieve. For example, if the div you are applying 100vh to is inside another div with a defined height, it can throw off the layout. Here’s an example, where the parent div has a green border:

See the Pen JvVEXz by Float Nine (@floatnine) on CodePen.

The overflow of the #inner div makes it appear that something unintended has happened in the layout. So 100vh might not always be ideal. You could use 100% height instead, which will make the div as tall as possible, without exceeding the height of its parent element:

See the Pen LmvxxK by Float Nine (@floatnine) on CodePen.

If you want the parent element to be 100% the height of the viewport, give the parent element and all its parents elements (including the body and html tags) 100% height, too:

See the Pen VxNPbw by Float Nine (@floatnine) on CodePen.

You might be thinking at this point, “That’s starting to get too complicated. What if I can’t make all of a div’s parent elements 100% height? It’s much easier to use the 100vh trick.” I would agree with you. This is a common problem people run into when they try to master CSS. Any given rule seems to only work some of the time. It seems like you’re left with one of two choices:

  1. Memorize one or two techniques for each scenario and limit your HTML markup to always accommodate those techniques.
  2. Don’t worry about the markup, whenever you come across a problem with styling, just noodle around in CSS until you get your desired effect.

Neither one of these strategies is ideal, for obvious reasons. The best answer is that you need to learn multiple ways to achieve any given effect, and know when and why to apply each one. This principle can be applied to thousands of layout issues: centering elements relative to each other, creating “sticky” footers and columns of equal heights, working with background images, and a myriad of everyday issues like lining elements up next to each other and repositioning elements with relative and absolute positioning.

The good news is, you don’t need to be able to list the different techniques off the top of your head, to begin to master CSS. Just try to approach CSS problems with this philosophy in mind. You will be way ahead of the game.

Coding Confidence – aka Ignoring the Hype

The following is a work of fiction, but it’s affects nearly all of us at some point. Hopefully, if you relate to it, you can take the message to heart and increase your coding confidence.

Anxiety Mounts

You’re sitting at your desk, and your team lead comes into the room and makes an announcement:

“Listen up everyone, I just had a team meeting with devops, and we’re switching to Laravel for the next project.”

You hold back a groan. Not only have you never worked with Laravel before, you’re not even that familiar with PHP. As feelings of anxiety start swirling in your chest, another developer chimes in:

“I take it we’re using 5.4.22 then?”

The team lead’s face lights up a little. “Yeah, unless they release a newer version between now and then.”

“Laravel’s a good one,” the developer says, not missing a beat. He picks a foam dart off the table and pitches it through a basketball hoop against the wall. “I’ve been keeping an eye on Laravel since they added model binding in 5.4.”

“Oh yeah, 5.4 was a huge jump forward,” the team lead agrees.

“Blade templating’s a nice touch, too,” the developer says.

“And route prefixing,” the team lead adds.

You start to imagine that you have never learned anything useful about programming in your life, let alone anything you could have an intelligent conversation about.

Coding Confidence Tanks

The team lead’s eyes brush over you and the other developers, and you look away, hoping he doesn’t realize you have no idea what they are talking about. Model binding? Blade templating? Route prefixing? As your anxiety builds, your coding confidence plummets. You start to imagine that you have never learned anything useful about programming in your life, let alone anything you could have an intelligent conversation about. Were you were supposed to be keeping abreast of MVC release logs? Hell, maybe you really aren’t very good at what you do. You can’t help but entertain the notion, as you watch your two teammates return to their seats, that maybe you just aren’t cut out for programming.

Diagnosis & Solution

This is called impostor syndrome, and a lot of programmers suffer from it. Maybe you don’t have a formal degree in computer science, and feel like you just haven’t been trained to think about things from the right perspective. Or maybe you do have a degree, but you have coworkers who skipped college and started programming for large companies right away. Since programming is one of those professions that a lot of hiring managers don’t know how to test for, it would be easy for an impostor to slip through the cracks, right? This is exactly how good programmers lose coding confidence.

These terms that your coworkers used: model binding, blade templating, and route prefixing, they are all pretty simple concepts.

Okay, so what I recommend here is to take a deep breath and let’s try to see the big picture. Part of what is fueling your insecurities can actually bring you some relief, and here’s why: jargon in the programming world is completely out of control. Marketing teams hype up simple concepts in an effort to catch peoples’ attention. These terms that your coworkers used: model binding, blade templating, and route prefixing, they are all pretty simple concepts. Let’s take a look at them, one at a time.

Breaking it Down

Model binding is probably the most complex of the bunch, and all it means is that, when a user enters a URL into your web app, like “profile/user/22”, Laravel automatically looks up the record in the User table with an ID of 22 and gives you, the developer, access to the record. So if you wanted to show the user their email address and phone number when they entered “profile/user/22”, you wouldn’t have to write the code to query the User table for that record. That’s all model binding is.

Blade templating is just a kind of templating system. Blade is one of the most intuitive, straightforward templating systems I have ever worked with. It’s a snap.

Route prefixing is a Laravel feature that lets you forgo beginning of a URL when writing routes. Say you need three routes, “admin/profile/{id}”, “admin/dashboard/main”, and “admin/users/all”. First tell Laravel that the next group of routes will start with the prefix “admin”. Then write them as: “profile/{id}”, “dashboard/main”, and “users/all.” Laravel puts “admin” on the front of each one for you. It’s really simple, isn’t it? Not intimidating at all.

It’s really easy to get intimidated by jargon, but in hindsight, the conversation your coworkers had was pretty basic.

Coding Confidence

Feel better? It’s really easy to get intimidated by jargon, but in hindsight, the conversation your coworkers had was pretty basic. They might as well have been talking about baseball:

“I’m a Yankees fan.”

“Yeah, but what about the Red Sox?”

“Don’t forget the Blue Jays.”

99% of the time, tech talk in offices is much simpler (and boring) than it sounds. Maybe your coworker was just trying to impress the team lead with a barrage of intelligent sounding jargon. Maybe model binding and blade templating really do excite him. Either way, bring the focus back to yourself and don’t worry about him. You’ve got this, and you can build your coding condfidence. You know much more than you think you do.

Five Things (Almost) That You Don’t Need jQuery For

You might be in the habit of using jQuery to perform quick and relatively simple tasks on the front-end of the stack. But especially nowadays, you don’t need jQuery for many everyday web dev tasks. Vanilla Javascript will do the job fine, and with less overhead.

The Problem with Using JQuery

There are a few things you need to do to set up jQuery on a webpage. First, add a script reference to jQuery in the page head. Then make sure that script src points to a CDN or a copy of the jQuery library living on your company’s server. Finally, write the script and test to make sure jQuery has loaded.

Easy, right? But what if the CDN goes down? What if the company server coughs up the script, or, more likely, it clashes with another copy of jQuery somewhere? One of the most stressful parts of web development is unforeseen deployment issues, and you just want to code, right?

Nowadays you don’t need jQuery for a lot of tasks. Javascript does these jobs just fine.

The thing is, nowadays you don’t need jQuery for a lot of tasks. Javascript does these jobs just fine, and with less overhead. Here are five things you can do in Javascript alone, without the help of jQuery:

Selecting an Element

Selecting an element is one of the most fundamental things we use jQuery for. It’s pretty simple. In jQuery:

That dollar sign is called syntatic sugar, and it’s supposed to make reading a language easier. But you really don’t need jQuery to do this. You can just as easily write this expression in Javascript:

Changing CSS Styles

You can directly change the CSS styles of elements with jQuery, right? It’s something you might do like so:

See the Pen aGayEx by Float Nine (@floatnine) on CodePen.

But why use an external library when you can do it with Javascript:

See the Pen vjzJoy by Float Nine (@floatnine) on CodePen.

Adding a Class

jQuery makes this easy! Like this:

Why would you do it any other way? Because you don’t need jQuery to do it. It’s just as easy in Javascript:

 Adding a Click Event

This is one thing that jQuery certainly does better than Javascript, right?

See the Pen pVOWwB by Float Nine (@floatnine) on CodePen.

Again, NO. Why not just do this with Javascript:

See the Pen odPGyw by Float Nine (@floatnine) on CodePen.

Wrapping Your Script in a $(document).ready Function

Okay, surely this is a job for jQuery. The $(document).ready wrapper ensures your code is scoped and gets executed after the page has loaded. For example:

See the Pen ELebaW by Float Nine (@floatnine) on CodePen.

This codepen doesn’t really do anything, but if there were code inside the $(document).ready function, you could be assured that it would execute after all of your HTML elements loaded. That’s a handy feature, as it takes time for your browser to render each element on the page, and if your script is manipulating elements, you want to make sure they’re there. Well, you don’t need jQuery for this either. Not exactly, that is…

Here is one way to try to mimic $(document).ready with simple Javascript:

See the Pen VxGrex by Float Nine (@floatnine) on CodePen.

This will do the trick in most browsers, but not IE8. Increasingly, that’s not a problem anymore, as a lot of companies are phasing out support for anything before IE9, or IE10. If you must support IE8, you can do something like this:

See the Pen aGaVmy by Float Nine (@floatnine) on CodePen.

By putting your script after all HTML elements (other than the closing body and html tag) you are safeguarding against the browser not having loaded the elements the script uses. The generic function wrapper makes sure the script fires without prompt. This isn’t perfect, either, as there are times when a browser renders some objects or elements after the initial page has loaded. But it’s a pretty good alternative, and will work fine most of the time.

But this last example brings up a greater point. We’ve gotten into territory where the solution to the problem has gotten a little complicated. Do we use jQuery here, or do we try to achieve the same with vanilla Javascript? Those kinds of decisions are ultimately up to you, and you should get in the habit of knowing what you do and you don’t need jQuery for. What is important is not that you make flawless decisions every time, but that you know the benefits and drawbacks of the different routes, and stand behind your decisions accordingly.