There are three main steps to creating a customized share button. There’s some javascript to include in the footer.php, few lines of html to add at the end of your posts, and of course some styles and the icon itself.

JavaScript

You’ll want to add this js code in the footer file as probably the last piece of code. This means it won’t be loading until everything else is done. You can read detailed explanation of what you can do on AddThis’ API page but the short of it is — include this script file “http://s7.addthis.com/js/250/addthis_widget.js”. If you want to keep track of various stats AddThis provides, you’ll need to provide your username. This is done with the “addthis_config” variable. So for example, what I have is

<script type="text/javascript">
var addthis_config = { username:"2late2die", data_track_clickback:true };
</script>
<script type="text/javascript" src="http://s7.addthis.com/js/250/addthis_widget.js"></script>

HTML

The HTML is pretty much just a regular link, but with certain href target, class and a couple of special addthis attributes. You can style it anyway you want, as you would any other link. Here’s how said link might look

<a href="http://www.addthis.com/bookmark.php?v=250&amp;username=[username]"
  class="addthis_button" addthis:url="<?php the_permalink() ?>"
  addthis:title="<?php the_title_attribute() ?>">Share</a>

“http://www.addthis.com/bookmark.php?v=250&username=[your username here]” is the url the link should be pointing to. It must have the “addthis_button” class, otherwise AddThis js won’t recognize it, and then the addthis:url and addthis:title attributes. These attributes are self explanatory, just remember to use PHP so that they are assigned dynamic values. If you have any code, or plugins, that insert tags with attributes or class names into the title (like in my case, wp-typography, which puts <span class="caps"> around any caps-only words, like acronyms and such) then use the “the_title_attribute()” function, instead of the typical “the_title()”. It strips the tags and escapes any problematic characters.

CSS

This is really all up to you, depending on how you want to style the button and the tooltips with the various sites. By default the AddThis scripts provides its own style, so if you don’t mind the white tooltip box, all you’ll need to style is the link itself. If you want to style the tooltips as well, then you’ll need to dig into the generated code for them and the styles used by default, and figure out which ones you want to change. (You can check out my styles to see how I gave it a dark theme by switching a few colors.)

If you like optimizing your code you might decide to not include the AddThis styles file at all. You can do this by adding “ui_use_css:false” to “addthis_config”, i.e.

var addthis_config = { ui_use_css:false };

That CSS file weighs in at about 52k, which is actually quite hefty. There are, however, two reasons to keep, instead of removing it.
First of all, by removing it, you will have to provide all the styles to AddThis widget from scratch, as it were, including all those icons for the various services, which are backgrounds of the links, not image tags in the HTML. It’s certainly doable but it’s a hastle that might be not worth it at the end (depending on how anal you are about optimizing your code). The other reason is that, because AddThis is a fairly popular widget, many of your users are likely to have already downloaded that css file when they encountered the AddThis button on other sites. This means it’s cached in the browser and takes little to no time to download.

Now, as for that FB “like” button, looks like it might be tricky…

There are still a few features missing but I’ll be adding those in the upcoming weeks. Anyway, it’s back to our regular scheduled programming now.

Right now I’m finalizing an all new (and original) design for the blog; it’s gonna be minimalistic and dark. In the meantime I’m also redoing categories, cleaning up the tags and modifying small things here and there, as part of the preparations for the new design.

I recently had a few projects that needed this functionality, and while some of them had email, password and other fields that required validation, one needed just very simple text fields with placeholder text. So I wrote this very simple javascript function, using jQuery, to do just that (I’m using jQuery 1.4.2 here).

function setupPlaceholder(inputid) {
	if ($.browser.webkit) return false;

	var target = $('#'+inputid);
	if (target.length==0) {
		target = $('input[type="text"], input[type="email"], input[type="search"]');
	}

	target.each( function(i, el) {
		el = $(el);
		var ph = el.attr('placeholder');
		if (!ph) return true;

		el.addClass('placeholder');
		el.attr('value', ph);

		el.focus( function(e) {
			if( el.val()==ph ) {
				el.removeClass('placeholder');
				el.attr('value', '');
			}
		});

		el.blur( function(e) {
			if( $.trim(el.val())=='' ) {
				el.addClass('placeholder');
				el.attr('value', ph);
			}
		});
	});
}

