Since our last installment in February 2010, it seems that the Google Maps API has shifted yet again and bricked our demo. No worries. Thanks to some great detective work by @Chris, we can get the old code up-and-running again by adding “optimized:false” to our Maps API Marker options. This will prevent Google from optimizing (encoding) the Marker image and allow the Marker to be rendered as an image tag as it did in our first demo. Therefore we can revert to our original CSS selector and call it a day.

But why leave it at that? Let’s take this to the next level and tweak that pulsating marker so it looks even more realistic.

Blue dot special

First off, let’s start with a fresh new marker—one that just encompasses that blue aqua icon at the center of the pulsating ring. I basically just recreated the blue iPhone Maps location icon in Fireworks and exported it as a PNG with alpha transparency. After uploading the image to the server, I also updated the Marker options to reflect the new file name and image size (17px square).

Great rings of Neptune, Batman!

Next up, the pulsating ring. Back in April 2010, Zachary Johnson posted a piece on Pure CSS Map Markers that inspired me to go 100% CSS on the rings. It just took me this long to get around to it.

To start, we’ll make a circle out of a square div by adding mega border-radius to it. In our case, we’ll have a 51px square (three times the blue icon’s height/width) with border-radius set to 51px as well. Now that we have our circle, let’s style it to look more like that iPhone Maps ring. Look closely at that ring and notice that its not a blue ring but a white ring with blue blurring the edges. We can achieve that effect by adding a 1px solid white border to our circle and then—and here’s the magic—applying multiple layers of blue inner and outer box-shadows in the same CSS declaration.

box-shadow:
  inset 0 0 5px #06f,
  inset 0 0 5px #06f,
  inset 0 0 5px #06f,
  0 0 5px #06f,
  0 0 5px #06f,
  0 0 5px #06f;

Who knew you could do such a thing? I didn’t, until I tried it. The ability to use standard drop shadows and inset shadows in the same declaration is amazing enough, but that you can layer them to achieve deeper color (as you would in Photoshop with multiply layers) is astonishing. And we’ll need this color depth when we animate our ring. Without this color depth, the blue would appear too faint as its opacity drops to zero.

So, all that remains in our styling exercise is to animate our awesome ring. Going back to our keyframes, let’s start from an initial scale of 25% and opacity of 100%. Then let’s progress at the 95% mark to 130% scaling and 0% opacity. And lastly, let’s return to scale of 25% with the 0% opacity to reset everything for the next iteration. That’s pretty much it—aside from some refactoring to take advantage of animation shorthand and the addition of Mozilla’s CSS prefix,

Okidoki. So we have our new blue icon marker and we have a new pulsating ring, but they’re not connected. We need to dig into the Google Maps DOM and grab our marker’s wrapper element to apply the ring styling (so that the ring will pulsate out from the marker image). Fortunately, there’s a div that surrounds our marker image that meets our needs. Curiously, there are actually two almost identical div/marker-img combos to play with. We can actually sacrifice one for our sneaky purposes. The second combo has a div with the Marker title we added in the options so we can conveniently use that as our ring’s CSS selector. Yay! But since that div is scaling up and down, the inner bluedot.png img tag scales up and down too, which isn’t what we want. No problemo! Display:none that image and let the first set’s bluedot image shine through.

Add a few more margin tweaks for high DPI devices and we’re done styling our realistic pulsating marker. Check it out on the demo page.

Am I really here?

Commenter @John also mentioned some issues with geolocation accuracy thay @Ziyad was kind enough to address. Since we’re already under the hood, let’s roll those modifications into our code as well.

navigator.geolocation.watchPosition( 
  displayLocation,
  handleError,
  { 
    enableHighAccuracy: true, 
    maximumAge: 30000, 
    timeout: 27000 
  }
);

Wait, what version is this?

This demo has had a history of API version issues so it comes as some relief to find Google providing support for versioning. I’m not sure if this is a recent development, but you can actually specify the Maps API version that your code works with. So now when our code breaks, just go back and request the API script version that was running back when things were good.

http://maps.googleapis.com/maps/api/js?v=3.4&sensor=true_or_false

Git it while it’s hot!

Speaking of versioning, the code for this demo is now up on GitHub. Go grab it from there, fork it, enjoy.

demo code

