Neven was working from Portland and Alex and I from Chattanooga in the Tubatomic offices. (Trivia: The Tub offices are above an event space that hosted two proms during this event.) We used Dropbox to share files and Skype to bridge the two locations. (Did you know that on the iPad 3 video chat will drain the battery faster than USB can charge it? Neither did I.) We did very little preparation in advance of the theme annoucement. I made sure Flash Builder still worked and figured out how to import Tiled maps into Flixel.

As Neven said, “Flash, lol”. Why Flash instead of HTML5? My last two Ludum Dare games were HTML5 and the results were really lackluster. Zero to poor audio support, terrible mobile performance, and ugh, the choice between anti-aliasing or memory devouring in-canvas scaling. I’d rather create a good experience on one platform than a poor experience on many.

Like everyone else we got the theme “Tiny World” at 9 Eastern/6 Pacific on Friday night. While brainstorming we touched on Liliputians, Innerspace, and Alan Moore’s Voice of the Fire. We talked about the myriad things that can happen in small spaces, phonebooths, hotels, airplane cabins, and in our own heads. About small physical spaces observed over huge stretches of time. The idea of splitting yourself into smaller and smaller pieces and using the discarded pieces to progress.

An early narrative saw the player in a coma, wandering around inside his own head, piecing together the experiences that lead him to and eventually out of his current predicament. Was he a heroic fireman or a poisoned king? A victim of a drowning or a car accident? An astronaut knocked unconscious during reentry? We talked about additive level design where the entire game would play out in one room with each colected item filling in a narrative blank and adding more detail and new challenges to the game world. A player would control ego, super ego and id. The idea of an introspective totem pole eventually lead to the segmented gameplay mechanic.

While Neven pixelled the protagonist and Alex developed gameplay ideas and continued exploring narrative options I stumbled through loading tmx files. Within a couple hours we had the core dropping heads and using them as platforms mechanic working and were able to build and test levels quickly.

Things get blurry here. Collision resolution with a segmented character was really difficult to implement. Adding in enemies and spikes only complicated things. The stack height affects environmental collisions but the damageable hitbox doesn’t actually change size. Changing the player’s height caused Flixel’s camera to shift suddenly or pushed the player into the ground and out the bottom of the level. Once we introduced enemies the idea of activating the heads, one moving up, the other falling was developed. So now the heads had different collision states. For a while you could ride the rocket up the screen (or the planet down) but that ability neutered the challenge of the vertical platforming.

While I continued to debug and add features, Neven and Alex both designed levels to explore the gameplay possibilities. Occasionally Neven would create some new characters or animation sequences. Alex performed the unenviable task of building up a library of sound effects and serving as a second pair of eyes and lobes diagnosing bugs in the game. Early Sunday morning I composed a background theme and slept for the first time since Thursday night (I slept 11 hours total during the event which spanned 72 hours plus the 12 hours before we got the theme).

The final 24 hours were focused on polishing what we already had. Inserting sound effects, composing background music and goal fanfare, fixing bugs, refining enemy and projectile interaction, creating more bugs, setting up autotiling and implementing the parallax starfield. Alex figured out how to get cutscenes created in the Flash IDE into Flixel and built those out. Neven trimmed the level fat. We had a bit of a scare at zero hour when the Flash Builder release build wouldn’t load our external levels so we ended up posting the debug build.

Ludum Dare is always a rewarding experience. You have a deadline and a direction and 48 (or 72) hours to see where they take you. At the end of the weekend you have something that didn’t exist before. It’s simultaneously exhausting and rejuvenating. You can relive our experience and if you participated you can rate our game.

Levels come in four varieties: a single screen tall and wide (room), a single screen tall and multiple screens wide (corridor), a single screen wide and multiple screens tall (shaft), or multiple screens wide and tall (cavern). Like The Last Rocket the new game has an 8-bit aesthetic so a screen on an iPad is 256x192 pixels and 240x160 on an iPhone (both scaled squarely to exact device resolution).