The code is very straightforward. For one it checks that this is not a webkit browser, if it is I assume it supports placeholder attribute and so doesn’t need the code. Then it checks if an ID for the input was provided, just in case I wanted to do this on one field only. If there is no ID, or if it wasn’t found, it’ll simply apply to all inputs of type text, email or search (HTML5 input types).

When combined with some styles you end up with a nice input field with some “help” text, like this.

The one “catch” with this script is that I don’t check the case where a user would put the same text in as the placeholder text. If the user does this, then when they focus on the field again, the text will be erased (’cause the script thought it’s the placeholder text). To fix that you can add a flag that keeps track of whether the user has edited the field or not.

I’m not going to argue about fairness to developers who have invested time and money into, in many cases, perfectly legitimate apps, only to see them pulled down without any warning despite being approved in the first place. I’m not going to discuss the fact that there seems to be no clear guidelines or rules as to what constitutes an “offending” app, meaning that these can change at any moment to accommodate apple’s every whim. I’m not even going to mention that not a few months ago apple introduced the 17+ rating which is used to prevent the purchase of “adult” apps by kids, and which could be easily used to also filter out those apps from even showing up on the store pages unless age was verified. (Why Apple would not do that in the first place is beyond me, you’d think they have amateurs working there.)

I simply want to point out that a company (and more importantly, the man in charge of that company) that once prided itself on standing up to “the man” (Microsoft), is now doing things that are far worse than what “the man” ever did. Can you imagine for a second what would happen if MS started blocking software and applications from Windows because they were “from competitor”, or had “titillating images”, or “duplicated existing functionality”? Why, why are there people defending Apple?!?! The entire European Union got up in arms because MS bundled IE with Windows, yet we are allowing Apple absolute control over a product that WE bought and supposedly own. The iPhone (and in the future probably the iPad) is fast becoming the second “PC” for many. With one little difference of course — when you buy a PC desktop or laptop (even one with Mac OS) on it, you’re in control. You decide what software to install, and how to use it. With the iPhone you don’t — you can only do what Apple deems appropriate. I don’t know about you, but that scares me.

So what’s next? Will Apple be blocking Stanza and Classics when iPad comes out because they duplicate functionality of Apple’s bookstore? Will it pull down Evernote from the app store if it decides to extend the native note app to use the cloud. And what about Safari? Can’t help but bring up the fact that MS was forced to include a browser ballot screen and the European copy of windows (while never actually blocking anyone from installing other browsers), yet Apple gets away with not allowing any “browser” applications in the app store.

Of course the worst part of it all is that they get away with all of that — so many people have been blinded by the shiny iphone that as far as the average user is concerned it’s all perfectly fine. Only the bloggers and the techies actually speak out against this, and even then the opinions are split 50/50. All I can say is Double U. Tee. Eff!

Hopefully most uses of WebGL will be more sophisticated than that

WebGL itself is actually pretty hardcore in comparison to stuff like HTML and JavaScript. It’s a true, honest-to-god programming language. Which means that even simple things take a substantial amount of code. Heck, even initializing the damn thing takes a whole function. On the other hand, it’s also a very well established API (more specifically the OpenGL ES 2.0 API on which WebGL is based on) with plenty of resources, tutorials and websites that cover it from A to Z. So if you’re willing to roll up your sleeves and dig into it you’ll be making spinning cubes with blinking colours in no time.

For all the details and some example check out the WebKit blog.

So far the exact specs are unknown but it seems that the price is going to be $2,000, at least according to Business Week, via Engadget.

That’s not to say I have any illusions about rushing out and buying it the day it’s up on the shelves. But it’s interesting to see what kinda specs this baby will have (for that price they better be really good), and hopefully they’ll show Apple that you don’t have to gimp your laptop to make it thin and sleek.