My client’s site was already using Mark Huot’s Simple Translator extension to provide multi-language capability so, for every weblog entry, we needed to create a custom field for each language (with the language’s suffix appended—e.g., body, body_es, body_pg). All was fine until I came across an interesting bugaboo presented by the LG Polls module (another beautiful piece of work from Leevi Graham). The module handled multiple custom fields for the poll question just fine, but for the poll details (the answers) there was to be none of that.

Fortunately, the client agreed to a rather unorthodox solution: rather than creating three custom fields, we’d use just one custom field with three fields piped inside—e.g., “English answer|Spanish answer|Portuguese answer”. Then in the template, we’d insert the PipeBomb plugin where we needed to parse those fields. In the following example, we switch between the three language responses based upon a match from EE’s “lang” cookie:

{poll_answers}
<li class='a-{answer_count}'>
	<label for="lg-polls-answer-{answer_id}">{answer_input} <span class="answer">{exp:pipebomb switch="lang" switch_type="cookie" cases="_es_pg" values="{answer}"}</span></label>
</li>
{/poll_answers}

Of course, this plugin has more uses:

{exp:pipebomb switch="{dynamic_variable}" cases="1234" values="Number OneNumber TwoNumber ThreeNumber Four"}

And if you want to get really creative, you can loop and pipe a whole HTML fragment between categories tags:

{exp:pipebomb switch="{simple_language}" cases="EnglishEspañolPortuguês" values="{categories backspace='1'}<h3><a href='{path='articles'}'>{category_name}</a></h3>{/categories}"}

For the curious, the PipeBomb name evolved from the way it works under the covers: it basically explodes piped values and plucks those values out of the array for display based upon the switch/case parameters.

NOTE: Just as I went to publish, I noticed that a very similar plugin called Switchee was recently released. I believe the two plugins are suitably different to coexist. PipeBomb is a small, crude device meant for quick, dirty jobs whereas Switchee is more of an industrial-strength switch/case utility.

Download PipeBomb

When Google updated their Maps JavaScript API V3 last summer, they apparently did a bit more than change the way our iPhone map marker image was displayed (now as a background image rather than an image element). When I noticed the API change, I modified the CSS selector to hunt down the new marker: #map_canvas div[style*="blue_dot_circle.png"]. This allowed us to apply the CSS animation to the marker easily enough but it created another problem.

Since Google also inserted a phantom layer for the cursor pointer and title attribute that shares the same image background as our target marker, our new CSS selector actually applies animations to 2 markers; including one not normally seen because its opacity is set to 0.01. Worse yet, the primary marker seems to be shifted off the phantom marker by -10px top and left—but only on mobile Safari (the markers are centered just fine in Firefox 3.6 as you can see in the Firebug screenshot above). This created the ungainly double pulsing markers that some of you noted in the comments.

To kill the phantom, I tried a few parameter changes in the Maps script but nothing seems to stop the phantom (by the way, it’s not a shadow—I already turned those off). So it seems the only recourse is to de-animate the phantom marker layer with another CSS hack. Remember that the phantom layer that had the cursor and title attribute in it? We can use one of those attributes in another selector to isolate the phantom and remove the animation: #map_canvas div[title="I might be here"] {-webkit-animation-name: '';} (just make sure you match the title in this selector with the title you provide in the Maps script). We can use that information to enhance our selector to exclude the phantom layer (the one with a title attribute) from the animation with a little negation pseudo-class action: #map_canvas div[style*="blue_dot_circle.png"]:not([title]) (for more info on CSS selectors, check out Taming Advanced CSS Selectors).

Here’s the new complete CSS stylesheet for our Map app:

@-webkit-keyframes pulse {
  0% {
    opacity: 1.0;
    -webkit-transform: scale(1.05);
  }
  40% {
    opacity: 0.25;
    -webkit-transform: scale(0.85);
  }
  100% {
    opacity: 1.0;
    -webkit-transform: scale(1.05);
  }
}
#map_canvas div[style*="blue_dot_circle.png"]:not([title]) {
  -webkit-animation-name: pulse;
  -webkit-animation-duration: 2s;
  -webkit-animation-iteration-count: infinite;
  -webkit-animation-timing-function: ease-in-out;
}

