Windows Live Writer

So Microsoft recently released a new product called Windows Live Writer. It is a blog authoring tool. When I first heard about it, I assumed it would be a gimmicky piece of crap. However, I’ve played with it a little  and am thoroughly impressed. It is stable, intuitive, has spell check, does photo editing, and supports a wide variety of blogs. Most importantly, I no longer have to worry about WordPress eating my posts since this program saves drafts on my hard drive. =) Anyway, I recommend it to all you bloggers out there.

JavaScript Tip: Writing Dynamic Content

What is the difference between the write function and the innerHTML property? There is a huge difference. What happens to any JavaScript you import using these methods? It’s more complicated than you think.

The write() function (as in, document.write), writes text to the “document.” When an HTML page loads, what’s actually happening is a “document” is opened, some content is written to it, and then it is closed. This “document” is the main HTML window that you end up seeing. When a document is opened and written to, everything inside it is cleared out. Let me restate that: if you try to use document.write() after the HTML page has finished loading, you will destroy everything on the page, including the JavaScript tags, all the HTML, and pretty much everything you would see if you hit “view source.” Granted, if you did look at the source, you’d still see the original HTML that was loaded since the “view source” command shows you the originally loaded content, not the result of any JavaScript changes.

Continue reading JavaScript Tip: Writing Dynamic Content

Word Press SUCKS

Word Press has truncated or otherwise destroyed more than one of my posts on this blog. I am going to look into switching to a better engine. If you have suggestions, please post them. I wrote a very long entry yesterday about technical writing, and I came back today to realize it had killed half my posts during one of my edits. That’s insanely stupid.

Update: I have no plans on re-posting the truncated article. Over half of it was lost and I am too frustrated to convince myself to write the same thing a THIRD TIME. From here on out, I’m posting to this blog using a third party tool.

New Job and Punching Monkeys

I am starting at a new job in a week as Lead Developer. This has kept me busy because I have been slaving away trying to wrap up all my responsibilities at my current job.

On a separate and completely unrelated note, today I saw another variation to those once-popular punch a monkey type of ads. I always humor the programmers of the ad by repeatedly clicking on the ad without actually hitting the target. I’ll try my very darn best to shoot between the targets, miss the baby, and just plain suck at punching.

I’m looking at your ad. I’m clicking — perhaps not where you intended, but I’m clicking. I’m looking at your moving monkey baby thing. I’ve glossed over the ad text. I’m still clicking. And yet nothing happens to move me from viewing the ad to viewing the product. Eventually, I get tired of amusing myself and stop clicking, returning to whatever I was doing.

To me, this is a failure on the advertiser’s part. They’ve gotten my attention and my willingness to interact with the ad, but they’ve failed to communicate why I am interested in the product and convert my interest into action that results in a sale. It seems to me that a failure to use the product in the interactive ad, or the lack of mind-share presence of the product, is a fundamental failure by the advertisers to leverage the limited attention granted to them from a web surfer.

There’s a small chance I’ll want to visit your site, but if I don’t understand what it is I’m punching a monkey for, if punching the monkey becomes the focus of my interaction, I certainly won’t be *actually* interested in visiting your site.

And this is why I love clicking between the action areas on those interactive ads. There’s many solutions around what I do, but it amazes me that the ad hasn’t evolved in the years since it first became popular. Addressing this is how Google became king.

What Should I Write About Next?

I’m sorry about the lack of updates these past few days. I’ve been very, very busy wrapping up a few things in my personal life. I should have a significantly greater amount of time next week. I have a few ideas for some other coding related posts to address in the coming weeks. Whenever I get ideas, I write them down. Here is what I have so far:

Continue reading What Should I Write About Next?

A Brand New Way to Hide Your Email Address

If you haven’t already, I suggest you read the last article I wrote about separating your Javascript from your content. It will give you important background information needed to fully understand what I will be covering today.

Today, I’m going to show you how to embed your email address into any page of your site without fear that some bot will come along and steal it. This method is different from other ones because not only is it “backwards compatible” with older techniques, but it degrades gracefully and is straight forward to non-developers. This feature will work with all modern browsers, is human readable (no garbled text mixed in), and works when you click on it. Most importantly, it doesn’t require you to mark up your beautiful HTML.

Background

Some rogue email spammers use “bots” to automatically go through the internet and find email addresses. Once they find one, they add it to their spam list and you’re email becomes their newest indentured servant — forever. At first, people tried to trick the primitive bots by putting in spaces in their email address, such as in the following example:

