Yesterday, life dealt a significant blow to our little family when we discovered that our chinchilla, Zippy, had died. In age, he was the middle of the three roommates. Dusty, the oldest, is the calm and intelligent type; the youngest, Noodle, can be quite crazy at times. Zippy occupied the personality space in between.

The three made the perfect trio of rodent companions. Even if they all looked identical, you could always tell them apart by their mannerisms. Curious, excited, and sometimes seemingly narcoleptic, Zippy would come to meet you without fail when you entered his room, and never passed up the opportunity to play.

Our strange family has shared many fond memories with you: lounging in bed, chewing on things we shouldn't have, chasing each other around the room, and destroying old apartments. Things simply won't be the same without you around, especially for your fellow roommates. We know they are going to need some time to adjust to life without you.

We hope you led a fulfilling life, as much, or more than you enriched ours. We already miss you, Zippy. We will continue to remember you until our own days are depleted.

When performing URL rewrites with .htaccess files, if your resources are available from both an unsecured (http://) and a secured (https://) connection, your first instinct might be to write a rule for each. For example, this snippet will remove the leading "www." from the domain name over both HTTP and HTTPS:

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.(.+) [NC]
RewriteRule ^(.+)$ http://%1/$1 [R=301]

RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^www\.(.+) [NC]
RewriteRule ^(.+)$ https://%1/$1 [R=301]

Here, each group of three lines is doing exactly the same thing (removing the 'www.' prefix), but the first group is only effective when serving pages over HTTP, and the second only over HTTPS. Clearly, if you have a lot of rewrites to perform in this fashion (external redirects, for example) then you're going to end up with a lot of otherwise redundant code.

Thanks to htaccess' ability to set environment variables, we can make this quite a bit cleaner. The following example first checks whether the connection is secure or not, sets a variable, then, in a single RewriteRule, uses this variable to do the original rewrite once.

RewriteCond %{HTTPS} !=on
RewriteRule ^(.+)$ – [env=prot:http]
RewriteCond %{HTTPS} =on
RewriteRule ^(.+)$ – [env=prot:https]

RewriteCond %{HTTP_HOST} ^www\.(.+) [NC]
RewriteRule ^(.+)$ {ENV:prot}://%1/$1 [R=301]

The observant will note that this is still six lines of code, however, like I mentioned earlier, if you have a lot of external redirects, you don't need to test for the protocol each and every RewriteRule. Simply reference the variable, {ENV:prot}, instead of explicitly typing "http" or "https".

Finally, for the savvy webmaster, here is an even more compact (although also a bit more confusing) way to do the same:

RewriteCond %{SERVER_PORT}s ^(443(s)|[0-9]+s)$
RewriteRule ^(.+)$ – [env=s:%2]

RewriteCond %{HTTP_HOST} ^www\.(.+) [NC]
RewriteRule ^(.+)$ http{ENV:s}://%1/$1 [R=301]

If you can follow, what’s happening here is that the first line is testing %{SERVER_PORT} to determine if it contains the string "443", and if so, setting the {ENV:s} variable to "s", and leaving it blank otherwise. This variable then gets appended to all instances of "http" effectively creating an automatic switch between secure and unsecured URLs.

Thanks to the posters in this thread at WebmasterWorld, for helping me clean up my code.

Every time Sarah Palin hits the news, there’s always another silly sound bite to go along with her latest conquest. This is sort of expected, but seriously, does everything that comes out of her mouth need to relate to "up here in Alaska"?

I can't believe anyone would entrust an entire country’s decisions to someone who’s complete scope of knowledge is "up here in Alaska."

Last time I checked, the other 99.8% of us don't give much of a shit what happens in Canada.

This post, and the related CSS code to target the iPhone 4’s browser, came through my Twitter stream multiple times today.

Thomas Maier writes about targeting the Mobile Safari browser with CSS media queries on his blog.

I think the things Apple are doing, and the advances they are making in the mobile phone and hand-held Internet device markets are amazing. I think it’s great that consumers (with the help of device makers) are redefining where, when, and especially how they interact with devices and data. I think the iPhone is cool. [I don't own one (I do have an iPod touch for testing), but that new display is incredibly tempting...]

So here we have this awesome new device which allows us to access all the same information we previously only could from a desktop (or laptop) computer. Apple even went out of their way to reinvent the way we interact with and browse that information so that we could have "the full Internet experience," and not some scaled-down mobile version.

See where I'm going with this?

It seems to me that we have so called 'standardistas' promoting information on how to design for a specific device, when the last — what has it been now? — 10 years have been all about getting away from browser sniffing, and moving toward adaptable, degradable design. In enough time, there won't be a 'mobile web,' it will just be the standard 'desktop web' that we're used to, and "these websites over here that only work on the iPhone." Thankfully, I'm not the only one, nor anywhere near the first person to realize this.

But a funny thing happened. Web developers started making versions of their Web sites optimized for the iPhone. Some had these versions available shortly after the iPhone launched. But since then many of the major sites like Google, Yahoo, FaceBook, Amazon, and so on, recognize when they are being browsed on an iPhone and will display an iPhone-specific view instead of the one you see on your Mac or PC. So Apple gave us the real Web, but the Web site developers took it away.

Gary Rosenzweig from 'iPhone’s Promise of "The Real Web"' posted on MacMost.
[Emphasis added by Jstn Ryan.]

The iPhone has become an obsession. If we don’t pay attention, we’ll have a mobile web that only works on the iPhone. And then we’ll have the real mobile web that wasn’t made by us and doesn’t give a shit about web standards and best practices.

[ ... ]

We’re doing exactly the same as ten years ago. We now say “iPhone” instead of “IE6,” but otherwise nothing’s changed.

Peter-Paul Koch from 'The iPhone obsession' on his site, QuirksMode.

What’s the solution?

First you have to identify whether or not you have a problem. If you're designing for a specific audience, namely iPhone 4 users only, then there is no problem. At the moment, though, that’s a pretty small target audience. Additionally, if you're only using this media query to "clean up" the appearance of your site when viewed on the iPhone 4, it’s probably safe to bet that you're doing things the 'right' way.

Why use this specific targeting at all, especially when there are much better alternatives? Another trend which has resurfaced recently is being called Responsive Design. It’s sort of a rethinking of the elastic and liquid layouts of a few years back.

"Figure 1" from the A List Apart article 'Switchy McLayout: An Adaptive Layout Technique,' demonstrating the changing design of a web page based on the browsers display-size characteristics.

Using the very same idea, CSS media queries can be used to target all devices of certain display capabilities, for example display width and or height, not just the fact that their "device pixel ratio" (whatever the hell that actually means) is a certain value.

These media queries, although commonly in use for serving styles to iPhone, also work for any other browser which will recognize them. Consider this a way of 'future-proofing' your website. If I come along one day with a device that has a screen size similar, if not the same, as the iPhone, your website will already be appropriately styled for my browsing experience, no modification necessary.

Consider the following:

@media screen and (max-device-width: 480px) { /* iPhone 2/3 */ }
@media screen and (max-device-width: 960px) { /* iPhone 4 */ }
@media screen and (max-device-width: 1280px) { /* etcetera… */ }

Media queries can be a very powerful tool, and certainly don't stop at the functionality shown above. By changing max-device-width to device-width further style customization is possible:

@media screen and (max-width: 320px) {
    /* iPhone 2/3 portrait AND ANY DEVICE WITH SIMILAR DISPLAY SPECS */
}
@media screen and (max-width: 960px) {
    /* iPhone 4 landscape AND ANY OTHER DEVICES WITH MATCHING SPECS */
}
@media screen and (max-width: 768px) and (orientation: portrait) {
    /* iPad portrait, etcetera… */
}

These media queries show some specific, powerful examples of targeting specific devices in specific modes, and can certainly be used for providing that functionality (if that’s your end-goal), but the point is that they shouldn't. They are powerful enough to give the designer the ability to build a site’s HTML once and style it endless ways provided some simple conditions of the device on which it is being viewed — not just the iPhone.

Go forth, and design wisely.

Buzzwords and 'buzz-concepts' travel through the web development community like the plague. After using the table element for page layout became faux pax everybody was so quick to jump on the bandwagon that there’s no arguing the point anymore — even in the off-case that it might just be appropriate. It’s such a widespread ’social injustice' that I've even had to explain to people that, "no, it really is okay to use a table here to mark up your tabular data," on more than one occasion.

Obviously, this isn't always a bad thing. It’s great to have people jump on board when something newer, better comes along. Recently, especially with all the hoopla over the new 'HTML5,' there’s been a lot of talk about semantics. Better semantics this, better semantics that. To me, most of the time it feels like we're just "being semantic" because it’s the cool new thing to do. You can go crazy with the label maker machine, but your basement is still going to be a fucking mess.

Garann Means seems to understand this flaw, and provides a great rant why using semantic markup is not always being semantic. Titled Defending Terrible Things, Garann explains the value of the b and i (italic) tags, versus their strong and em ’semantic' alternatives:

You know what strong and emphasis refer to? They refer to verbal inflections. You know what most peoples’ web browsers don’t do? Talk to them. You know what would annoy the shit out of me if I were using a screen reader to read a bibliography on the internet? Listening to a goofy-sounding computer voice try to emphasize every single word of Journal of the Study of Obscure and Mostly-in-Latin Canine Diseases Affecting Generally the Respiratory System but Also Sometimes the Lymph Nodes or something. I don’t know that this is still a problem, but the idea is ridiculous in and of itself. Italic does not always mean emphasis, nor does bold always mean MAKE THIS LOUD. Certain conventions of formatting require the use of bold or italics, but actual writing rarely does. If you need to place emphasis on something, you can do that with word choice. (Or anyway I hear it’s possible..)

Reproduced, because I couldn't have said it better myself.

So, what’s the moral of this story, then? Sometimes the cool, new, 'right way' to do things, isn't always the best way.