That’s why I’m glad to see that at least some people are still trying to think outside the box. Like take R. Clayton Miller for example, who came up with the 10/GUI concept multi-touch interface for a desktop. The idea in a nutshell is to separate the multi-touch surface from the screen and put it on the table in front of the user, like a keyboard or a mouse.

Multi-touch control surface

Right away this is smart in two ways: 1) it uses a familiar control metaphor — controlling the UI on screen through controllers on the table, instead of directly on the screen; 2) it puts the control surface in a comfortable location and without obstructing the screen.

Taking the idea even further Miller comes up with a new “windowing” system for the desktop (which he calls con10uum) which takes advantage of the nature of the multi-touch control. Instead of arranging the windows on the screen in a random fashion, he puts them all in a line, think the alt+tab taks switcher but instead of small window previews you’re dealing with the actual program windows.

Con10uum multi-touch desktop

The idea of con10uum is to take advantage of the ability to use all your fingers for control. Ordinarily, having windows arranged in such a manner would make it cumbersome to browse them using a mouse and keyboard, but as is shown in the demo, with all your fingers at your fingertips zooming in and out, scrolling and opening new windows, and accessing the menus is quick and easy, once you learn the gestures. I also like the idea of global and local menu access by using different sides of the control surface.

It’s still just a concept but I hope it’ll be taken further and turned into a real product. There are a lot of awesome ideas here. There is one thing I would change about it though. I think putting the control surface in front of the keyboard, the way it’s done in the concept, isn’t ideal. Personally, I would like to see this replace the mouse. Instead of using a mouse, put the multi-touch surface to the right of the keyboard — that way you still have access to the keyboard as usual (instead of going over the control surface). Of course then this becomes a “5/gui” seeing how you’d be using only one hand on this surface. But that’s still 5 times more control pointers than the mouse.

You can read more about this on Miller’s site.

We’re working on exposing the multitouch data from the system to regular web pages through DOM Events, and all of these demos are built on top of that. … We have three new DOM events (MozTouchDown, MozTouchMove and MozTouchRelease), which are similar to mouse events, except that they have a new attribute called streamId that can uniquely identify the same finger being tracked in a series of MozTouch events.

They are also adding CSS support to allow styling for touch-enabled devices. However, strangely they’re using a pseudo-selector :-moz-system-metric(touch-enabled) instead of CSS media property. Then again, this is just the first draft, things are bound to change before this comes to a Firefox near you.

In any case, this some very cool stuff. Between Windows 7’s support for multi-touch, falling tablet prices, not to mention the rumored Apple tablet and the general surge of touch devices in the marketplace, it’s a great time to start adding some multitouch support to apps that never had it before and basically just playing around with them, seeing what we can do with them. After all, resizing and cropping images are fairly limited use cases, but when mainstream desktop apps (such as Firefox) have multitouch, plenty of people will come up with whole new ways to do familiar things, or just ways to do things we’ve never even thought of.

The idea is to set up tabs for Gmail and Google reader that will always be open, but with a few extensions will have minimal impact on the interface while providing the information relevant to each app (site). For a full guide see the link at the bottom, but here’s the gist of it.
Using the Better Gmail 2 add-on turn on unread count display in the favicon. Then get the Faviconize Tab and the PermaTabs Mod add-ons. The Faviconize add-on will add an option in the right-click menu of the tab to “Faviconize” it, i.e. remove the text and only leave the favicon visible. The PermaTab add-on gives you an option (right-click tab) to make a tab permanent. This will prevent it from accidently closing and will leave it on even after Firefox is closed (to close the tab you’ll need to “un-perma” it). And apparently permatabs don’t load their content until they’re first selected, in other words, this setup will not cause Firefox to load up 2 extra tabs every time you open it.

This is extremely useful. I check both gmail and reader multiple times a day but don’t like leaving them open all the time because the tabs take space, but with this I can have the best of both worlds.

[Original Lifehacker Post]