ul li {
   display: inline;
   margin-right: 10px;
   padding-right: 10px;
   border-right: 1px solid red;
}

ul li:last-child {
   margin-right: 0;
   padding-right: 0;
   border-right: 0;
}

This bit of CSS would give you perfect line separators in IE8+. But since IE 7 supports the :first-child pseudo-class, we can do one better:

ul li {
   display: inline;
   margin-left: 10px;
   padding-left: 10px;
   border-left: 1px solid red;
}

ul li:first-child {
   margin-left: 0;
   padding-left: 0;
   border-left: 0;
}

Same* result, with more browser support.
*Substitute for “sane”.

.debug {
  background: rgba(255, 0, 0, 0.5);
}

Update 2: This code is released to the public domain. You can use, modify, remix as you see fit.

Behold, fixed positioning on iPhone! http://doctyper.com/stuff/iphone/fixed/

Here’s a video for those without iPhones. This is running in the iPhone Simulator bundled with the SDK. Note that the animation is much choppier on an actual iPhone.

With the release of iPhone OS 2.0 came some great improvements over previous Mobile Safari versions. CSS animations are in (though buggy), as well as native touch events like touchstart, touchend, gesturechange, etc.

I played around with these new goodies while hunting for improvements to build into Pickleview. The most fascinating change to me was that you can now prevent the default behavior of elements with a simple preventDefault() call. It allows a user to drag an element around the screen without having to worry about the viewport wobbling about.

I grew curious as to what I could specifically call this on, and started testing out several elements. Turns out you can preventDefault on everything in the DOM, including the body element. This seemed incredibly useless for no other reason than the terrible usability it would bring if you couldn’t scroll the viewport. Then the proverbial light bulb went off: fixed positioning!

First, let’s recap why fixed positioning does not work off-the-bat. Mobile Safari uses a viewport to show you websites. Imagine a book in front of you. Take a piece of paper, cut a 320×416 square in it, and lay it over the book. To read the book, move the paper around and position the hole over the words you want to see. This is exactly what Mobile Safari’s viewport is doing. When you flick and scroll, you’re moving the viewport around while the website behind it stays static.

This renders fixed positioning null and void on iPhone. An element that has its position fixed is affixed to the body, not the viewport. So it is actually working as intended, though most people would prefer it attached to the viewport.

There are workarounds in the wild, but these are inelegant. You can reposition an element onscroll, but a scroll event in Mobile Safari is only fired after scrolling has stopped. This results in an evident “glitch” since you have to a) flick to your desired position, throwing the element off-screen, and b) wait for the element to reappear in the viewport after scrolling has stopped.

By disabling the default scroll behavior on the body element, you essentially glue the viewport down to its initial starting point, where it’s unable to go anywhere. This limits the viewport to exactly 320×416 pixels of space to show you. In this state, you have a perfectly useless experience.

This is where it gets interesting. In order to re-enable scrolling, I needed to only make the content area scrollable (think iframe, with header and footer above and below it). The touch and gesture events gives access to X/Y values, as well as timers and offset values. So by logging these and incrementing the top offset of the content area, we can create a scrollable block that does not affect the header or footer elements. A little spit and polish later: voila!

It’s pretty evident from my proof-of-concept that CSS animations need a lot of work. They’re promised to be “hardware-accelerated”, but there’s little proof of this. Most animations glitch, some to the point of non-use. The scrolling isn’t particularly smooth and even something as simple as animating a ‘top’ CSS property takes its toll. Still it’s usable, though I hope later Mobile Safari builds will address these issues.

If you’re interested, I’ve bundled together the source files for my proof-of-concept. Grab ‘em here.

Bug fix:

Flow will no longer choke with SWFObject.

Early this morning I received a report about Flow not playing nicely with SWFObject. After debugging, it turned out it was a case of doing too much.

SWFObject correctly cleans up after itself in IE by removing its generated code on unload. The conflict appears because Flow does the same with its code, going as far as eliminating all extended element properties.

So when SWFObject tried to removeChild, it returned null because Flow extends that property, and by the time SWFObject got to it, it was already wiped out.

