If you’ve never heard of Digg, what Digg originally was was a tech-oriented news aggregation site. Users submitted links to tech stories and stories got dugg up or buried based on their popularity, with the most popular stories making it to Digg’s homepage. In the beginning, Digg only had 14 categories: apple, deals, design, gaming, hardware, links, linux/unix, mods, movies, music, robots, security, software, and technology. It was a great place to learn about and spread news of cool tech stuff. Almost anyone with a link to an interesting story (including me) could get it promoted to the front page. Over the years Digg slowly evolved into more of a social news aggregation site that covered topics other than technology (see below) and along with it’s growth in popularity came abuses to the system. Users found ways to game the system, and advertisers used it as a way to promote their products and services. For the most part, we, the users, of Digg, were able to tolerate the various abuses that crept in. That is up until now.

With the latest release of Digg 4, the site has again changed, however its user base is not happy. In fact, between the site being down frequently with the new release and the Digg system being plagued by submission from it’s main competitor reddit.com, it’s become almost unusable. Popular stories have no relevance as anything is being promoted by a large group of disgruntled members. It’s not possible to set your Digg homepage to a specific category as you could in the past, upcoming stories are gone (they were gone but have been brought back) and the concept of following other Digg users is now a core part of the new site. As one Digg member put it:

“worst. facebook clone. ever.

i couldn’t care less about “my news” or “my friends bla”. i came to digg.com to see the digg community’s news. i don’t want to subscribe to anything. i’ve been visiting digg.com for the last years at least three or four times a day and always found interesting new stories without having to do all that crap. now, the digg.com frontpage is an emtpy, big mess. i have to klick on “top news” to actually see anything. after clicking on a story, i have to click another time to actually see any comments. that’s at least three clicks more than i needed before. and it sucks. the old digg.com was simple, unique, it was self-explenatory. now i can’t even find the upcoming stories and i feel like i’m on a strange facebook-twitter hybrid. however, i hate twitter and i don’t need more than one facebook.

meh.”

In 2005, Digg’s motto was “What’s Digg? Digg is a technology news website that employs non-hierarchical editorial control. With digg, users submit stories for review, but rather than allowing an editor to decide which stories go on the homepage, the users do”

In 2006 this changed to “Digg is all about user powered content. Everything is submitted and voted on by the digg community. Share, discover, bookmark, and promote stuff that’s important to you!”

Fast forward to today and now the first thing on Digg’s about page is “Better performing ads. Ads on Digg enable you to seamlessly integrate your content and engage everyday users and taste makers as they discover and curate content online.” How times have changed.

Digg seems to have lost its way and the spark of what made it cool in the first place. It’s been drawn into the social networking pool where not everyone enjoys swimming. Digg is now about following people and having them follow you. I may be in the minority here but I truly could care less about following other people. Why should I believe that someone I don’t know who may digg items I like will continue to do so? Why should I care? What originally made Digg great was that it allowed the masses to vote on cool tech news and the most popular ones were easy to find. Now the content is controlled by a small group of fanatical users and the rest of us are now forced to wade through the mire to find something that is of actual interest. Digg’s power users have made it virtually impossible for the average Joe to get a story to the front page, despite Digg’s claims of adjusting their system to help stop this behavior. In other words, where Digg was once a great tool to find interesting news, it has now become the same cesspool that it tried to help its users avoid.

Oh and those basic original news14 categories? Well as of early 2010, they had evolved into:

• Technology
  • Apple
  • Design
  • Gadgets
  • Hardware
  • Industry News
  • Linux/Unix
  • Microsoft
  • Mods
  • Programming
  • Security
  • Software
• World & Business
  • Business & Finance
  • World News
  • Political News
  • Political Opinion
• Science
  • Environment
  • General Sciences
  • Space
• Gaming
  • Industry News
  • PC Games
  • Playable Web Games
  • Nintendo
  • PlayStation
  • Xbox
• Lifestyle
  • Arts & Culture
  • Autos
  • Educational
  • Food & Drink
  • Health
  • Travel & Places
• Entertainment
  • Celebrity
  • Movies
  • Music
  • Television
  • Comics & Animation