Note that I also added scaling to our pulse transformations in this round of edits to swell and shrink the circle just as in the native iPhone map app.

As always, thanks for your comments and please let me know if you’ve found a better way to rid the phantom marker.

Austin GeekNite Info actually started as a simple spreadsheet of the local web groups I regularly attended and their typical meeting nights. But since I’d also like to know what’s going on in other communities (and my wife would like to know where I think I’m going) I started looking at ways to automate the process of adding events to a calendar.

As luck would have it, Google Calendar provides the means to add iCal feeds from other sites to your calendar AND share this newly aggregated event calendar with others. Nice. The wife will be happy. By why stop there? Overwhelmed by the spirit of the season, I grabbed the geeknite.info domain and prepared a simple calendar page to share with the rest of Austin.

Initial release

Adding and editing iCal feeds in Google Calendar can get a bit unwieldy so this first version of GeekNite applies Tony Hirst’s Delicious Pipes solution for managing iCal feeds. It’s a pretty slick fix for getting around Google Calendar’s limitations.

Basically, we’re manually collecting iCal feeds from around the Austin tech community on Delicious.com. We then massage the RSS feed from that Delicious list into an iCal feed with Yahoo! Pipes. Google Calendar happily chomps on that iCal feed and spits out a pretty calendar that can be embedded in any HTML page with a snippet of iframe code.

We end up with a decent calendar that can be viewed in a few different ways (weekly, monthly, agenda). Clicking on an event brings up a bubble with more details and a link to add the event to your own calendar. Nothing too fancy, but useful.

Next steps

• I had to manually enter some dates (e.g, Ignite Austin). That’s something that I’d like to get around in future iterations. It’s 2010 folks and time for y’all to add semantic mojo (in the form of iCal or vCalendar microformats) to your sites. Perhaps that’ll be one of my base requirements: iCal or no-cal.
• The whole Delicious Pipes layer is a temporary hack to get this rolling. I’m guessing there’s a way to sniff out all the local web event iCal feeds sans spam/noise but I just haven’t looked into it that much yet.
• As long as I’m at it, I’d like to break from Google Calendar as well. It’s a nice starting point and all, but much too limiting. I’d like to customize the results a bit more to include more information (e.g., group size, number of past meetings) and to format for iPhones and such.

So there it is, Austin.GeekNite.Info. Let me know what you think and how we can improve this little app.

Update

Shortly after I wrote this, Judd Lyon told me about a couple of other Austin web tech calendars already out in the wild: GarysGuide and Door64 (I really need to check with him before embarking on new projects).

Update [October 31, 2011]

See Here We Are Again for the latest update in this saga!

Since Apple announced the iPhone OS 3.0 update at WWDC a few weeks ago, I’ve been eagerly anticipating the addition of location services to Safari (Webkit).

Until now, providing an iPhone 3G user with a map and an indicator of their current position required building a native iPhone application in Objective-C and getting approval from Apple to distribute said app via the App Store. Not fun.

Well now that OS 3.0 is out, we can take advantage of Safari’s newly baked-in geolocation services and some other niceness to do the very same thing. (jump to the map)

Native Geolocation

Safari now gives us navigator.geolocation from the W3C Geolocation API Draft Spec and all the magic that goes with it: getCurrentPosition (one time retrieval of location), watchPosition (continuously updated location), and clearWatch (stop watchPosition). (If you’re browsing with iPhone, Android, or Firefox 3.5 right now, take a peak at your raw geolocation info.)

We want the location marker to follow us around, so we’ll choose watchPosition. The following provides the basic format we’ll follow, though the final code will be different as we add the Google Maps juice:

function displayLocation(position){
  var latitude = position.coords.latitude
  var longitude = position.coords.longitude
  // do something with this new information
}
 
function handleError(error){
  switch (error.code){
    case error.PERMISSION_DENIED:
      alert('Sorry. Permission to find your location has been denied.')
      break
    case error.POSITION_UNAVAILABLE:
      alert('Sorry. Position unavailable.')
      break
    default:
      alert(error.code)
  }
}
 
navigator.geolocation.watchPosition(displayLocation, handleError)

When this code is run in an iPhone 3G with OS 3.0, the browser asks for permission to use your location. If permission is granted, the displayLocation function is called; if not, the handleError function is called. Now let’s do something useful with this location information.