some @ email . com

But bots learned to look for the @ symbol and then ignore spaces, so this quickly became obsolete.

So while some clever people think they are safe using address that look like:

some [at] email [dot] com

Or

some[nospam]@emailDOTcom

Or

someREMOVEME at email [period] com

The problem is that bots can be trained to look for these text patterns and get around them. After many programmers spent many hours mucking around with ASCII hashes and other futile measures, it became clear what the real problem was:

Bots can see and read anything a human can see and read!

The other problem is that adding in random words, brackets, and other symbols into your email address makes it very hard to read. This is very much unacceptable for people who are trying to run a business and can’t afford to have less savvy people send emails to salesREMOVE@[DONTSPAM]mybusiness.com.

I’m not going to tell you my idea is future proof. However, it’s been possible for many years now and I’ve never seen it. When and if this catches on, spammers may eventually start learning to get around it. But it won’t be easy. That’s because my method can vary wildly between implementations and can be used along side with any or all of the methods I showed above! More importantly, my method relies on the difference between bots and humans:

Humans click on stuff.

New Idea

The first and most important issue is that when a person clicks on your email link, it should let them email you. This is one of those things that has long since been lost as a readily available feature because so many people are afraid of getting spammed. Sure, maybe you can click on an email link, but you end up with something like the example below (click on it)

email me!

I’m sure you find that as annoying as I do. But what if we used Javascript to dynamically change what the href tag did? Well, the thinking-in-the-box idea would be to have this happen on the page load. That presents problems because some bots can run Javascript. The second idea is to change it if and only if someone clicks on the link. Now this makes sense. However, we reach the second problem: how do you store the email address somewhere on the page without the bot being able to see and read it?

How It Works

Primitive implementations used really ugly Javascript that would look something like this:

var myEmail = ‘so’ + ‘me’ + ‘@’ + ’email’;
myEmail += ‘.com’;

And then later on:

<a href=”#” onclick=”return ‘mailto:’ + myEmail”>email me</a>!

You can already see that this is violating the rule of mixing content with code. What happens if your email address changes? Do you really think your designer understands that ugly jumble of a mess? At the very end of the last article, I mentioned the possibility of parsing attributes and putting things together. Using the knowledge you gleamed from there, study the following and listen closely as you hear a lightbulb turn on. The objective is to have an email link to “some@email.com”:

<a href=”#email.com” class=”email-link” id=”some”>email me</a>!

This could have also looked like any of the following:

<a href=”@email.com” class=”email-link” id=”some”>email me</a>!
<a href=”#” class=”email-link” id=”email.com”>some</a>!
<a href=”#” class=”email-link” id=”some”>email.com</a>!
<a href=”#some@” class=”email-link” id=”email.com”>email me</a>!
<a href=”some” class=”email-link” id=”email/com”>email me</a>!

As you can see, there are many, many possibilities. And it is standards compliant and relatively straight forward (especially compared to those other solutions). Best of all, this will work in any browser that supports Javascript. Let’s focus on the first example and go over why I chose that format.

This way, if Javascript is broken, the worst thing that happens is the click does absolutely nothing. Remember, if you aren’t willing to have your email address break when Javascript is turned off then you have *no choice* but to use those HTML based tricks (that bots have already beaten). For 99.99% of the population, this is a pretty worthy sacrifice. However, for those of you who really can’t deal with that, I present you this compromise:

<a href=”#email.com” class=”email-link” id=”some”>some[REMOVE]@NOSPAMemail.com</a>!

This renders into this:

!

Now if Javascript is disabled, nothing happens but your visitors can still figure out your email address! Although you’d have to pray bots can’t. Anyway, I hope you are starting to see the power of my solution.

Seeing the Address

If we can dynamically re-write the HREF portion of the URL, what’s to stop us from rewriting the innerHTML portion (the stuff between the a tags). Nothing! And this is easily possible. And this should happen during a mouseover so that people can easily read your address if they want.

The Code

Before I give you the demo, please observe the code fragment that summarizes the gist of how this works:

  1. Look for all tags with the class “email-link”
  2. For each one create a new onMouseOver that changes the text (innerHTML) into the email address
  3. For each one create a new onClick that changes the link (href) into an email link