• Sports
  • Baseball
  • Basketball
  • Extreme
  • Football – US/Canada
  • Golf
  • Hockey
  • Motorsport
  • Olympics
  • Soccer
  • Tennis
  • Other Sports
• Offbeat
  • Comedy
  • Odd Stuff
  • People
  • Pets & Animals

And just about a day ago, just after Digg 4.0 rolled out, Digg founder Kevin Rose has announced that he is stepping down as CEO.

On a side note, I just got an email from Digg with the subject, “We’ve Created A Monster – The New Digg Is Here”.  How true.

Both hide() and fadeOut() work similarly in that they gradually change an element’s opacity  to zero, and then change the display style property to none (hide() also change the height and width). However, while using animate() to change the opacity will look like it accomplishes the same result, it doesn’t change the display style property to none like hide() and fadeOut() do. Therein lies the gotcha. If you use hide() or fadeOut() to make an element disappear, you can’t use animate() to change the opacity and make the element visible again. Since hide() and fadeOut() also set the display style property to none, animate() can’t do its job because hide() and fadeOut() have effectively hidden the element, causing it to remain invisible.

This has tripped me up from time to time; especially when I’m trying to keep an element hidden and then animate a few properties simultaneously as I fade it back in. So while hide() and fadeOut() are quite capably on their own, and show() and fadeIn() work well to make elements visible again, stick with using animate to hide or fade out an element when you want to fade it in later as well as animate other properties at the same time.

I’m currently working on a project that uses jQuery throughout the user interface to improve the user’s experience. In one section of the application there are three divs laid out next to each other horizontally as if they were three columns. The leftmost div contains a series of items to select from via check boxes. When you pick one (or more) items, the middle div is populated by a jQuery Ajax query and displays a list where the content is based on what was selected in the first (leftmost) group. Finally, you can click on an item in the middle div which will then bring up detailed information in the rightmost div.

Normally this wouldn’t be a problem, but in this case the issue is that the width of the columns needed to be dynamic. If we had made the column widths fixed, then whenever the data in any of the columns was wider than the containing div, a horizontal scrollbar would’ve popped up. While this wasn’t a showstopper, it’s wasn’t visually appealing. You might be thinking that using a table would be a good solution except for the fact that resizing table cells isn’t much easier than resizing multiple divs, plus we’re not displaying true tabular data. Another possible answer could lie in using frames, except for the fact that frames disappear in HTML5 and I haven’t used frames in over 10 years.

So back to our divs. To find a solution I realized that not only would I need the three main div containers, but I would also need two more divs to act as column separators. These two new divs should give me something to grab and drag since dragging the left, middle, and right container divs themselves wouldn’t look right.  OK, so now we have five divs laid out horizontally. Three for content and two to act as drag handles.

So we have our layout but the real brain work still needed to be done. How can I manage all the divs so that only the two “handles” were draggable AND the three content divs would respond to the movement of either handle? By using jQuery I could make the two handles draggable – that was easy. The problem now was how to get the content divs to react to the handles being moved. After many failed experiments, I determined how to properly arrange the divs so that dragging the handles not only properly resized the container divs, but the handle divs were prevented from overlapping each other.

During some of my initial experiments I would drag the handles and the neighboring content divs would be resized, but they ended up pushing my handles while they were being dragged making them move much farther than they should have. After positioning the handle divs absolutely that solved the ghost movements, but introduced another problem. With the handles positioned absolutely, they had been removed from the flow of the document so I couldn’t rely on their dimensions and other CSS attributes to “push” the other content divs. Now I had to calculate their position and use that information to resize the other div’s width. When dragging the left handle we would change the width of the left and center content divs. When dragging the right handle we would change the width of the center and right content divs. There wasn’t any need to change the left position, margin, or padding for any of the elements and this was a big relief.

