.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

It started with Dean Edwards and his release of the Base2 library. It scratched an itch that I’ve had for years: I wanted the ability to use the DOM API (Level 3) in all modern browsers. Base2 has since seen a second revision and is even more powerful than before. (Aside: Dean Edwards’ is a freaking genius.)

But I wanted more. I wanted a hybrid API that would allow me to use the standard API, but would also contain helper functions, shorthand notation, chainability, etc. So I got to work.

After eight months of development, trials, tears and tribulations I am pleased to announce the initial release of The Flow Framework.

Flow aims to fix and enhance the DOM Level 3 API. Flow extends API functionality to browsers that currently don’t support it. Additionaly, it adds powerful functionality on top for the best bang for your JavaScript buck.

A sample of the functions it implements cross-browser:

• getElementsByClassName / getElementsByAttribute
• addEventListener / removeEventListener (with DOMContentLoaded support)
• preventDefault / stopPropagation
• addClass / removeClass / replaceClass
• querySelector / querySelectorAll
• shorthand notation (getById, getByTag, getByClass, etc)

Here’s a snippet of what can be accomplished with Flow:

Find all: ul.checked li

With Flow Core

var uls = document.getElementsByClassName("checked").filter(function(e) {
  return e.nodeName.toLowerCase() == "ul";
});
var lis = [];
uls.forEach(function(ul) {
  ul.getElementsByTagName("li").forEach(function(li) {
    lis.push(li);
  });
});

With Flow Extend

var lis = document.getByClass("checked").filter(function(e) {
return e.elementName() == "ul";
}).getByTag("li");

With Flow Query

var lis = document.querySelectorAll("ul.checked li");

Want to open external links in new windows via JavaScript?
document.getByAttr("rel", "external").setAttribute("target", "_blank");

Want to return false on those pesky blank-anchor links?
document.getByAttr("href", "#").addEventListener("click", function(e) {
  e.preventDefault();
}, false);

There are more code samples, documentation, unit tests on the official site. Be sure to download a customized Flow build and try it out!

For those that want to take a gander at the code, you can check out the source on Google Code: http://code.google.com/p/flowjs/.

There’s already a website using Flow in the wild. South Park Studios was unveiled a couple of months ago, and it’s been chugging along since. Unfortunately I was under gag order at the time while the final details were being hammered down. Now I can officially state that it’s using Flow and lovin’ it.

Many, many thanks to Schematic for supporting the release of this library, and to the many Schematicans who freely contributed to the library.

Thanks are also in order to the great JavaScript programmers who’ve turned us all on our heads: John Resig, Dean Edwards, Robert Nyman, Tino Zijdel, Sergey Ilinsky and countless others.

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.

application/xhtml+xml vs text/html

5.1. Internet Media Type

XHTML Documents which follow the guidelines… may also be labeled with the Internet Media Type “application/xhtml+xml” as defined in [RFC3236]…

W3C XHTML 1.0 Guidelines

There are many who feel that an XHTML document without the proper application/xhtml+xml content type is no better than transitional markup, or even tag soup. This is preposterous. First and foremost, content served as application/xhtml+xml will not render in Internet Explorer. The world’s most popular browser will not render this content type. What more do you need to steer clear of this headache?

On the other side of the coin, strict XHTML served as text/html will take advantage of debugging tools (such as validators) to help you code a better page. text/html is allowed per the W3C specifications. It is not meant to be avoided, it is meant to aid your cross-browser needs.

Transitional v. Strict

For all intents and purposes, this is the real question that needs addressing. Not whether you should use (X)HTML, but whether you should use a transitional or a strict doctype. The answer is, and always should be a strict doctype.

In this day and age, it is imperative to think of the transitional doctype as deprecated. Quite honestly, the only thing a transitional doctype is useful for is a false sense of satisfaction when validating your markup. The transitional doctype was created to bridge the switch from HTML to XHTML. It’s treated that way by the W3C, and they go so far as to recommend a strict doctype.

The number one reason you should use strict over transitional is cross-browser compatibility. Believe it or not, the Gecko-based browsers render pages slightly differently when triggered by a transitional doctype. This is called “almost-standards mode”, and is defined in the Mozilla Developer Center documentation.

Using a strict doctype ensures that every browser renders your markup as closely as possible with the standardized specs.

But… my markup isn’t valid in strict mode!

Validity does not equal accessibility. An invalid strict page is always better than a valid transitional, as long as you recognize why it fails validation, and you’ve exhausted all options to correct the markup. True accessibility and semantically correct markup require a separation of content, design, and function. Many of the HTML attributes were created to aid design. Examples are the border, align, width and height attributes. These attributes are deprecated in strict doctypes.

Invalid markup in a strict doctype must be treated as invalid in a transitional doctype, regardless of validation output. HTML is an extremely forgiving language, something you must ignore to better your coding, and to better the web. Consider the error handling in languages such as PHP, ASP and XML. In each, an error will trigger the language to immediately stop rendering until the problem is rectified. There is no option to do otherwise.

