February 22, 2011 0

Keeping Tabs On Your Credit Report

By in finance

Regardless of which financial blogger or author you follow, it is generally agreed that keeping tabs on your credit report is sound advice. By federal law, you are entitled to a free credit report from each of the 3 primary credit reporting agencies every 12 months. (See annualcreditreport.com and avoid all the credit report scams) Of course, that means in the worst case scenario you could potentially have incorrect or adverse information on your credit report for up to a year before it’s detected. A strategy that I employ to lessen this risk is to stagger each of my credit reports every 4 months. An example schedule could be ordering your TransUnion credit report every January, Experian every May, and Equifax every September.

Of course, there’s no guarantee that each of these reporting agencies will have the same information. Which means it’s possible that adverse information only exists on a single report. In which case, you’re back to the original situation of detecting this information up to 12 months after it’s added to your report. However, the odds are in our favor that adverse information is added to more than one of the different reports. This means, in the best case, you can detect adverse information at most 4 months after it’s added to your report.

In order to keep my schedule straight, I have scheduled a Google Calendar reminder for each of the three credit reports. Each reminder repeats annually and sends me an email notice so that I know from which agency the report should be ordered. It’s also a good idea to order a report for your spouse on the same schedule. So far, I like this method for keeping up on my credit health and lessening the risk that incorrect or adverse information negatively impacts my credit.

 
 

Tags:

February 15, 2011 0

CodeMash Recap

By in conferences

I can’t honestly call this a recap or an overview because there is just too much good stuff to do CodeMash proper justice. And I clearly waited too long to do a ‘best of’ or ‘highlights’ post. However, after attempting to give a recap of CodeMash to my fellow CSGers, I had a list of talking points and recommended resources that shouldn’t be put to waste. I’m omitting the two mini-demos that I gave during my recap: git-bisect and BDD/Cucumber. So you’ll have to research those on your own. Seriously, go try git-bisect. It’s cool.

So it was clearly impossible to recap 72 hours of awesome in 1 hour. Not to mention the drinking, water slides, etc. So here are a few resources you ought to check out while you’re sitting on the couch with your wife suffering through American Idol this season.