Not to go into too much technical detail, but jQuery’s draggable interaction has a containment option which allows you to restrict the movement of draggable elements. This would be critical to prevent the handles from being dragged too far. The problem is that you either pass it an element, like the parent of a draggable element, the body of the page, or give it a set of coordinates. The problem with the coordinate system is that it’s relative to the document, not an element. Had we been able to specify the coordinates relative to an element rather than the document, this would’ve been much easier.  Since we had to use coordinates relative to the document we had to make our calculations relative to the document as well, which caused a conflict with webkit browsers when we wanted to center our columns. The problem with webkit browsers is that they don’t calculate the jQuery offset() function properly when you center something by using margin: 0 auto and you have a whole slew of “how am I ever gonna get this one to work?” problems to solve. Once I figure out that by solving the webkit centering issue I wouldn’t have to worry about the offset() issue it was smooth sailing.

Another issue involved the content divs themselves. Floating them didn’t work and absolute positioning didn’t either.  I began to dig into the CSS display property. Did you know that the display property can be:  block, inline-block, inline-table, list-item, run-in, table, table-caption, table-cell, table-column, table-column-group, table-footer-group, table-header-group, table-row, or table-row-group? Neither did I. As it turns out, inline-table did the trick. (Note: I later found out that inline-block also works just fine.)

