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:
.html part 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.
By all accounts, CodeWorks — a touring conference produced by the same people who publish php|architect Magazine — was a big success. Although I was exhausted from all the travel by the time we made it to NY, I'm really glad I took the time to participate.
Judging by the nice comments left on Twitter and Joind.in, everyone really liked my talks. Comments like "this was my favorite talk of the day" and "by far the most entertaining presentation" are especially uplifting. I put a lot of effort into my talks, and I really appreciate when people take the time to let me know when I've done a good job. Thank you so much!
It was great having the conference visit NY, especially since it was so near my apartment. On the first day, I took everyone to Siggy's for a late lunch. NY is known for great food, and Siggy's didn't disappoint:
Just had quite possibly the best veggie burger I've ever had. Ever. Thank you, Siggy's in NYC, you have made my day!
For lunch the next day, I took everyone to Grimaldi's for the best pizza in the universe, but the real highlight of the day was the beer dinner at Beer Table I had been planning.
Beer Table is a local bar in Park Slope operated by Justin and Tricia Philips. The beer selection is admittedly overpriced, but it's worth it for a great selection, an intimate atmosphere, and very good food. When I first spoke to Justin about hosting a beer dinner there, he noted that Beer Table has never been closed to the public, but there's a first time for everything.
Beer Table's first private event hosted some of the Web's friendliest designers, developers, copywriters, and illustrators:
For those who went, here is the menu, with links to each of the beers, using RateBeer where possible, BeerAdvocate otherwise:
- 1st Course
- Roasted beet salad paired with De Glazen Toren Saison D'Erpe Mere and Saint Somewhere Saison Athene
- 2nd Course
- Cannellini beans with pork, roasted tomatoes, and rosemary paired with Green Flash West Coast IPA and Burton Bridge Empire IPA
- 3rd Course
- Triple chocolate cookies paired with Hitachino Espresso Stout and Harvey's A. le Coq 2003
Sadly, there's not a very good review of the Harvey's stout online. It tastes different from year to year, so reviews vary. We had the 2003 as part of the beer dinner, and some of us later tried the 2001. I thought both were great, and I now have a few bottles of each at home. :-)
Half of the dinner was sponsored by the fine people at echolibre, a web development company based in Dublin that is the home of respected developers like David Coallier and Helgi Ãžormar ÃžorbjÃ¶rnsson. The other half was sponsored by a small group of people including Jon Tan, Andrei Zmievski, Alan Colville, and myself. We're not quite ready to talk about what we're up to, but we hope to be soon.
I'll add my slides to SlideShare in the next few days. When I do, I'll mention it on Twitter. Derick is currently editing a video he took of one of my talks. Unfortunately, it was one I gave very early in the morning, so I wasn't at my best, but it should be better than the slides alone.
This is the last of my conference appearances for the year. Now it's time to focus on my new company. More about that soon!