The Typical Stuff
The majority of you guys are already familiar with the three components:
- HTML is the language used to markup the data that you want to display in the browser.
- CSS provides the facilities for making the data look a certain way.
Am I right? None of these are wrong, but I’d consider this to be a high-level description of what each language does. Though this isn’t necessarily wrong, it leaves something to be desired. I’d even go as far to as to say that getting a clear mental model of how these three things work can make you a better developer.
- HTML is for describing data
- CSS is for presenting data
Make sense? Each language serves a single purpose in the context of a page. When you begin to think this way, it provides a way for you to make decisions on where certain things should go.
Decisions on Data Description and Display
For example, say you’re trying to determine if text should fill the width of the container (or the page) or should only take up the space necessary to display the width of the sentence. You’re making a decision on the description of the data so you’d use HTML.
Specifically, if you want to fill the parent element, use a paragraph – it’s block level and fills the width of its container; otherwise, use a span element – it displays inline and fills only the width of the sentence. The thing is, CSS supports display:block; and display:inline; such that is can be achieved that way, but I argue that nine times out of 10 you don’t need to use CSS.
Ultimately, this leads to writing cleaner HTML and cleaner CSS. You’re allowing each language to serve the purpsoe for which it is intended. This makes it easy to determine where a certain line of code should go based on what it will be doing.
In the context of development, you can think of it like this:
Just Because You Can, Doesn’t Mean You Should
You’re stuck trying to find where the line of code lives that is causing the problem and the debugger (be it Firebug or Dev Tools) is having a difficult time calculating the right line number. As such, time is lost trying to figure out where the problem originated and it could have been saved should a few decisions had been made and steps had been taken at the front end of the project.
Understanding how these three components actually fit together in creating a page or a site goes in a long way in furthering your development chops: you can make better decisions on what language should handle what function, you can write cleaner code, and you can organize your projects in such a way that they won’t be such a mess months into development.
Of course, it’s much easier to say all of this than to do it. At least aim for it.