Now I know many of you are looking at my examples and yearning for the actual source code. Please keep in mind that the source code varies greatly depending on how you choose to obfuscate your email address. I’m also confident many of you read this and are now realizing you could dynamically search and replace the “[REMOVE]” and “NOSPAM” text. That said, here is the basic source code, using Prototype‘s getElementsByClassName function:

document.getElementsByClassName(className).each(function(element) {
var emailAddress = this.id + ‘@’ + this.href.split(‘#’).last();
element.onmouseover = function() {
this.innerHTML = emailAddress;
this.href = ‘mailto:’ + emailAddress;
};
})

Now I know some of you will complain about the each() function. As I stressed yesterday, the Prototype library provides shortcuts that make Javascript programming easier. The each method goes through an array, and for each one, passes it into a function as an argument. That function can be defined on the fly, which is what I am doing. Since the array being passed in is all the tags on the page that have “email-link” as its class, the function is then processing each link. The rest, I’m hoping makes a decent amount of sense. The part with emailAddress might be a little confusing, so I will break it down into its simplified equivalent:

var otherPart = this.href; // #mail.com
otherPart = otherPart.split(‘#’); // split it up by the # symbol
otherPart = otherPart.last(); // get the last match found
var emailAddress = this.id; // some
emailAddress = emailAddress + ‘@’; // some@
emailAddress = emailAddress + otherPart; // some@ + mail.com

Demo

If you are burning to see a demo, click here.

Parting Gift

I find that it is becoming difficult to explain my demos without giving you the real source. As such, I have written a Javascript class called CleanCSS. You may download it here.

Designing without Javascript

This article will cover the importance of keeping content, design, and coding elements seperate. I will then explain how you can use advanced techniques to apply Javascript to an element (such as a link) without ever changing the HTML.

Before I begin, I would like to say: I hate CSS. It’s a necessary evil, but I really hate focusing my time and energy on design issues. You see, in an ideal world, designers would design, content providers would provide content, and programmers (that’s me!) would glue it together with backend stuff.

However, this was not how the world spun, my friends. That is, until today.

Continue reading Designing without Javascript

Obligatory First Post

Hello and welcome to my new blog. While it’s hard to predict exactly how this site will turn out, needless to say, I plan to focus a lot of energy into it for the long term. While I did maintain another web journal, it occured to me that the site no longer accurately represented who I am. In short, I’ve graduated from the kid journal and I’m moving on to writing more techincal, thought-out posts. I am in no denial that this journal will contain humor, bad movie reviews, or small tidbits about my daily life, but the intention is to keep this blog insightful and less about the personal, mundane aspects of my life.

Welcome to My New Blog

Welcome. This is my technical blog. If you are a LAMP web developer with an interest in business this is the blog for you.

Here, you will find 100% original articles related to one of two things: IT news or programming. I try to write as many good programming articles as I can, but as you can imagine, it is very hard coming up with original programming posts day after day. As such, the majority of the time, I cover IT business news. I try to refrain from simply summarizing, and I rarely post an article if I can’t find an interesting observation to make. For you programmers, I write about JavaScript, PHP, and MySQL the most. I try to post at least one article a day on weekdays.

You’ll notice this site uses a couple of JavaScript effects that are entirely unnecessary. While I don’t regularly add effects such as these for commercial sites I do, I thought it would be an interesting challenge. For example, the right two navigation links on top of my home page use “AJAX” (loads content without refreshing the page). But to make things more interesting, I added conditions to the project:

  1. The AJAX links had to work without javascript
  2. The content would not be duplicated (no ajax-only versions of a page)
  3. The site must be XHTML 1.0 compliant
  4. There must be no Javascript markup inside the content except in the footer and header as include files
  5. Must integrate with the blog
  6. Must work in the latest versions of Opera, Firefox, and IE and look nearly if not exactly identical
  7. No tables for layout placement

Any seasoned web developer knows these requirements are rediculously hard to meet — especially getting AJAX functionality without marking up the links. =) This was a fun challenge. I will eventually document how these obstacles were overcome and update this page. I plan to buy a Mac soon, but until then, I’m afraid I can’t be certain if Mac browsers are supported. I made the tough decision that this site would require javascript. While many commercial entities always have non-javascript versions of their content, I think we’re getting to that point where Javascript is becoming an integral ‘net technology that is pretty much as standard as HTML tags. As such, since this is a personal site, Javascript is “required.” However, as condition #1 said above the site is fully functional without Javascript (although PNG images break in IE).

Article 1: Designing without Javascript
Article 2: A Brand New Way to Hide Your Email Address