The W3C says that the inline-table property is “a rectangular block that participates in an inline formatting context”. This basically means that you can have a block with a width, height, margins, etc. but it’s treated as an inline element instead of the usual block element. Hmmm. So far so good. Add that, width, and a little vertical-align:top to all the container divs and we’re looking good. The handle divs get positioned absolutely and get their left position set initially based on the container divs to their left (i.e. the first handle has a left position equal to the width of the first container div and the second handle has a left position equal to the width of the first two container divs plus the width of the first handle. That’s all the CSS you need, the rest is jQuery.

Since we can’t center the big div that contains everything and do our dragging because webkit browsers can’t calculate the correct jQuery offset, we center it manually (note that this isn’t necessary if you’re not going to center the whole shebang). Then we have to figure out the horizontal limits of our drag handles. We don’t want to have people dragging the left handle over the right handle and vice versa, plus we should also give the content divs a minimum width so that the content doesn’t become unreadable. Finally we calculate the containment area for each draggable handle once the opposite handle is finished being dragged. Phew.

Finally, this code is pretty compact and works in all browsers including IE8. It doesn’t work in IE7 or IE6 and that’s just fine with me. It also degrades well for those with JavaScript disabled. Check out the demo and feel free to play with the code. If you come up with a more elegant solution or use this in a project of your own feel free to share it.

View the demo here

First off wallpaper. I love interesting wallpaper for my computer. Paying for it is our of the question. Actually I used to be a paying member of Webshots since they had a good variety of high res stuff, but since that time I’ve found a few sites with a great selection. And they are:

• National Geographic – National Geographic has been around a long time and one reason is due to their stunning photography. Head over to their site to find loads of high resolution, free images for your pleasure.
• InterfaceLift – With thousands of high resolution images in a wide variety of sizes, InterfaceLift can keep you busy for hours downloading wallpaper.
• Mike Swanson – Back in 2005 Mike (a Microsoft employee) began posting his own high resolution, mostly macro shots of just about anything. Most are worthy of being framed and hung on your wall. 150 and counting.

Apple. Despite problems, Apple seems to be coated in Teflon™ and resistant to anything negative. The new iPhone has major issues (even though I want one I won’t buy one due to AT&T sucking hard) yet sales are stellar. Hell even businesses have been born due to their problems. The iPad has yet to become the magical device Steve Jobs would love you to believe it is and sales are stellar. Looking back a little further does anyone remember the MacBook Air? Beautiful to look at, ridiculous to use. How does a company with so many issues continue to go unscathed? Anyway, getting back to cell phones in general, is it just me or does anyone else think that there are just too damn many models of phone to choose from? And doesn’t it feel like new phones come out and then disappear from the market faster than ever? I can’t keep up anymore. You’ve got the iPhone, Droid variants, HTC, BlackBerry, LG, Samsung, Motorola, Nokia,  and on and on and on. And let’s not forget Microsoft’s recent foray into the cell market with the only-on-the-market-for-seven-weeks Kin fail.

Switching gears. I’ve slowed down my jQuery development a bit and gotten back into more PHP work lately. Until recently, my main server was still running PHP 4 (yes really) however about a week ago it finally got the bump to PHP 5 (yeah, yeah I know, welcome to 2004). What I found funny about making the change from JavaScript work back to PHP was how similar the languages are, as well as the little quirks that make them quite different. The biggest face palm I had was regarding variable scope. In JavaScript, variables outside of functions are scoped globally by default. In PHP that’s not the case. This little difference caused me to lose far more time debugging than I care to share. That aside, I still love PHP and think that it’s the best language to use when developing for the web.

And finally, my favorite image this week:

The first time you visit the page you see what appears to be a normal home page

Notice that the vertical scroll isn’t at the top of the page? It’s almost imperceptible and in fact, I didn’t notice it for a week. Why does this happen? Scroll up the page and you’ll see that msnbc.com now has a large chunk of content sitting up above what appears to be the normal top of the page. It wasn’t until I saw a link where some of the old navigation used to be that said “Where’s my navigation? We’ve moved it to the top” that I noticed this big change.

So I have to ask why would you redesign a page and place a large chunk of important content up above where the visitor will see when a page loads so that they have to scroll up to see it? This just seems completely counter intuitive to web navigation. Visit a news site and then scroll up to read the headlines? That’s like opening the New York Times and then finding that the top stores section was folded down behind the front page.

Msnbc.com explains this change by saying “We’ve moved the news menu to the top of story pages and made it easier to see what’s happening across the site. When you first get to a story, you’ll see sections and shows displayed across the top of the page. Below is the name of the section you’re in and a search box. Scroll up to see top headlines, slideshows, video and hot topics. Roll over a section name to see more from that section and click on a section name to go there.” Scroll. Roll. Click. Are they serious? Is it just me?

• No print preview. While this seems like a no-brainer, apparently Google decided it wasn’t needed. No public release of Chrome has had a print preview, although I hear version six is supposed to have it (fingers crossed).
• No Google toolbar. Really Google? You make the toolbar  and you make a browser, yet you don’t make the toolbar for the browser you make? I love your toolbar and its the only one I use.
• No sidebar for favorites or history.
• No way to quickly see an image’s properties. OK, this is a small one but to see an images dimensions or file size you have to either download the image or view it through the element inspector. Too much hassle for such a simple feature.

There may be extensions that solve my issues but I don’t want to use extensions for things that should be a part of the browser. I’m sure I missed a few features that other would like to see built into Chrome, so what is Chrome missing for you?

Moving on, today is the 30th anniversary of Pac-Man. Shit I feel old. I grew up on Pac-Man. Google acknowledged this by adding a sweet Pac-Man game to their generic home page so check out google.com (don’t use the personalized version) for an awesome JavaScript version of the game. Here’s a tip, hit “insert coin” twice to add ms. pac-man to the game and have two players clear the board.

Oh and in case you missed it, Google unveiled a sweet step forward in the web fonts arena with a simple way to use non-standard fonts in your site. Check out http://code.google.com/webfonts for the full run down and some examples. If you ask me, while this is cool and could be quite helpful, I still think that this whole web fonts thing is still too open ended. There are far too may way to try and get fonts to render properly in most browsers and all these solutions and workarounds just fee like they’re skirting the real issue which is being able to use any font on the web. The font foundries fear that they’ll lose money from designers and developers using fonts on sites and visitors being able to download them and then publish their own magazines with them without paying for them. The whole thing just feels kludgy and unnatural and that includes Google’s solution.  There’s got to be a better way.

var stickerTop = parseInt($('#sticker').offset().top);
$(window).scroll(function()
{
    $("#sticker").css((parseInt($(window).scrollTop())+parseInt($("#sticker").css('margin-top')) > stickerTop) ? {position:'fixed',top:'0px'} : {position:'relative'});
});

This snippet of code assumes that the block you want to make stick to the top of the browser window has the ID of “sticker”, but you can change it to whatever you like (and it doesn’t need to be a div). You could also expand the condition that checks the position of the window and the “stuck” element and apply a variety of other effects as well.

Here are a couple of basic demos. The first is just a bare bones example and the other uses a template from styleshout and applies the effect to the sidebar on the left. In my tests it works great in Chrome, Firefox, Opera, and IE.