Obviously, a single iPad screen won’t fit on an iPhone screen without the camera drifting vertically on corridors, horizontally on shafts, or both in rooms and caverns (vertical drift can be minimized with the use of a trap). The Last Rocket sidestepped the issue with single iPhone screen sized levels and a tile set that resolves to black so the unused area of the iPad screen is unnoticeable.

The solution I’ve decided on requires a slightly modified camera behavior and that some simple rules be observed when designing levels.

The camera still follows the trap (instead of the player character) but on the iPhone the camera is snapped to a special bounds rectangle—unless the player character moves beyond that rectangle. The bounds rectangle is four rows and two columns smaller than the level and offset by two rows and one column from origin.

Look familiar? On a single screen room, the relationship between the level and the bounds is the same as the relationship between the iPad and iPhone screens. So what happens when the player character moves beyond the bounds? The camera slides to its natural, unsnapped position using the player character’s current velocity (or a default value when stationary).

The level design considerations are easier to explain. To ensure that an edge is always visible on screen at the edges of a level, the top and bottom three rows and two columns on the left and right must be solid (with obvious exceptions for the doors that connect levels). I also block out some persistent space for the player’s thumbs (but not on screen buttons!). More on that in another post.

• Multi-line comments (syntax highlighting and keyboard shortcuts) cmd + opt + /
• Quickly change language to mml (shows in the list of other languages that use this shortcut too) ctrl + shift + opt + m
• Easier to read ruby in bundle scripts (string interpolation)
• Better cleanup. In some cases .h files were still hanging around.
• When compiling fails you’ll know! Shows in a textmate tooltip. (no more guessing if something worked)

Thanks Matt!

Download the updated bundle.

Leslie and I arrived in Austin yesterday for our seventh SXSW. We use to take a taxi from the airport until we discovered the $1 Capital Metro bus a few years go. This year I did something unbelievably stupid: I forgot my laptop bag on the bus.

We got off at 4th and Congress and walked about a block before I realized what I had done. I immediately broke into a sprint in the direction I thought the bus was headed (it was already out of sight). Hands on my head, muttering, “Oh fuck, oh fuck, oh fuck”, I clopped along in my flip-flops for about a block before whipping them off for more speed. I dashed down every cross street, trying to desperately to pull up my mental map of downtown Austin (you don’t so much navigate Austin at SXSW as you do flock).

As I reached the borders of that map I almost ran past the bus at a stop light. I manically banged on the bus door, hoping the driver would recognize me from exiting minutes earlier and not mistake me for some deranged, barefoot maniac (though he wouldn’t have been too far off). Fortunately my laptop bag was still aboard, having slid out of sight, under the seat I had occupied.

I am fortunate I was able to intercept the bus before it continued on its way. In the laptop bag was my laptop, my iPad, my DS Lite and a handful of games, our house keys, our sole car key and clicker, and my antibiotics for the obligatory South By Sinus Infection.

There are so many different ways this story could have ended. If we had taken a taxi I might have never seen the bag again. My barefoot sprint could have ended in stitches (there seems to be broken glass everywhere here), or worse, hit by a car or the very bus I was frantically searching for. If Leslie wasn’t with me I would have had to choose between abandoning my luggage or my livelihood (so long luggage!). I feel bad for all the quantum Shaun’s that made it this far only to suffer one of these other, less fortunate fates. Sorry guys.

tl;dr

Ever wonder why links you find via Twitter don’t show up in your browser history and aren’t suggested by autocomplete in the url bar? The t.co link shortener serves known browser user agents an HTML page containing a JavaScript or meta refresh redirect (instead of the standard Location header) so that Twitter can stake itself out as the referrer when coming from third-party clients. This confuses Safari.

Stats are cool and all but only when they don’t break the experience for your users.

Download Detox.