Flow now merely restores an extended property back to its original implementation, rather than nullifying the property. This will fix the error.

Feature:

dispatchEvent is now implemented in Flow. You can use it to fire events on elements from another element. Confusing? Here’s an example:

var test = document.getById("test");
test.addEventListener("click", function() {
    // console.log(this.id);
}, false);
 
document.getById("dispatcher").addEventListener("click", function() {
    test.dispatchEvent("click");
}, false);

You can pass any event type and it will fire all events coupled with that type.

As usual, you can download the Flow framework at http://flowjs.com

What started as a simple itch to scratch has turned into a full-fledged iPhone application, used by true honest-to-goodness people. Really!

The feedback has been nothing short of spectacular. We’ve received tons of praise and we’ve listened to your feedback, sometimes pushing out updates within hours of suggestions. A gigantic thank you to everyone who pushed us to keep upping the ante.

An extra amount of thanks to Major League Baseball and Twitter, the entities responsible for providing us data. Without them Pickleview would not exist.

To commemorate this milestone, I’m happy to say that we’re releasing the Pickleview code under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 License. You are free to learn from it, distribute and modify (as long as you share alike). View the source here. Thanks to the good folk at iPhoneWebDev for hosting our files. We’re hoping it becomes the repository for open-source iPhone web applications.

Lastly, stay tuned. We’ve got things in the works, gears are grinding, and overtime is being spent.

Over the weekend I attended iPhoneDevCamp, a gathering of web geeks from around the globe with one purpose: to create applications for iPhone.

I went into the event with little-to-no expectation of anything happening. It being my first BarCamp I didn’t know the atmosphere, how we would mingle, etc.

What happened that weekend was something I won’t forget for some time. It was a great feeling to walk through the Adobe Town Hall and see energy popping from 300 minds at once. You could feel the electricity as people discovered loopholes and solved riddles that had puzzled iPhone developers since its release.

My story was rather interesting. After a canceled flight and barely making the 6:00pm start time (United: Never Again), I was sticking with my usual schtick: talk to no one, avoid eye contact. Twenty minutes in, I suddenly realized the magnitude of the event and was determined to talk to someone– anyone.

It was then I spotted a couple of individuals at a corner table, mingling away. I took a chance, and introduced myself. Ryan and Seto were their names. A short while later, Estelle joined the small table, and we started brainstorming.

I’d been developing a small web app I dubbed LiveScore for a Dodgers’ fan forum that I run. It gave real-time updates of Dodger scores, as well as some vital stats of each game. On a whim I opened up the app and showed it to the group. The gang really took to it, and from that point brainstorming focused around LiveScore.

Minutes later, we had a prototype: A web app/mashup that would combine live game tracking with the ability to chat along with friends on Twitter.

And so, Pickleview was born.

In the span of 36 hours, we four furiously coded together the required bytes to get the app off the ground, and wrapped it around a native-looking UI. It was thrilling to say the least, if not completely overwhelming. I don’t believe I’ve ever coded so much in so short a time.

We had our small moment in the sun, making some top ten lists and being interviewed by the San Jose Mercury Press. But the real payoff was being able to release a very useful app for others to enjoy.

That, and comments that would make anyone jump for joy. Thanks again, Joe.

Since the camp, we’ve been working hard to improve our little app that could. We’ve added features such as play-by-play, visual cues on score, balls/strikes tracking, and lots and lots of bug fixes. I have to say I’m enjoying the ride. All for an app I’m proud to be a part of.

I should reiterate that neither I nor Ryan nor Seto nor Estelle had ever met each other before Friday. It was a great experience to be able to accomplish so much with virtual strangers. Pickleview, however, is quickly making us closer acquaintances.

Please note that I’m not talking about image-based opacity, but rather opacity on any given element. There are articles on image opacity that are still relevant to today’s browsers.

The current favorite method is a combo opacity/filter fix to placate Gecko and Webkit browsers, as well as IE 6 and below. This involves setting a opacity value for browsers that support the spec, and hacking out an acceptable solution for browsers that don’t (read: <IE6). The fix is outlined below:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
      -moz-opacity: 0.5;
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->


