Being still relatively young, I never understood how so many people could be affected, deeply emotionally, by the death of a 'celebrity.' I've seen the footage of uncountable people lining up to visit Kennedy’s grave, for example, and while, logically, I could understand how someone so influential could touch so many people, what eluded me was how these people were so attached, so emotionally affected by the death of someone they've possibly never even seen in person.

Until today.

Twitter user benschwarz just announced an attractive new facelift for the W3C HTML5 spec for authors.

The new design uses em units which (on my screen) renders to a body width of about 640 pixels wide. Save for a naughty fieldset which strays outside of its yard, everything fits within this tight column, making for lines with reasonable word count.

This rant isn't about the appearance of the page, though. It’s about a little oversight in the way the page was coded. As I mentioned above, I found out about this page through a Tweet, and more often than not, I'm browsing Twitter on my iPhone. Here’s what that looked like:

Naturally I tried a little bit of pinch-to-zoom out action, but to no avail. Landscape mode wasn't much help, either. The problem here is that the author(s) of these pages decided to include the increasingly commonly used viewport meta tag.

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;">

If you're not familiar, the viewport meta tag was introduced by Apple to help developers improve the presentation of their pages when viewed on mobile devices (namely the iPhone, iPod Touch), and was later adopted by other browser vendors.

In this specific instance, the viewport tag is telling the browser to set the logical width of the page to the 'device-width' (being 320px in portrait, or 480px in landscape, on the iPhone), instructing that the initial zoom level is 1:1, and telling the browser to disallow zoom capability. It’s that last bit there that is troubling. Usually when developing a "web app" specific to mobile, the developer keeps in mind sizing constraints and sizes all the elements (text, buttons) on the page accordingly. In these cases, zooming in or out may distract from the app’s functionality, or not be necessary. For example, when developing a web app, an author would rarely (if ever) allow elements to render off-screen (scrolling elements aside).

In the case of developing for the desktop, however, where layouts are frequently larger than the screen size of most common mobile devices, the last thing you'd want to do is render a page full size, then tell the mobile user that they have to scroll through the entire document (namely left to right, in order to read every line) just to see it! In the case of this particular series of pages, the viewport meta tag is completely unnecessary (the iPhone, and I expect most other browsers, would have rendered the page 'properly' — as one would normally expect it to be rendered), and indeed actually causes more problems than it fixed.

Developing for mobile is receiving increasing amounts of attention as of late, and mobile use is growing exponentially. It’s an exciting new area for developers to explore, but we can't just take 'off the shelf' solutions, slap them on our pages, and expect everything to be just fine. When developing pages, please take care to use coding techniques appropriately, and be especially careful when using new[er] techniques that may affect users in adverse ways. If you want your content to be read, know that most users will abandon your page at the first annoying hurdle they encounter.

Google Chrome blocking Apple iTunes downloads?

"This frame was blocked because it contains some insecure content."

Okay, so it’s obviously just an iframe security certificate conflict or something, but I still find it terribly funny. Is Google trying to tell me something?

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.