(Zackary Corbett made a Chrome version too, which may or may not be necessary. Firefox and Opera also appear to be unaffected.)

Detox 1.1

Now when you hit a t.co redirect page (from a native client or a direct message from Mail.app) the destination url is added to the document title making the destination url appear in your history and url autocomplete suggestions.

Detox 1.2

Added code submitted by Orangenhain that fixes a similar history-breaking problem on Google’s search results.

Detox 1.2.1

Recently Twitter updated their link expansion data attributes. Previously the expanded url could be found in each link’s data-expanded-url attribute. A recent update duplicates the t.co url in data-expanded-url and puts the true url in data-ultimate-url.

Detox 1.2.2

Digging deeper it appears that data-ultimate-url contains the terminal for twice (or more) shortened urls (eg. a t.co’d bit.ly pointing to the terminal google.com). Detox 1.2.2 Uses data-ultimate-url if available, falling back on the original data-expanded-url. data-expanded-url containing the t.co instead of the expanded url may have just been a temporary Twitter bug. I regret jumping to conclusions but with twice shortened urls the user never sees the intermediate url which is what ultimately lead to the confusion.

• The Last Rocket Though not released until mid-August I started work on what I consider to be my first proper game in early January. The development of this game, more than anything else, shaped the past year. It was critically well received, responsible for a quarter of the year’s income, and even made Edge, Touch Arcade and iPhone Alley’s year end lists.
• Unplayed I’d been privately maintaining a list of games I’ve played or want to play since getting a DS Lite in June of 2006. After briefly dabbling with a Tumblr to maintain the list I wrote this trifle of a web app.
• Breathing Room My first Ludum Dare. Also, an early study from my thinking about level design.
• CSSFrag A Safari extension for targeting specific DOM elements by url. Passed the torch to Pinpoint.
• Reply Reach & Past @s Two little JavaScript bookmarklets for use on Twitter.com.
• Data Entry Sentry My second Ludum Dare and my first attempts at a JavaScript/Canvas game. The genesis of the JavaScript port of the Objective-C framework I use for all of my iOS games, SI2d.
• Day-O A simple menubar calendar replacement for OS X.
• Chunks A native iOS port of my second Ludum Dare game, Data Entry Sentry. I didn’t promote this as much as I probably should have but a more vocal release might have set expectations too high for this modest little falling block game.
• Sinkhole My third Ludum Dare. A tense little exploration game that I’m still actively developing. SI2d.js was updated significantly for this game. I even ported it from Canvas to DOM sprites to compare performance (pretty much head to head by the numbers but the Canvas version feels smoother in play and is easier to extend).
• The Last Rocket Suite The soundtrack from The Last Rocket did pretty well too so I released this string quartet version of three themes from the game.

In addition to these wholly new things, I also released a bunch of updates to Mint and its Pepper, Fever, Shortwave, Lessn and NoiseES. I’m also about a month or two into another all new 8-bit iOS game, inspired as much by Metroid and Super Mario Bros 2/Doki Doki Panic as it is by Studio Ghibli’s films.

All in all, a very productive year.

This past weekend I participated in my third Ludum Dare. I created an HTML5 game called Sinkhole from scratch in 48 hours. It was an awesome experience and the game didn’t turn out half bad either. Last time I had just launched The Last Rocket. This time I had just launched Chunks, a native port of my previous Ludum Dare creation.

The theme this time around was Alone. Unlike the previous two Dares where I came up with three ideas and then slept on them before starting, this time I had an idea I was really excited about and after only half an hour set to work.

The first three lines of my notes from that first night read:

• top-down
• exploration by flashlight
• something moving in the darkness

I wanted there to be an urgency to the exploration. I wanted the antagonists, the stalkers, to be unseen. Let the players’ imagination do the heavy lifting.

