I've been a web developer for a decade and a half. I've learned a lot along the way, and I'm comfortable with a lot of web-related technologies. But, I'm not very good at HTML and CSS, and I've decided it's time to do something about that.
I'm learning HTML and CSS.
When I ran my first marathon, I read a book called the Non-Runner's Marathon Trainer. One of the first few chapters explains that you should choose a marathon and tell everyone you know you're running it. This helps motivate you, because you feel as if you've made a promise. You're on the hook.
I'm putting myself on the hook.
Now that I'm on the hook, it's time to get started. I'm reading a book Jon Tan reviewed a few months ago called HTML and CSS Web Standards Solutions. I think it's going to be a perfect fit.
I know HTTP pretty well. Perhaps because HTTP is so familiar, I took a few notes while reading the first two chapters that I'd like to share with you in the hopes it will help you understand the Web a bit better.
From Chapter 2:
.htmlpart is important: it is a suffix, referred to as an extension, that tells the browser the document is a web page.
This isn't strictly true. URLs don't have file extensions, although it can appear so because of how easily you can map a URL to the filesystem, and how common it is to do so. The
Content-Type header indicates the content type. This is why a URL like http://shiflett.org/about doesn't appear to have a file extension, yet browsers still know to treat it as HTML.
As a matter of design, I think URLs should always be carefully considered. As I've written before in URL Vanity and URLs Can Be Beautiful, they play an important role in how your site is perceived. Unless a file extension is meaningful, such as when the resource is an image, get rid of it.
A file extension can seem important if the resource is something users might download. Luckily, it's not even necessary in this scenario; you can indicate your preferred filename with the
Content-Disposition header. For example, regardless of URL, you can suggest the filename
foo.bar as follows:
Content-Disposition: inline; filename=foo.bar
Also from Chapter 2:
The last thing we need to ensure our pages validate is a character encoding.
The suggested way to do this is with a
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
meta tag of the
http-equiv variety is a substitute for an HTTP header. Adding this tag is useful, and the W3C Validator even suggests it. Pages still validate without it, but you'll receive the following warning if you leave it out:
No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc.
In order to prevent problems, including some security vulnerabilities, be sure to always indicate the character encoding, and make sure you're consistent.
Now it's time to read Chapter 3. I hope you enjoyed this quick HTTP lesson.