Not so with client-side languages. HTML, CSS, and JS all will forgive (and sometimes, forget) errors it receives. This is the way it always will be, because the nature of the web depends on pages rendering despite bad coding practices. The sign of a great front-end developer is the ability to correctly parse the language without the need for error handling.

And so, I submit to you that this:

<ul>
  <li>something
  <li>something else
</ul>
is no better than this (in XHTML):

<br>

is no better than this (in XHTML):

align="absmiddle"

In the end, it is up to the developer to decide which of the two language types is most comfortable. Both have their charm, and both have their acceptable uses. But you must code using a strict doctype. It is the only way to eliminate browser quirks, and it is the best environment you will have to achieve cross-browser optimization.

It seems odd to me that there isn’t (as of yet) anything out there that brings these two fan favorites together. If any two applications are deserving of a mashup, it’s these two. So I said to myself, “Self, why not build your own?”

A few hours later, I had myself a bona-fide Firebug bundle for TextMate.

The bundle automates the console commands found in the Firebug API. They’re all in there, every last one. One of the reasons I built the bundle is because I constantly found myself resorting to console.log for most of my debugging. I knew that Firebug offered many more commands to take advantage of, but I just never had the time to keep looking up commands. Fortunately, this bundle solves that problem. With a simple keystroke, all the console commands are at your disposal.

Features

Keystrokes

The default keystrokes are Command + D (D… debug, get it?) and Command + Shift + D. You can change the keystrokes to whatever you wish. Part of the TextMate versatility I was talking about.

I’ve split the commands into two sets, because of the number of console commands in the API, and because I wanted each command to have it’s own shortcut. Each set contains half of the commands organized in order of the documentation.

Documentation

In case you need a refresher on what a command does or what it outputs, I’ve added the Firebug Console API documentation in the bundle. Selecting it will open the TextMate web preview, with the complete documentation intact.

I also threw in a couple of features to help automate the edit/debug process:

Debug with Firebug

Debug with Firebug (Command + D, 9 in javascript; Command + D, 1 in HTML) will check to see if Firefox is running. If so, it switches focus to the browser, refreshes the current window, and then launches Firebug (if needed).

Profile with Firebug

Profile with Firebug (Command + D, 0 in javascript; Command + D, 2 in HTML) does the same, but it invokes the Firebug profiler, then refreshes the current window. After a short delay, it returns the captured events.

Both of these last two features require that you enable access for assistive devices. This is found under System Preferences > Universal Access > Enable access for assistive devices.

Installation

1. Download Firebug.tmbundle.dmg.
2. Mount the disk image.
3. Double click on Firebug.tmbundle. TextMate should launch, and the installation is complete.

Troubleshooting

If you are selecting Debug with Firebug or Profile with Firebug and nothing happens, one of two things is wrong:

1. Firefox is not running. Open Firefox and the page in need of debugging.
2. Access to assistive devices is disabled. See above for instruction on enabling access.

If you find that the profiler returns too fast, it is possible to alter the length of time it waits:

1. In TextMate, open the Bundle Editor (defaut: Control + Option + Command + B) and select the Firebug bundle.
2. Click on “Profile with Firebug”.
3. Find the value “delay 2”.
4. Tweak “2” to your liking. I recommend incrementing by 1 until you hit your sweet spot.

Please let me know of any bugs, or if you’d like to suggest an improvement.

Firebug.tmbundle.dmg

Let’s get a disclaimer out of the way: I am a markup purist at heart. There’s nothing that tugs at my heartstrings than well-structured markup. So it pains me to see the body element so underused, especially when that #wrapper div you created can do exactly what <body> can.

There are situations where you will no doubt need that #wrapper element, and I’d bet it will have something to do with Internet Explorer. But the remainder of the time, I’d wager that element is just plain expendable. Let’s take a look at an example:

body {
  margin: 0;
  padding: 0;
  font: 76%/1.6 "Comic Sans", Arial;
  text-align: center;
}
#wrapper {
  margin: 0 auto;
  padding: 1em;
  width: 750px;
  text-align: left;
}

Here we have a sample of what I constantly see. Usually, margins, paddings, and maybe a font declaration is relegated to the body element, and then it is left alone to spend the rest of its days in CSS purgatory. Subsequent properties are then added to a superfluous and unnecessary element.

But the same feat can be accomplished with just a body element!

html {
  margin: 0;
  padding: 0;
  font: 76%/1.6 Helvetica, Arial;
  text-align: center;
}
body {
  margin: 0 auto;
  padding: 1em;
  width: 750px;
  text-align: left;
}

Think of the Document Object Model as a staircase. By merely “stepping up” a level and utilizing the oft-ignored element, we save ourselves a wasted element. It may seem like a small thing, but remember that a div element has no semantic value anyway. And search engines will adore you for making sure your content gets to them without crawling through another div.