I also knew I didn’t want to have to worry about level design so after bootstrapping the JavaScript framework I cobbled together for the last Ludum Dare I started researching cellular automata and pathfinding so I could dynamically generate solvable maps to use. I managed to get the skeleton of a solution working (ported from C to JavaScript) before bed the first night.

While falling asleep I started imagining the stalkers’ behavior. After a short delay a stalker appears and attempts to sneak up behind the player. Facing the stalker causes them to freeze. Shining a light on them causes them to flee. But every time one flees another, slightly faster, stalker spawns. The player solves their current problem at the cost of future safety. More impetus to find the exit quickly.

In addition to the unseen threat of the stalkers, the player’s defensive and discovery tool, light, is limited. The flashlight’s batteries drain in one minute. Matches burn out after 3 seconds. It takes time to load a new battery or strike a match. During that time visibility is nil. Or rather, you can see the stalkers approach but not the player or the walls of the level. Once the player runs out of light sources and their eyes adjust only slivers of walls are visible on the periphery of their limited cone of vision. The player must rely on these subtle hints and the minimap to find another battery or matchbook to buy them some more time to find the exit.

I eventually fell asleep.

I woke up to the realization that I had attempted (and abandoned) a very similar mechanic during my first Ludum Dare (the original Chibi Pan & Pup idea).

Shaking off the thought of repeat failure I quickly implemented a TileMap class in SI2d.js and a way to crop the viewport allowing the “camera” to follow the player as they moved across the map. I revisted the touch-based controls then created some rough graphic masks to start implementing the different sized beams of light that define the gameplay. Minimaps came quickly. Around this time I realized that the framerate wasn’t going to be acceptable on the iPad and implemented keyboard controls as well.

Power-ups, a compass to reveal the exit on the minimap, batteries and matchbooks to recharge your light supply slotted in pretty easily. Stalkers gave me a bit of trouble initially. They needed to spawn outside of the players cone of vision or else they would flee immediately.

The story arrived in the form of four tweets that became the prologue:

Tomo the Cartographer was on a routine survey mission in Central America when the earth opened up and swallowed him whole.

Miraculously, he survived falling hundreds of feet and walked away with only a broken arm.

Guide Tomo out of the sinkhole before he runs out of flashlight batteries or burns through all his matches.

It will be a lonely climb back to the surface. At least, Tomo thinks he’s alone. He hopes he’s alone.

Around midnight the second and final night I started on the artwork. Like all of my games to date I limited my palette to only colors the NES was capable of producing. Tomo came together quickly, based largely on the Link sprite from the original Zelda (with a strong Mega Man influence). I used Mario from SMB3 as a referene when drawing his vine climbing animation. I had to redraw the power-ups and background tiles a few times but I eventually arrived at something I was happy with. I had a lot of fun creating the onomatopoeia bursts that represent the stalkers.

The remainder of the last day is a disjointed blur. Lots of revisions to stalker behavior. Persisting inventory between levels. In a remarkable moment of clarity I coded, from memory, in one go, an error-free JavaScript port of my Objective-C TextMap class. This allowed me to get some of Tomo’s internal dialog on-screen while playing.

The title screen graphic was a happy accident. While trying to draw grass hanging over the edge at the top of the sinkhole I accidentally turned off (or on) another layer producing the masked out, moss-clinging-to-the-sides effect you see in the finished artwork.

By the end of it all I couldn’t see straight, my own eyes were anti-aliasing the pixel art I had slaved over. But it was totally worth it. It’s creatively rejuvenating, knowing that you just created something, non-negligible, largely from scratch, in just 48 hours. If you participated in Ludum Dare, please play and rate my entry (I’d love any feedback you have as well)!

I’ve been continuing to develop the game in the days since submitting. Improving collision detection, softening cornering, improving keyboard responsiveness, adding Gamepad API support, refining power-up frequency and distribution, tuning stalker behavior. Maps no longer regenerate every time you die. The minimap remembers previously explored areas. Inventory reverts to its unique pre-level state rather than resetting completely. Play the updated version of Sinkhole. Who knows, maybe someday there will be an expanded native iOS version.