Google Maps

Google Maps released a welcome upgrade to their mapping API this past spring. With the still developing API v3, they tossed out the API key, rewrote the code, improved the namespacing, and much more. In the interest of playing with all things new, we’ll use this version of Google Maps. And in the interesting of keeping the focus on the new geolocation shizzle, we’ll skip the in-depth Google Maps discussion and just cover some abstract goals.

Initially we’ll center the map somewhere in downtown Austin, Texas. Then, when our previously mentioned displayLocation function gets called, we’ll add a marker and re-center the map on that marker—just like the big kids do with their fancy native apps.

Inside displayLocation, we’ll create the marker just once and then update its position on subsequent calls. Every time the iPhone changes location, the marker moves to follow. (extra credit: if you want to create a breadcrumb trail, take out the if/else stuff to create a trail of new markers on each iteration)

Lastly, we add an onload attribute to the body element to invoke our geolocation and Google Maps magic after the page loads. We now have a cool mobile map that tracks your position as you’re moving.

CSS3 Animation

We could certainly stop here and pat ourselves on the back, but let’s apply one last bit of polish. If you look at the native iPhone Map app, you’ll notice that the blue location icon pulses in and out to keep your attention. Hmmm. Our current location marker is lovely PNG image with alpha transparency that smoothly overlays the background map but it doesn’t pulse. Unfortunately, we can’t animate PNGs. We could fade the image in and out with some more JavaScript coding, but let’s take a look at a better solution, compliments of the new Safari.

When the CSS animation draft was announced, it sounded rather odd to add behaviors (JavaScript’s forté) to a styling spec (CSS). But given our current problem, we start to see the wisdom. We can select and animate the location marker with CSS3.

As demonstrated by Surfin Safari, first we describe the effect with @-webkit-keyframes, then we select the marker element from the DOM and apply the animation with -webkit-animation:

@-webkit-keyframes pulse {
  0% {
    opacity: 1.0;
  }
  40% {
    opacity: 0.25;
  }
  100% {
    opacity: 1.0;
  }
}
#map_canvas div[style*="blue_dot_circle.png"] {
  -webkit-animation-name: pulse;
  -webkit-animation-duration: 2s;
  -webkit-animation-iteration-count: infinite;
  -webkit-animation-timing-function: ease-in-out;
}

It’s a simple solution that provides the effect we need without the added overhead of JavaScript.

Feel free to view this map with your normal browser, you’ll get a plain old map of Austin—not much more. For the real show, open it in iPhone 3G and find your current location. Then start moving.

When you get back to the desk, crack open the source code to see how it was all brought together.

Next

So there it is: a breezy introduction to what is possible with the iPhone’s new Safari geolocation powers and Google Maps. We certainly don’t have to stop here. We haven’t even mentioned that other mobile devices have or will have these very same powers. That web developers now have direct access to these powers means that we can expect a torrent of location-aware innovation.

See you at the mall.

Reference Links

• our map
• The Google Maps API V3
• W3C Geolocation API Specification (Draft)
• Safari CSS Reference

For far too long, web designers have had to deal with a lack of real-world design tools in CSS. In their place, we’ve used kludgy HTML, images, and even JavaScript to accomplish basic visual treatments such as transparency, shadows, gradients, and, yes, rounded corners. Every solution using this old toolset calls for an uneasy compromise of appearance vs. semantic markup vs. development time vs. file count/size.

Why can’t we just ask the browser to provide a 5px radius in CSS in whatever color/width/shape we want and get on with our day? We can.

Welcome Border Radius

Firefox has supported a border radius property for some time now (-moz-border-radius) and Safari recently came out with their own experimental syntax (-webkit-border-radius). Furthermore, the CSS Working Group recently announced some pretty robust support for the border-radius property which means the usually standards-leading Opera should be getting around to roundness soon as well.

Using border-radius today provides nice, rounded corners and shaves a ton of development time (no more round-trips to the image editor or nesting HTML for flexible dimension boxes).

The problem, of course, is that 70% gorilla in the corner. So, what about IE? The yet-to-be-released IE8 is finally getting things right with CSS2.1 (a good thing) and moving their proprietary properties into -ms- vendor specific extensions (also a worthy effort). Yet it doesn’t look as though the IE team will be tackling border-radius until IE9 (2 years?).