As you can see, the code is quite verbose for what it is. Let’s take it step-by-step. The first style block contains the supported opacity properties for Safari and Opera (opacity), as well as Gecko-based Firefox and Camino (-moz-opacity).

The latter block is designed so that only Internet Explorer receives that code (in real-world application, this code would appear in a separate “<IE 6 only” style sheet. The block contains a proprietary property called “filter”, supported by Microsoft browsers. This property is not approved by the W3C, and is therefore invalid. Thus the need to “hide” it from validators and place it in its own style sheet.

While the code is slightly complex, it has served its purpose. But with the evolving nature of the web, its status has changed since this method was concocted. New browsers have emerged, others have updated. Essentially the web has changed enough that we must tweak this fix in order to get true cross-browser opacity. There are a few ways to handle this depending on your preference and whether or not you care about style sheet validation. Lets take a look, first at the browser changes, and at a couple of updated fixes:

Internet Explorer 7

Its characteristics are impressive. It supports quite a bit more W3C approved properties than it’s predecessor. However, the powers-that-be decided that it would not support the opacity properties– not yet, anyway.

On the other hand, IE 7 does still support the proprietary filter property. This means that IE 7 will respond to the same fix created for IE 6.

However, one of the many improvements IE 7 brings to the table is its native support for PNG transparency. This is an important point, as it allows us to devise a fix that will play better for those not interested in yet another conditional comment.

Gecko-based browsers (Firefox, Camino)

Gecko browsers support their own proprietary CSS property, the -moz-opacity property. However, it’s no longer necessary to declare this property, since current versions now include support for the standard opacity property.

So, given these bits of info, we’re left with the following cross-browser opacity methods:

The single conditional comment fix

The simplest method of all these is to simply remove the -moz-opacity property and open up the IE conditional comment to include IE 7. Example below:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
    }
  </style>
  
  <!--[if lte IE 7]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
    #someOtherElement {
      height: 1%;
      margin-left: -3px;
    }
  </style>
  <![endif]-->


While this is an easy solution, it is not often the best. For example, your CC was probably specified for IE 6 and below for a reason. Remember that IE 7 is much more standards-aware than previous IE incarnations, and probably does not need any of the hacks defined in the <IE 6 stylesheet. Thus, you’d most likely have to do some more work hiding those hacks from IE 7.

The multiple conditional comment fix

Another method is to create another stylesheet, and wrap it around an IE 7 conditional comment:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
    #someOtherElement {
      height: 1%;
      margin-left: -3px;
    }
  </style>
  <![endif]-->
  
  <!--[if IE 7]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->


This fix addresses the problems of the earlier fix, but creates additional markup, not to mention yet another stylesheet to maintain. If all the IE 7 stylesheet does is add opacity support, it would hardly be in your best interest to keep it around.

The IE 7 filter fix

There is another way to support IE 7, and that involves using an IE 7 CSS filter to target only that browser:


  <style type="text/css" media="screen">
    #element {
      opacity: 0.5;
    }
    *:first-child + html #element {
      filter: alpha(opacity=50);
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->


This works a treat, but it also carries the inconvenience of invalidating your style sheet.

The PNG transparency fix

This is my favorite method, merely because it eliminates the issues of the first three methods. However, that’s not to say it doesn’t come with it’s own flaws:


  <style type="text/css" media="screen">
    #element {
      background: url("/path/to/image.png");
    }
  </style>
  
  <!--[if lte IE 6]>
  <style type="text/css" media="screen">
    #element {
      filter: alpha(opacity=50);
    }
  </style>
  <![endif]-->


This method eliminates the opacity property altogether, and instead relies on a transparent PNG to mimic transparent color. Because IE 7 supports native PNG transparency, the fix works for all advanced browsers. The <IE 6 stylesheet is left alone, since it’s PNG support leaves much to be desired.

The downside of this method, of course, is that you lose the ability to easily update the element you are editing. Rather than changing a hex value, or tweaking the opacity value, you’d have to go through your photo editor and change a PNG in order to see changes.

So there you have it, four distinct ways to implement cross-browser opacity. Each with its benefits, each with its flaws. It’s ultimately up to you to weigh those against each other, and choose what best fits your needs.