Later tonight or early tomorrow I’ll have a new game in the App Store. (For real this time. Last week Horror Vacui 2 showed up on a number of App Store new release lists for no apparent reason despite being released over a year ago.) It’s a small game with more in common with Horror Vacui than The Last Rocket. And it might look familiar.

Chunks is a native iOS port of my most recent Ludum Dare game Escape! Data Entry Sentry. The core gameplay mechanic and most of the graphics were created over a 48 hour period shortly after releasing The Last Rocket. While I’ve been working on a new, more ambitious 8-bit platformer for iOS (somewhere between The Last Rocket and the unreleased Mimeo and the Kleptopus King in scale) I’ve also made time to rename and refine Chunks for a proper release.

In addition to some gameplay tweaks and instructional UI, I composed three new chiptunes, a short game over jingle plus a handful of sound effects. The themes were inspired by falling block giants Tetris and Dr. Mario (with a little The Guardian Legend thrown in for good measure). The tempo of the background music increases with the speed of the conveyor as you play. This change is imperceptible from level to level but after a while you really start to feel the frantic increase in momentum. Grab the NSFe and give it a listen in NoiseES.

Chunks is a universal app so you can play on your iPhone, iPod touch or iPad and includes Game Center leader boards for high score and highest level. It’s a small game with humble origins so it’s only a buck. Check it out tomorrow!

Day-O is a simple menu bar clock replacement with a simple calendar for your Mac. It’s free, as-is (which means I’m not providing support, taking feature requests, addressing perceived inadequacies or releasing the source code). Here’s how it came to be:

My late upgrade to Lion was relatively painless. The only casualty was MenuCalendarClock. It somehow clobbers the Dictionary shortcut key command and gesture which I use daily (if not hourly). I thought I could live without MMC. I don’t use any calendar apps so I was just using the free version for the simple date icon and convenient fly-out calendar. I thought the system menu clock would suffice. Really, how frequently did I use the fly-out calendar?

Turns out, quite a bit. I tried a few replacements but couldn’t stand any of their date icons. MMC developer Objectpark seems to have gone quiet. Fortunately, as I quipped on Twitter, I’ve “never met a wheel I didn’t want to reinvent.”

I was able to piece something together from various NSStatusItem tutorials, the NSDatePicker Class Reference, Stack Overflow answers and GitHub repositories.

I may or may not have had this YouTube video on repeat in the background the entire time.

Download Day-O.

Drag this Past @s link to your bookmarks bar. Then the next time this happens select the tweet and click the bookmarklet to perform a quick Twitter search for recent tweets from this person to you.

Think that’s useful? You might also like my Reply Reach bookmarklet.

function chance(x, y)
{
    // return Math.ceil(Math.random() * y) <= x;
    return Math.random() <= x/y;
};

Which in my testing behaves as intended. chance(1, 32); has an approximately 3% chance of returning true. chance(99, 100); has an approximately 99% chance of returning true.

Hopefully this will save someone else some unnecessary head-scratching.

Update K.M. points out that Math.random() returns a number between 0 (inclusive) and 1 (exclusive) so the Math.ceil() is unnecessary.

I’m increasingly of the opinion that onscreen buttons are not the way forward. Overlays are a poor substitute for a physical d-pad or buttons; it’s too easy for fingers to drift while attention is focused elsewhere onscreen or to obstruct immediate threats to the player resulting in unfair deaths.

They create the expectation of familiar behaviors that they can’t deliver. When you use a gamepad your fingers don’t hover over the buttons waiting to touch each individually. Your thumbs rest on the buttons, then depress and/or pivot to adjacent buttons as needed. On a touch screen it is impossible to distinguish between a resting touch and a touch with intention. (Hold and slide might effectively simulate an analog stick but I’m primarily interested in 2D games where an analog stick offers little benefit.)