Progressive Visual Enhancement

So at this point we have two options when it comes to going all CSS on rounded corners: we can whine and cry about how IE sucks (been done already) and wait for IE to get around to border-radius or we can take progressive enhancement to the next level.

Let’s take the latter route. Starting today, let’s throw out all the crappy, nested HTML; the countless, un-scalable images; and the overly-complicated JavaScript work-arounds. Let’s start fresh…

1. Lay a foundation of basic borders—square, un-adorned, solid borders. Every browser shall see squared edges by default. No problemo.
2. Then throw in some rounded corners for Firefox and Safari and anyone else that’d like to join the party. Kewl.
3. Lastly, add a dash of gradient to Safari as prescribed in Shiny Happy Buttons. Brilliant!

Sweet. No one gets hurt, the cool kids get the nicest looking stuff, and those squares that want to join the cool kids just have to download a free browser. What could be better?

One irritation defied all my attempts to resolve: disabling CSS via the Web Developer Extension’s long-standing keyboard shortcut CMD-SHIFT-S. Apparently the Mozilla team decided to Shanghai that shortcut for their History Sidebar. Why?

No matter. Today I found my solution in Keyconfig for Firefox 3. Now I can create, edit, or disable existing any FF3 shortcut I wish. Buhbye, History Sidebar!

Web development on a Mac is pure joy. There are so many tools that just that make building websites simple and even fun. From the dead-simple MAMP web server setup to the deceptively powerful TextMate editor to the game-changing Firefox browser-cum-editor/tester (with the essential Web Developer, FireBug, and ySlow extensions), it’s all good in Mac land.

And since Mac went Intel, we can develop like crazed bunnies and test our work in each nasty little flavor of Internet Explorer running in separate virtual Windows environments. Granted, it took a bit of Googling on my part to find out how to point Windows browsers to MAMP. But the two primary solutions are fairly straight forward and work in most cases:

1. use the Mac’s IP address (e.g., 192.168.2.2:8888)
2. create and use a hostname
   1. open the C:\WINDOWS\system32\drivers\etc\hosts file (in Notepad)
   2. add a line to the bottom with the Mac’s IP address and desired hostname (e.g., 192.168.2.2 mamp) and save
   3. use that hostname (e.g., http://mamp:8888)

In most cases? Yep. Everything runs fine so long as your apps don’t reference MAMP’s default webserver name, localhost:8888. Of course, the popular apps such as ExpressionEngine and WordPress do need a base URI—and localhost:8888 is it.

Bugger. Windows has it’s own localhost quite separate from Mac’s and neither the two shall meet. Accessing MAMP’s localhost just isn’t going to happen with Windows’ localhost listening in and intercepting. The only solution is to set up a hostname other than localhost on the Mac side and enter that same name in the Windows host config file.

The gritty, command-line way of changing MAMP’s hostname from localhost is to make some changes to its httpd.conf file and to muck with dscl (Apple’s NetInfo replacement). Feel free to Google the specifics, but I personally don’t want to have to fire up Terminal every time I want to change to another site. Thank goodness for VirtualHostX.

My new pal, VirtualHostX, allows me to create different virtual host names for all my projects. So rather than using the localhost URI, I can create meaningful URI’s such as newproject.dev and anotherproject.dev with impunity (which makes it superior to the Headdress method of merely assigning new port numbers to localhost). VirtualHostX makes all the changes behind the scenes and even backs up the default settings before making those changes. Sweet!

We’ve almost achieved web developer inner-peace… but we need to make one more stop. Let’s remove that crufty port 8888 bizness (e.g., localhost:8888, myproject.dev:8888). By default, MAMP uses port 8888 to avoid conflicts with OS X’s built-in web server (which listens to the http default port 80). Since I have no immediate intentions of using OS X’s built-in server, I immediately changed MAMP’s default port setting to good ole port 80. From here on out, just enter myproject.dev in any Mac browser and go. Yay. Nirvana.

Now, back to the Windows side. After adding myproject.dev to the Windows host file (e.g., 192.168.2.2 myproject.dev), fire up your Windows browser of choice, point it to myproject.dev, and Shazam! Everything works.