Reasons why CodeMash is awesome

  1. The tiki hut/bars.
  2. Waterslides. In Sandusky. In January.
  3. Hot-tub snowball fights; lacking only a time machine.
  4. Aside from the numerous presentations, there are great open spaces that spring up. These lead to great discussions and they’re completely ad-hoc. I participated in one covering node.js (check out the #nodemash tag on Twitter)
  5. You’ll see people pairing all over the place in corners, empty rooms, hallway couches. They’re working on mini-projects, trying out demos, and generally experimenting; usually inspired by a talk, keynote, or open space.
  6. You can attend a deep dive on Parallel Programming in .NET and then see an intro to UX design, followed by BDD with Cucumber, topped off with HTML5 and offline webdev. One of the best things about CodeMash is the range of languages, platforms, and technologies. You can meet people doing awesome stuff in Java or Flex, and pick up a few testing tricks from the Ruby dudes. Even within just the .NET world, there was VB, C#, F#, and IronRuby.
  7. Did I mention the after-parties?

Things to check out

If you’re interested in going next year, be prepared. They sold out in just 3 days this year. That’s right: the conference itself lasted longer than the ticket sales.

 
 

Tags:

January 28, 2011 4

Networked PDF printer? Yes, please.

By in home network

Need an awesome solution for printing to PDF? Have multiple home machines and prefer a network solution? Read on!

My setup involves PDFCreator installed in server mode on my Windows Home Server box. The printer is shared so other machines on the network can print to it. PDFCreator saves the PDF on the server under the user’s Documents folder. Using Windows 7 Libraries, a user’s Documents folder on the server is added to their local Documents Library so they have quick access to their printed PDFs.

Step by step process:

  1. Download and initiate the PDFCreator installer from Sourceforge on your home server box. Be sure to select Server Installation during setup and choose the remaining options as you please.
  2. Once installed, start PDFCreator and choose Printer -> Options from the menu. Open the Auto-Save settings and enable Auto-Save mode. Choose your auto-save file name and location (file name/location tokens available in the select box).
    I chose the save location: D:\shares\Users\<REDMON_USER>\PDFs\
  3. Now you can minimize PDFCreator (minimizes to the system tray) and go to your Printers control panel to share the PDFCreator printer. Right-click on the PDFCreator printer, choose Sharing and check Share this printer.
  4. On each of your networked machines, you can now go through the Add Printer wizard and add the PDFCreator printer by using the path: \\<server>\PDFCreator
  5. As an optional step (for Windows 7 users), you can add the user’s Documents folder (on the server) to their local Documents library. On any networked Windows 7 machine, open the user’s Documents library. Under the heading Documents library heading, click the link Includes X locations. Click Add and browse to the user’s Documents folder on your server.

At this point, your user’s can easily print to PDF. The generated PDF is saved on the server in their own user folder and is accessible through their Windows 7 Documents library. However, there is a catch. The PDFCreator monitor must be running to auto-save print jobs to PDF. If it is not running, the jobs will simply queue up and execute the next time someone logs into the server. (The PDFCreator monitor is added as a shortcut to your Startup folder.) To get around this issue, we simply need to turn PDFCreator into a Windows service.

  1. Download and install the Windows Server 2003 Resource Kit Tools.
  2. Download and install Any Service Installer.
  3. Fire up Any Service Installer and switch to Advanced from the mode menu.
    • Fill out the location of your Windows 2003 Resource Kit installation
      (C:\Program Files\Windows Resource Kits\Tools)
    • Select PDFCreator as the application you want to make a service
      (C:\Program Files\PDFCreator\PDFCreator.exe)
    • Enter your WHS Administrator username and password

Now you’re done and you can remove PDFCreator from your startup folder! Users can print freely and the print jobs will execute immediately.

I used two different step by step guides in the process of getting my PDF printer set up: the first for simply installing PDFCreator on a server and the second for turning PDFCreator into a Windows service. If anyone has any other PDF printing, Windows Home Server or home networking tips, be sure to share in the comments. I’d love to hear about any WHS tricks you might have come across.

 
 

Tags: ,

June 4, 2010 0

IE6, MooTools, and MultiBox: A Tale of Woe

By in javascript, mootools

On a recent project, I traveled to the depths of hell and came out alive. Here’s how it went down…

The initial task wasn’t all that unique or difficult. We were to add a few videos (most hosted on YouTube, with a couple self-hosted) that would open in a lightbox-style popup when the thumbnails were clicked. MooTools was already being used on the project, so we selected MultiBox by phatfusion as the pop-up of choice. I won’t go into the reason(s) for selecting MultiBox. The more I work with it, the less I like it; but that’s for another post. So, we have MooTools as the JavaScript framework and MultiBox as the plug-in.

Base Functionality

Keeping progressive enhancement techniques in mind, we set the destination URL of the thumbnails to be the video page on YouTube. This gives crawlers the ability to find the true video destination, as well as user’s without JavaScript the ability to find the video. Now, I realize that YouTube doesn’t even work without JavaScript, but that’s their problem. (On a side-note, it’s really sad that they use JavaScript to inject the Flash video player, when the SWFObject static publishing method would work just fine).

So the first problem we run into is that, by default, the MultiBox media type of youtube expects the link URL to point directly to the video and not to the video page on YouTube (one reason to ditch MultiBox). Note the difference in URLs below. The video identifier is the same in both (eCzEkiIucUk) but rather than passing it as a parameter to the ‘watch’ page, we can pass it as the slug to /v.

Video page on YouTube: http://www.youtube.com/watch?v=eCzEkiIucUk
Actual video on YouTube: http://www.youtube.com/v/eCzEkiIucUk

To deal with this, I wrote a quick script that executes ondomready. It parses the v parameter value out of the query-string and rewrites the URL to point directly to the video. This way, when MultiBox opens and inspects the URL to load, the video itself is opened in the MultiBox pop-up rather than the entire YouTube page.

Roadblock #1 : MultiBox ‘types’

At this point, everything is working as expected until the client requests that we provide a customized fallback message for users without Flash. This is a perfectly reasonable request. Ideally the fallback content would be a transcript of the video and perhaps some still images from the video. Maybe even a link to the raw H.264 video. Of course, in this case we are requested to simply provide a ‘Please install Flash’ message. Unfortunately, MultiBox doesn’t have a way to provide custom fallback content for its youtube type. (Yet another reason to ditch MultiBox.)

Rather than using the youtube type and its out-of-the-box functionality, we’ll switch over to the element type. This type allows you to target an element in the dom and the targeted element (and children) is cloned into the MultiBox pop-up. For this to work, we’ll provide our own object element, complete with cross-browser nesting of objects (see SWFObject static publishing) and our own custom no-flash fallback content. Each video thumbnail will now have the actual video markup next to it in the source, hidden via CSS. The thumbnail is marked up to link to the video page on YouTube (for JS-off users). On page load, the links are rewritten to point to the fragment identifier of the video object in the page (e.g. href="#video1"). This way, when MultiBox is activated using the ‘element’ type, it will grab the object element with id="video1" and clone its contents into the pop-up.

Roadblock #2: MooTools ‘clone()’

With the exception of IE6, everything works as expected across browsers both with and without JavaScript. However, it fails in IE6 (of course). Upon inspection of the cloned object elements after they are inserted into the pop-ups, we notice that they no longer contain the param children they’re supposed to. The original object elements still contain their param children, but the clones do not. Internally, MultiBox uses the MooTools clone() method on the base Element class so I put together a quick test page to verify that MooTools’ clone() method works properly in IE6 on object elements. It failed the test, and I filed a bug against MooTools.

The workaround for the MooTools clone() bug is to use the old-school innerHTML property ourselves rather than allowing MooTools to do proper DOM manipulation in the background. So I open up MultiBox and find the routine whereby it uses clone() and add a quick hack. I check if the browser is IE6 and if so, use innerHTML to copy the object element (and all its children) into the pop-up.

Roadblock #3: IE6 ‘flashvars’

So now we have the object being correctly cloned into the pop-up when a user clicks the video thumbnail. An then I get another ticket. All the YouTube videos are playing, but the self-hosted video is not. Why is the video not playing? This particular video is played using a SWF player which takes the FLV file name to play via the flashvars param. I notice that the FLV file isn’t being requested in IE6. But we just fixed the param bug and the children are all there! Or are they really? After some more debugging and googling, I find that IE6 resets the value of the flashvars param when its innerHTML is modified.

You’re not surprised, are you?

After some more searching, I find a great blog post that describes the solution. Rather than passing the different variables to the flash player using the flashvars param, we’ll just add them to the SWF query-string. So this:

<object … >
  <param name="movie" value="player.swf" />
  <param name="flashvars" value="path=video1.flv" />
  …
</object>

becomes this:

<object … >
  <param name="movie" value="player.swf?path=video1.flv" />
  …
</object>

Since we’re using SWFObject’s static publishing method, there are 2 object elements. One intended for IE, and another one, intended for everyone else. The proper object (for Firefox, Chrome, et. al.) is nested within the IE object and hidden via Conditional Comments. Since this whole flashvars mess is only a problem for IE6, we only need to modify the outer object element.

Roadblock #4: MultiBox’s flvplayer

Just when you thought we were out of the woods, we have one last issue. Now that we have the video objects with proper fallbacks, and the elements being cloned properly, and the config file information passed correctly, we still don’t have a functioning video in IE. Since we modified the outer IE object element, thanks to the previous issue, we’ve broken the video in all versions of IE. What’s the problem this time? It turns out that the flvplayer.swf that comes packaged with the phatfusion MultiBox doesn’t stream the video properly when the FLV file name is passed via query-string. Solution? Ditch phatfusion’s flvplayer and use another! (I recommend any of the JW players if your situation fits the non-commercial bill)

When the bugs align…

So at the end of this ordeal, I had three more reasons to avoid phatfusion’s MultiBox widget, I had filed yet another bug against MooTools, and I had conquered yet another bug in IE6. And it all piled up because of a tiny bug in a particular flvplayer; that was caused by the solution to a specific bug in IE6; which was only a problem because of a bug in a particular version of MooTools; which was only a problem because of a poorly designed API in MultiBox; which was encountered because the client wanted to display a download button for Flash; mostly for users who aren’t even able to install Flash if they wanted to. Don’t you just love web development?

 
 

Tags: , , , ,

May 23, 2010 5

Cross Browser Inline-Block

By in css

How many times have you used float:left to make a bunch of elements align horizontally? Usually this technique is used on lists (of both the ul and ol persuasion) and generally works just fine under a few preconditions. The first precondition is that you are comfortable using some form of a clear-fix hack. Either you apply overflow:hidden to the container, or you add a meaningless empty div with clear:both, or you apply some magic with the :after pseudo-class. While this isn’t a deal breaker, it is annoying.

The second precondition is that all floated elements are of the same (fixed) height. Of course, your original mock-ups with dummy data and lorem ipsum text all use the same element just repeated across the page, right? And then the client provides actual content (hopefully), and you find that some items have a really long title, or a super-tall product image. And what happens? The floats ‘snag’ items and you end up with this:

float see fiddle

If the previous screenshot is what you going for, or both previous preconditions hold in your case, you may stop reading right now. Otherwise, read on and you’ll learn how to create this instead:

final see fiddle

First, I must give credit where credit is due. The technique I’m about to describe (and improve upon) was covered by Ryan Doherty over at the Mozilla WebDev blog. I suggest you read his post first because I’m going to breeze through his foundation and jump into my improvements.

Foundation

Here is the HTML will be working with:

<ul>
    <li>
        <h3>Product 1</h3>
        <p>Some product description.</p>
    </li>
    <li>
        <h3>Product 2</h3>
        <p>Some product description.</p>
    </li>
    <li>
        <h3>Product 3</h3>
        <p>Some really, super, long product description.</p>
    </li>
    ...
</ul>

And some aesthetic styles not relevant to the inline-block layout:

ul {
    list-style:none;
    width:440px;
}
li {
    border:1px solid #888;
    -moz-border-radius:3px;
    width:75px;
    text-align:center;
    margin:5px;
}
h3 {
    font-size:14px;
    font-weight:bold;
    margin:.25em;
}
p {
    margin:.25em;
}

Compliant Browsers

The first step is to try an use the proper CSS property: display:inline-block. This property gives an inline element, block-like properties. Such as the ability to have width and margin. With just this property, we have support in Firefox 3+, Safari 3+, Chrome 1+, Opera 9+, and IE8+. Not too shabby.

li {
    display:inline-block;
}

valign

Fixing the Rest: Firefox 2

Aside from IE 6 and 7, only Firefox 2 fails to support inline-block. To get support in Firefox 2, simply add the mozilla-specific property display:-moz-inline-stack prior to the display:inline-block declaration. Non-Gecko browsers will ignore the -moz rule. Firefox 3+ supports inline-block so it will override the -moz-inline-stack rule. Using the -moz-inline-stack rule for Firefox 2 also necessitates a div be wrapped around the inline-block element’s contents. Given Firefox 2’s latest market share numbers (most give it under 1% overall), I would generally concede that messing with -moz-inline-stack and an inner-wrapping div is unnecessary. For this reason, I have removed the -moz-inline-stack rule from my Inline-Block gist on GitHub, however, you can see it in action at jsfiddle. Feel free to add it back in yourself if Firefox 2 support is necessary.

Fixing the Rest: IE 6/7

IE 6 and 7 both support inline-block natively but with a caveat; they only support it on elements that are inherently inline. Thus, block elements like div and list-item elements like li won’t apply inline-block. However, IE 6/7 has the concept of ‘layout’. (see On Having Layout). IE treats elements with layout triggered exactly the way inline-block elements are supposed to work; that is, block-level elements that are displayed inline. So for IE6/7 we reset the display to inline, and trigger hasLayout with zoom:1.

* Note: You can apply the IE 6/7 rules in any manner you wish. Conditional Comments paired with IE-only stylesheets is generally the preferred method. However, I have gone with the *hack in this case to make these utility classes copy/paste-able.

li {
    display:inline-block;
    *zoom:1;
    *display:inline;
}

The final touch is to set vertical-align:top to make the boxes line up across the top:

li {
    display:inline-block;
    *zoom:1;
    *display:inline;
    vertical-align:top;
}

final

Room for Improvement

So now we have our elements aligned horizontally without using floats. We have one last problem which is where I will improve on Ryan’s method. In the screenshot below I have changed the li margin to margin:5px 0; We would expect the left and right borders of each box to touch, no?

whitespace

The problem is due to the fact that white-space surrounding inline elements is displayed. Of course, this makes perfect sense. Imagine if the white-space between words in a sentence weren’t displayed! The trick is to take advantage of letter-spacing and word-spacing to counter the white-space between our inline-block elements. (This is unnecessary in IE6/7 which already ignores the white-space between boxes because the elements have hasLayout triggered and are not technically inline-block.)

Six of One…

My first attempt was to apply a negative word-spacing to the container. Word-spacing is inherited, so we must reset it to normal on our inline-block elements themselves so as to not affect their children. With word-spacing set to -1em, we have eliminated the offending white-space in Firefox and Opera.

nowhitespace see fiddle

…Half a Dozen of the Other

In order to fix WebKit (Safari, Chrome) we must also apply negative letter-spacing. Interestingly, applying only letter-spacing actually fixes both WebKit and Firefox which means that either letter-spacing or word-spacing will work for Firefox. However, in order to appease Opera, we will apply both. see fiddle

All Together Now

I have pared down the necessary rules to a set of utility classes named ib-container and ib-block, as seen below. You can also find them in a gist on GitHub and as a fiddle on jsFiddle.

.ib-block {
    vertical-align:top;
    display:inline-block;
    *zoom:1; /* IE6/7 */
    *display:inline; /* IE6/7 */
}
.ib-container {
    letter-spacing:-.25em;
    word-spacing:-1em;
}
.ib-container .ib-block {
    letter-spacing:normal;
    word-spacing:normal;
}

Other Variations

They can be used on list items as seen in this example or any other set of sibling elements:

<div class="ib-container">
    <div class="ib-block">…</div>
    <div class="ib-block">…</div>
    <div class="ib-block">…</div>
</div>

They can be used without the ib-container class if the white-space between ib-block elements is not an issue for you:

<ul>
    <li class="ib-block">…</li>
    <li class="ib-block">…</li>
    <li class="ib-block">…</li>
</ul>

They can be nested so an ib-block element becomes an ib-container for other ib-block elements:

<ul class="ib-container">
    <li class="ib-block ib-container">
        <div class="ib-block">…</div>
        <div class="ib-block">…</div>
    </li>
    <li class="ib-block ib-container">
        <div class="ib-block">…</div>
        <div class="ib-block">…</div>
    </li>
    <li class="ib-block">…</li>
</ul>
 
 

Tags: , ,

March 10, 2010 3

Google Analytics Tagging with HTML5 data-* Attributes

By in javascript, jquery, mootools

Imagine if you will, a page with a significant amount of dynamic page elements. For instance, a slide-out panel containing a number of ‘panes’ containing topical information on various ‘factors’. Let’s assume that once this slide-out is open, we wish the user to be able to jump from factor to factor (similar to a slideshow) using buttons along the bottom of each factor. Let’s go even deeper and say that within each factor, we have a collection of close-up images. Again, the user should be able to navigate the close-ups via next/previous buttons similar to a slideshow. In addition to the next/previous buttons, along the top edge of the ‘close-ups’ section are progress indicator dots that highlight according to which close-up is active (and link directly to individual close-ups).  Given that this functionality should work without JavaScript, all of these UI controls are marked up as links. And we have quite a few of them—to wit, x*(x-1) factor links (for x factors) plus x*y (direct links to close ups per factor) plus x*(2y) (next/prev links for each y close-up for each factor). So, let’s say we have 3 factors and 3 close-ups per factor. We now have 33 links! And now the task is to tag each of these links with unique labels that will be sent back to Google Analytics upon each click event. I’ve broken down a brief subset of the analytics tags for each of the three types of links below.

Tag Templates

Tagging template for the factor navigation along the bottom of each [x] factor:

/page_name/factor_[x]/factor_1_icon
/page_name/factor_[x]/factor_2_icon
/page_name/factor_[x]/factor_3_icon

Tagging template for the prev/next buttons on each [y] close-up on each [x] factor:

/page_name/factor_[x]/closeup_[y]/next_arrow
/page_name/factor_[x]/closeup_[y]/prev_arrow

Tagging template for the close-up direct links (also used as progress indicator) on each each [x] factor:

/page_name/factor_[x]/closeup_dot_1
/page_name/factor_[x]/closeup_dot_2
/page_name/factor_[x]/closeup_dot_3

Approach

As with anything, I try to keep my code DRY. Considering that these tags will likely end up as magic strings in some form or another, I’d like to reduce the maintenance overhead of these tags as new factors or close-ups are added or removed. The tags themselves convey the hierarchy of the structure in which they are contained. So let’s map the tagging hierarchy onto the structural hierarchy. This tagging information could be embedded in the id or class attributes of an element, though I think that would be coupling two separate needs (JS behavior/CSS styling + Analytics) onto the same data. This information could also conceivably go into the title attribute, though this attribute is meant for human (read: end-user) consumption. Nothing seems to fit, so let’s try out an HTML5 data-* attribute: data-ga.

First, the /page_name segment should map to the page:

<body data-ga="/page_name">

Each ‘factor_[x]’ segment should map to its own factor pane:

<ul class="factors">
  <li data-ga="/factor_1" />
  <li data-ga="/factor_2" />
  <li data-ga="/factor_3" />
</ul>

Each ‘closeup_[y]’ segment should mapt to its own close-up pane:

<ul class="closeups">
  <li data-ga="/closeup_1" />
  <li data-ga="/closeup_2" />
  <li data-ga="/closeup_3" />
</ul>

And each link or button gets its own respective value. Keep in mind, multiple data-ga values will be ‘scoped’ by their ancestors’ data-ga values:

<a href="#factor-1" data-ga="/factor_1_icon" />
<a href="#factor-1-closeup-1" data-ga="/closeup_dot_1" />
<a href="#factor-1-closeup-2" data-ga="/next_arrow" />
<a href="#factor-1-closeup-3" data-ga="/prev_arrow" />

Now, whenever a link is clicked, we simply concatenate the data-ga values from each ancestor! The method below should have the context of this as an anchor element with a data-ga attribute. Generally, it would be in the click handler of any element matching the selector: "a[data-ga]". Once ga is concatenated, it can be used as the tag for a Google Analytics API call (_trackPageview or _trackEvent).

$("a[data-ga]").click(function(event){
  var ga = $(this).parents('[data-ga]').andSelf()
           .map(function(){return $(this).attr('data-ga');});
  ga = $.makeArray(ga).join('');
  _pageTracker._trackPageview(ga);
});

Demo

A few additional notes

Performance

It would be much better to calculate the ga-tag for every link on the page during page load and cache the result in the data store of the element. As written, the ancestor traversal is executed on every click, and would result in the same return value each time. However, as a special case when I was first implementing this, there were some widgets that altered the hierarchy of the page, thus it was necessary to only perform the concatenation at event-time rather than load-time.

As an additional performance boost, I added a class of ga-scope to each ancestor element that contained a data-ga attribute. This allowed me to use a class selector in the .parents() filter. This will only yield a performance boost in browsers that support a native implementation for querying by class name, thus allowing the selector engine (MooTools or jQuery) to avoid stopping to inspect every single ancestor on its way up the tree.

MooTools

I originally implemented this with MooTools. During the implementation I discovered a bug in the MooTools selector parser where the attribute selector doesn’t properly find attributes with hyphens. So, I created a custom pseudo-selector as a workaround:

Selectors.Pseudo.data_ga = function(){
  return Boolean($(this).get('data-ga'));
};
$$('a:data_ga').addEvent('click', function(event){
  var ga_code = this.getParents('.ga-scope')
                .get('data-ga').reverse().join('')
                + this.get('data-ga');
});
 
 

Tags: , , , ,

March 6, 2010 2

OpenID: Redirects and Delegation

By in openid

The Introduction

I’m a big fan of OpenID. I like the fact that my online (public) identity is associated with a URL that I own. This affords quite a few benefits, such as associating my public profile at various networks with one another. Even better, OpenID supports the delegation of identifiers to OpenID Providers. This allows the owner of a domain to use the domain as an OpenID without operating his own OpenID server. He simply delegates the provider responsibilities to an existing provider by adding some HTML link references at the top of his OpenID URL. But before I get too far ahead of myself, a bit of history.

The History

The Global Name Registry was delegated the .name top-level domain by ICANN in 2001. [Wikipedia] The intention was to set aside a specific top-level domain for individuals to register as their own domain. These domains may be registered on the second level (john.name) and the third level (john.doe.name). Generally, the second level domains are shared among the registrants of the third-level. (Aside: I find it rather surprising that the assortment of ancestry sites don’t take advantage of this for linking in family trees) In 2007 the GNR spun-off a small start-up formed as a partnership with JanRain‘s OpenID provider, myOpenID. This partnership created FreeYourID.com. The goal of FreeYourID was to make it dead simple for users to both register their own .name domain and use it as an OpenID. FreeYourID provided a couple great features. The domain registration was transparent to the end user, making it very friendly to non-techies. A .name email address was created (john@doe.name). FreeYourID provided a few URL forwarding options for those with existing domains. They had a decent default landing page that aggregated various social network profiles (YouTube, Flickr, Blogs). They even supported microformats with XFN! And via the partnership with myOpenID, the .name domain was automatically setup as an OpenID.

The Situation

So in 2007 I registered jason.karns.name from FreeYourID.com. A myOpenID account was created behind the scenes which handled the OpenID login. So as an end user I would attempt OpenID log-in at a relying party, which would navigate to jason.karns.name and encounter the OpenID delegation snippets. This would foward over to myOpenID (tied to the shim account) where I would authenticate and be redirected back to the original service having been authenticated as jason.karns.name. I used this service for 2 years as OpenID was beginning to gather steam. I used jason.karns.name as my primary web address (which was forwarded to other sites). I collected a few social network links on FreeYourID’s social network page (which provided a great resource for XFN crawlers). But most importantly, I used my OpenID as my primary (in some cases, only) authentication method at quite a few online services.

The Problem

At the beginning of 2009, the .name domain was transferred to VeriSign. This spelled the beginning of the end for FreeYourID. Toward the end of the year, FreeYourID announced it was shutting down and would be transferring all services over to DomainDiscount24. Prior to the transfer, I purchased jasonkarns.com. Once my .name was transferred, I setup an HTTP 301 redirect from jason.karns.name to jasonkarns.com. The landing page of jasonkarns.com contained the same OpenID delegation snippets as jason.karns.name so I assumed everything would continue to work. I was wrong. This setup prevented me from logging in at every service that used OpenID.

The Discovery

Through some digging and a bit of guidance by this post (thanks Will), I discovered that an OpenID relying part must follow all redirects and the final destination URL is used as the OpenID Identifier rather than the original URL. So in my case, I would attempt to login with jason.karns.name which redirected to jasonkarns.com, which was then delegated to myOpenID. I would authenticate normally at myOpenID because the delegation snippets specify which account to use at the provider. However, when redirected back to the relying party, my authentication token reported my ID as jasonkarns.com. As there was no existing account registered for jasonkarns.com, most relying parties would initiate their ‘new user’ flow. Others just error-ed out.

The Fix

So now I realize what the root problem is, but I’m not sure how to fix it. I definitely have to get my OpenID working again so I must serve the OpenID delegation code from jason.karns.name directly. However, I also want to continue using jasonkarns.com as the primary online destination for people looking for me.

  1. Configure DomainDirect24 to stop the HTTP 301 redirect to jasonkarns.com
  2. Create a landing page for jason.karns.name which contains the OpenID delegation code
  3. Use the old-school meta-refresh to handle the redirect from jason.karns.name to jasonkarns.com. OpenID Relying Parties won’t follow the meta-refresh because they are only interested in the delegation code.
  4. Setup a frameset to load jasonkarns.com from within jason.karns.name. This is only for user-agents that don’t or won’t follow the the meta-refresh. This way end users still end up with the same content.

The Result

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en' lang='en'>
 <head>
 <title>jason.karns.name</title>
 <meta http-equiv='Content-type' content='text/html; charset=utf-8' />
 <!-- OpenID server and delegate -->
 <link rel="openid.server openid2.provider" href="http://www.myopenid.com/server" />
 <link rel="openid.delegate openid2.local_id" href="http://jason.karns.name" />
 <meta http-equiv="X-XRDS-Location" content="http://www.myopenid.com/xrds?username=jason.karns.name" />
 <!--Redirect has been requested -->
 <meta http-equiv='refresh' content='0;url=http://jasonkarns.com' />
 </head>
 <!-- Frame Redirection for human content readers -->
 <frameset rows='100%,*' style='border:0;'>
 <frame src='http://jasonkarns.com' frameborder='0' />
 <frame frameborder='0' noresize='noresize' />
 </frameset>
</html>

The Future

While this isn’t the opimal solution, it works for now. I rather like the idea of potentially having 2 separate OpenIDs (though they are both delegated to the same myOpenID account). However, I don’t like the meta-refresh redirect. At one point there was a discussion going on for the OpenID spec around giving 303 (See Other) redirects special behavior—as oppposed to 301 (Moved Permanently), 302 (Found) and 307 (Temporary Redirect). Although at this point, I don’t hold much hope. My only other choice of action is to follow Will Norris’ method and use server-side HTTP Request sniffing and respond accordingly (OpenID delegation for suspected Relying Parties, 301 Redirect for everyone else).

 
 

Tags:

February 25, 2010 5

JavaScript Best Practices

By in javascript

@ikeif recently tweeted a request for some JavaScript best practices. Rather than simply reply to him, I thought I’d post them here and beat him to the blog-post-punch. I’m not going to expand much on any of these, although any discussion that arises will likely spawn its own post. These are in no particular order and are really nothing more than a brain-dump. I’ve numbered them for easy reference in the comments.

  1. Avoid global variables. When you must use a ‘global’, use your own namespace.
  2. Avoid cluttering the global namespace with functions. Assign your ‘global’ functions to a single namespace (see above).
  3. Discover the JavaScript framework/library that speaks to you and stick with it. Don’t load jQuery and Prototype on the same project. Yes, I know you can run many libraries in noConflict mode now, but think of the additional overhead you are placing on your users. All for some snazzy plugin? Port it!
  4. Use JSLint. I assume you validate your HTML? Use JSLint to validate your JavaScript. If your code is JSLint safe, you can avoid a few browser idiosyncrasies (hasOwnProperty() anyone?). As a bonus, JS-Lint safe code is also JSMin safe so you can minify your scripts without worrying if the minification will affect functionality.
  5. A side effect of using the JSLint validator in Aptana, my IDE of choice for front-end development, is my use of JSLint’s special `/*global */` comment. JSLint will flag any global variables unless they are explicitly listed as dependencies in this comment. This means at the top of all of my scripts, one can easily spot any required dependencies (specific MooTools modules for instance).
  6. Use feature detection not browser sniffing.
  7. Write unobtrusive scripts instead of inline event handlers.
  8. Keep your styles in your CSS! Although most libraries make it easy to manipulate element styles, it’s much better to keep your styling where it belongs- in your CSS. Mixing the two violates separation of concerns and makes your code less maintainable. Instead, add and remove classes as necessary in your scripts.
  9. Make sure your UI elements support proper interaction when JS is disabled. If a link opens a lightbox, set the href to point to the lightbox content so no-JS users can still access the content. Links with `href=”#”` kill kittens.
  10. Any UI elements that *only* support JavaScript interaction (and think carefully about this) should be created by JavaScript. Don’t litter your HTML will dummy elements that are only there for JS events. Your script should create and inject them.
  11. If at all possible, don’t modify libraries or plugins directly. This makes future upgrades a nightmare. It is much better to extend the plugin/library without modifying the original.
  12. Your .js files should be served with HTTP `Content-Type: application/javascript`. BUT the `type` attribute in your HTML `script` element must be `text/javascript` or else Internet Explorer will crap itself.
  13. Language=”JavaScript” was deprecated, like, a zillion years ago. Stop using it.
  14. Don’t pre-optimize your code by using fancy looping structures. It is much better to have readable code. Once your app is running, then you can go back and profile it to eliminate bottlenecks. There is no point in pre-optimizing your scripts when the overhead of your background image is 10x slower.
  15. Don’t return false from an event listener when all you really want is event.preventDefault(). Maybe someone else wants to listen for that click event, too, mmmkay?
  16. Stop using document.write

Okay, that’s my list. I may add more later. Disagree with any of these? What best practices or anti-patterns do you have?

 
 

Tags:

February 15, 2010 1

CSS Reset

By in css

Why start with a blank slate? After years of web development and hundreds of sites, starting from scratch on each project really turns into a buzz kill. Nobody wants to spend time rehashing the same issues from site to site. So many of us have turned to CSS Resets. As we all know, CSS Resets are designed to fix cross-browser inconsistencies by rebasing all or most default styles to a common state. I’ve always had a problem with these resets. Many of the styles in these resets are never used (how often do you use q, ins, del, and table anymore, really?). Other styles are completely overridden. I would wager that by the end of a long project, one could probably remove the CSS Reset without affecting the design (save maybe the margin/padding rules). Jonathan Snook feels the same way. For these reasons, I’ve generally used the universal margin/padding reset:

* {margin:0; padding:0;}

There is quite a lot of contention around the subject both for and against as well as the reasoned centrist.

So, rather than continue to rail against their futility, performance penalty, or outright boorishness, I thought I’d actually use a CSS reset a few times and report my findings.

Decision Time!

CSS Reset by Eric Meyer or YUI Reset? Well, after watching this video (you should, too), my decision was firmly in the Meyer camp.

First Reactions

Who uses Firebug? Okay, sorry, who doesn’t use Firebug? If you don’t, you should, and if you do, you likely won’t like Meyer’s reset without it first being modified. Ladies and gentlemen of the jury, Exhibit A:

reset

Due to the first rule in the reset, the font-size property is applied to (nearly) every element. However, font-size is also an inherited property. Which means nearly every element inherits its value from its parent, while simultaneously being reset itself by the same rule it inherited! The first rule of nearly every stylesheet of mine usually includes a set of font properties (font-family, font-size, and line-height). With these properties already being set, there is no reason to have them in my CSS Reset, so let’s remove the offending rule and relieve some of Firebug pressure.

reset3

Whew, that’s better.

Don’t Lose Your Focus!

The most offending rule in Eric’s reset is his outline rule:

:focus { outline: none; }

Sure, he adds a comment to remind users to be sure to specify proper outlines for keyboard users. But you and I can both count on one hand the number of times a proper outline is reinstated for the :focus pseudo-class. Besides, I subscribe to the belief that frameworks and tools should make it easy to fall into the pit of success rather than making it harder to do things the right way. Luckily, Patrick H. Lauke has outlined (sorry, I couldn’t help it) a method to remove the outline during its less-useful moments, while retaining the outline as necessary for keyboard navigation. In brief, simply:

a:hover, a:active { outline: none; }

This will hide the ugly outline during the click action on a link as well as during the time the page loads (so long as the user doesn’t move their mouse). I think this fits nicely in the 80/20 category.

And Now?

So where does that leave us? I’m not sure. I’m still not entirely convinced of the utility of a CSS Reset. However, I believe my two minor modifications do bring Meyer’s Reset a bit further into the ‘’useful’ category without being a pain or downright harmful. My version of the reset is hosted at GitHub, so if you don’t like it, go fork it!

http://github.com/jasonkarns/css-reset

 
 

Tags:

November 17, 2009 3

Roy.G.Biv alpha

By in css

I was recently on a project that called for a translucent background color over a an image similar to this:

rgba http://www.flickr.com/photos/yeowatzup/ / CC BY 2.0

Of course, being the conscientious web developers we are, we want to be as semantic as possible with our markup. This means that text should be marked up as text and not flattened into the image, forever to remain hidden from the world of web spiders, search engines, assistive technologies, and mash-up artists. We give the text a background color to keep the text readable over the background image but we still want the background image to be slightly visible through the text area. Before RGBa, we would resort to a 1 x 1px translucent PNG but this adds additional overhead (both with the extra HTTP request, the maintenance of the image should the color change, and a PNG fix for IE6). Another option would be the CSS opacity property. Unfortunately, the opacity property applies to an element and all of its descendants. This means the text itself would become translucent as well, something we would like to avoid if possible. So, let’s use some RGBa!

First, add the standard RGB background color so the text block will still be legible in browsers that don’t support RGBa:

  div {
    background: rgb(100, 100, 183);
  }

Now we can enhance this for conforming browsers:

  div {
    background: rgba(100, 100, 183, .75);
  }

We now have support in Firefox 3+, Webkit (Safari 3+, Chrome 1+). What about that other browser? To add support for IE6-IE7, we need to use IE’s proprietary filter property. As this is a proprietary property, it should be included via an IE-only stylesheet referenced using Conditional Comments.

  div {
    background:transparent;
    filter:progid:DXImageTransform.Microsoft.gradient(startColorStr=#BF6464B7,endColorStr=#BF6464B7);
    zoom: 1;
  }

A bit of an explanation is in order. First we set the background to transparent which overrides the solid color rgb declaration. Next we apply IE’s proprietary filter. Notice we set the startColorStr and the endColorStr to the same values. These values are not your standard HEX values. Instead of 0xRRGGBB, the first 2 digits are the alpha transparency. Converting our 75% into HEX (.75 * 255 –> 191.25 –> 0xBF). Lastly, we apply the zoom property to trigger hasLayout on the element. This is required for the filter to take effect.

Keen observers will note that the filter property is not supported in IE8 standards mode. As IE8 now properly follows the CSS grammar, we must add the vendor prefix and quote the value. The hasLayout trigger is no longer needed.

  div {
    background:transparent;
    -ms-filter:"progid:DXImageTransform.Microsoft.gradient(startColorstr=#BF6464B7,endColorstr=#BF6464B7)";
  }

Combined, we have our main CSS:

  div {
    background: rgb(100, 100, 183);
    background: rgba(100, 100, 183, .75);
  }

and IE’s CSS:

  div {
    background:transparent;
    filter:progid:DXImageTransform.Microsoft.gradient(startColorStr=#BF6464B7,endColorStr=#BF6464B7);
    -ms-filter:"progid:DXImageTransform.Microsoft.gradient(startColorstr=#BF6464B7,endColorstr=#BF6464B7)";
    zoom: 1;
  }

We have now achieved cross-browser, CSS-only (no PNGs needed), alpha transparency!

 
 

Tags: ,