Deferred Gratification

If an action is triggered immediately at the beginning of a touch (the press) that’s the only action that touch can trigger leaving you to rely on separate onscreen buttons to provide multiple distinct actions. But, if you delay triggering the primary action to the release, a single touch can be overloaded with at least three distinct actions.

In The Last Rocket, the press triggers a crouching state. From there the player can release to launch (like releasing a spring) or swipe to step in the direction of the swipe. Three distinct actions, zero buttons. While airborne, the press prepares to land in a crouching state, release reverses direction, and when snared by a fan or vent, a swipe chooses a direction. Again, three distinct actions, no buttons.

If Flip launched or reversed on the press then additional onscreen buttons would be required to support the additional actions. This new approach may at first seem contrary to past experience with gamepads and their physical buttons but is intuitive and easily grasped in the new context of a touch screen.

Potential Application

I can imagine a fairly traditional platformer that uses this buttonless approach (there may already be one, I’m not the most voracious iOS gamer): The screen is split down the middle into two equal, invisible regions representing left and right. A press starts the character running in one direction or the other, depeding on which side of the screen is touched (which the player intuitively understands as run towards the touch). A release triggers a jump that maintains the previous forward momentum. A quick tap from a standstill would be a straight jump up. A release after a period of running would be a leap forward. Maybe another touch on the same side cancels vertical momentum, limiting the height of the jump (which the player intuitively understands as the duration their finger is off the screen). A tap in the opposite direction could cease forward momentum without triggering a forward jump.

Definitely something I plan to explore further after submitting The Last Rocket 1.1 to the App Store and porting Data Entry Sentry to iOS.

This time the theme was Escape!. Like last time I came up with three ideas and slept on them before starting any work:

• Farmbreak!: You place obstacles to prevent animals from escaping their pens. Different animals have different abilities (ram, jump, burrow, fly) and each requires a different type of barrier to contain. Yawn.
• Escape from Zombie Hall: Sort of a Space Invaders/Smash TV mashup. A first-year dorm resident of Zombinski Hall is trapped in a zombie outbreak. In the first part of each stage the player moves left and right blasting back the oncoming zombie horde with a shotgun (Space Invaders). One zombie is holding the key to the exit which is behind the player. When that zombie is blasted the key pops out and the player must rush in with a 360 chainsaw attack (Smash TV), collect the key and make it back to the exit in one piece. The only thing less inventive than a clone plus zombies is a clone plus ninjas.
• Data Entry Sentry: Can you make a game about escaping data? Can you make it fun? You can certainly try. Chunks of data slide down multiple conveyors towards a parser and buffer. Some of the data chunks are gremlins. If a gremlin hits the parser it eats all the data between it and its pair. The goal is to fill the buffer without overflowing.

Waking up Saturday morning, Data Entry Sentry seemed the most interesting, unique option. So where do I start? For my first Ludum Dare entry, Breathing Room, I used Flixel. I’m really not a fan of keyboard and mouse games and really enjoyed the simplicity of tapping in The Last Rocket. I wanted to make a game that I could play on the iPad. So Flash was out.

After doing some quick research on HMTL5 game engines I decide to roll my own. Using John Resig’s Simple JavaScript Inheritance I put together a streamlined JavaScript approximation of the iOS framework I used for Horror Vacui 2 and The Last Rocket.

The framework is pretty simple (view source on the game). The primary class is Surface which can have a parent and children Surfaces, has a rectangle for size and position and knows how to render and update itself. Surface is meant to be extended but is also useful for grouping elements at a given zIndex. The GameSystem class extends Surface and is responsible for creating the canvas element and is used as the System singleton so that the Texture and Rectangle classes can draw to the screen. An InputManager class is used by other objects to register to receive input events. Everything else extends Surface. State automatically takes the dimensions defined when initializing GameSystem. Rectangle draws colored rectangles. Tile draws individual tiles in a tilesheet. Wallpaper repeats a single image. SurfaceY is just a Surface that sorts (and renders) its children by y coordinate instead of zIndex.

By the end of the first day I had an ugly, playable prototype. By noon on Sunday I had a design and simple animations I was happy with:

One of the trickier elements of the design was the level numbers. Because of the perspective, the tens and ones columns require two different sets of numbers. I created a special LevelNumber class to properly render the text from a tilesheet containing numbers drawn in both perspectives.

The remainder of Sunday was spent rewriting PlayState to use the new Chunk class and integrate the graphics and complicated zIndexing and stacking behavior. The bulk of the game logic lives in the PlayState update method. Chunks, a subclass of Surface, are moved between different Surfaces (conveyor, stack, Chomplies and dying) and behave differently depending on which Surface they inhabit. Initially this was done as an easy way to manage Chunk zIndexes but ended up being really useful for implementing the behaviors unique to each section of the game board.

As an aside, in The Last Rocket, instead of subclassing subclasses of Surfaces and adding behavior I have an Entity class (which has a little less overhead than a Surface) that has one or more Surfaces. States then iterate over entities which are responsible for the behavior of their Surfaces.

If I had more time I would have liked to create some 8-bit tunes and sound effects to complement the graphics but HTML5 audio still seems to be a tricky proposition on iOS.

Ultimately, Ludum Dare was, again, a rewarding experience. Maybe once The Last Rocket and NoiseES updates are done I’ll port Data Entry Sentry back to iOS and finish it up properly.

The Last Rocket has been approved and is available now on the App Store! Check out the site for the trailer, some iOS wallpapers and, if you still have Flash Player installed, a preview of the music.

Yesterday I twondered if there had been any developments in the browser space regarding linking directly to arbitrary elements. I wanted to link to a specific section of a page on a site I don’t maintain but that the author hadn’t anticipated linking to. The solution I proposed was a jQuery-like syntax for a normal CSS selector added to a url as part of the hash.

Then Eric Meyer pointed me to this proposal for Using CSS Selectors as Fragment Identifiers (co-authored by Simon St.Laurent).

Almost exactly what I was looking for but still just a proposal. So I put together a simple Safari Extension called CSSFrag that implements #css() selectors in url fragments (sans fallbacks). Then Laurian Gridinoc ported it to Firefox as a restartless extension (source). And then Lim Chee Aun ported it to a Chrome extension (source). Later, David Hasather ported it to an Opera extension (source). Progress!

Download CSSFrag for Safari, Firefox, or Chrome. Here’s an sample link to try once installed: Daniel Brown’s excellent Metroid Piano covers. (Note that attribute selector values must be quoted as well as URI encoded). The best part is that even if you don’t have the extension installed the link still works.

Author-designed versus User-designed urls

CSSFrags are not meant to replace more concise, author-designed urls. CSSFrags enable a site’s users to address specific sub-content that the site’s author may not have anticipated as being interesting. Think about user stylesheets and how they afford another layer of control above author-designed stylesheets. This was also the intention of the original proposal.

Caveats

Like normal fragment identifiers, CSSFrags may not be able to jump to an anchored element if the page is modified by JavaScript that causes the document to reflow or otherwise modifies attributes. Not sure if there’s a sensible solution to that problem.

Because CSSFrags might rely on content or specific document structure they are considerably more volatile than “normal” links. But, unlike a traditional broken link where a 404 results in missing content, a broken or unsupported CSSFrag only results in a loss of context, leaving the user to manually find the relevant element.

When I’m writing an @reply, it would be cool to know how many of my friends would be seeing it in their feeds.

Which reminded me of Eric Meyer’s Followerlap. So for my morning mental calisthenics I whipped up a simple JavaScript bookmark that allows you to check your reply reach before hitting the Tweet button.

Just drag this Reply Reach link to your bookmarks bar and give it a click the next time you hit that reply link.