Doctyper http://doctyper.com Doctyper is the website of Richard Herrera, a front-end developer with a strong commitment to the web standards movement. Tue, 16 Nov 2010 19:01:20 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 Apple’s shiny new USB installer icon http://doctyper.com/archives/201011/apples-shiny-new-usb-installer-icon/ http://doctyper.com/archives/201011/apples-shiny-new-usb-installer-icon/#comments Fri, 05 Nov 2010 19:40:32 +0000 doctyper http://doctyper.com/?p=112 Apple's shiny new icon

Download it here.

]]>
http://doctyper.com/archives/201011/apples-shiny-new-usb-installer-icon/feed/ 0
Quick Compile SASS with Compass + TextMate http://doctyper.com/archives/201009/quick-compile-sass-with-compass-textmate/ http://doctyper.com/archives/201009/quick-compile-sass-with-compass-textmate/#comments Wed, 22 Sep 2010 22:00:44 +0000 doctyper http://doctyper.com/?p=98 I’ve created a tiny TextMate bundle to quickly compile SASS into CSS. The bundle uses a SASS_DIR variable unique to your project pointing to your SASS directory. Here’s how to set it up:

  1. For best results, install the SCSS + Zen bundle beforehand.
  2. Download and install the Quick Compile bundle.
  3. In your project drawer, select the “i” icon in the bottom right corner. If the icon is grayed out, you probably have a file or folder selected within the drawer. Deselect the file by clicking elsewhere inside of the drawer.
  4. Add a SASS_DIR shell variable. The value should be the path to your SASS folder relative to your project root.
    Note: on a default compass generated project, the relative path is your project root. The SASS_DIR value should be “.”, unquoted.

That’s it. The keystroke is mapped to ⌘S. It will autosave along with your usual workflow. The Compass output will appear as a tooltip, either to confirm the output or to notify you of errors. Apologies for the formatting, I don’t see a way to clean it up:

Download Compass Quick Save 1.0

]]>
http://doctyper.com/archives/201009/quick-compile-sass-with-compass-textmate/feed/ 4
Substitute :last-child for :first-child for IE 7 support http://doctyper.com/archives/200912/substitute-last-child-for-first-child-for-ie-7-support/ http://doctyper.com/archives/200912/substitute-last-child-for-first-child-for-ie-7-support/#comments Tue, 01 Dec 2009 23:05:29 +0000 doctyper http://doctyper.com/?p=56 Consider the following:

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”.

]]>
http://doctyper.com/archives/200912/substitute-last-child-for-first-child-for-ie-7-support/feed/ 3
Add Ping.fm to your Twitter homepage with Greasemonkey / GreaseKit http://doctyper.com/archives/200912/add-ping-fm-to-twitter/ http://doctyper.com/archives/200912/add-ping-fm-to-twitter/#comments Tue, 01 Dec 2009 22:50:58 +0000 doctyper http://doctyper.com/?p=50 For those using either Greasemonkey or GreaseKit, I threw together a quick script to add the Ping.fm interface in your Twitter homepage:

Ping.fm / Twitter Integrator

Here’s a screenshot of what that looks like for reference:

]]>
http://doctyper.com/archives/200912/add-ping-fm-to-twitter/feed/ 0
RGBa makes a great debugging tool http://doctyper.com/archives/200912/rgba-makes-a-great-debugging-tool/ http://doctyper.com/archives/200912/rgba-makes-a-great-debugging-tool/#comments Tue, 01 Dec 2009 22:31:09 +0000 doctyper http://doctyper.com/?p=48 With 24 Ways pushing RGBa into the foreground today, I thought I’d share a quick debugging tip. Using RGBa can help while you’re debugging element positioning. For the adventurous, combine with a debug class:

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

]]>
http://doctyper.com/archives/200912/rgba-makes-a-great-debugging-tool/feed/ 0
Flow 1.1 http://doctyper.com/archives/200906/flow-11/ http://doctyper.com/archives/200906/flow-11/#comments Mon, 15 Jun 2009 00:44:24 +0000 doctyper http://doctyper.com/?p=47 And just like that, a new update. Several small fixes worthy of a point upgrade:

  • Switched QuerySelector engine to Sizzle 1.0
  • querySelector/querySelectorAll can now be run on any element (via Selectors API)
  • IE 8 does not like setAttribute on type elements. Reverting to DOM 1 method.
  • Fixed minor assertion bug in Require.js
]]>
http://doctyper.com/archives/200906/flow-11/feed/ 0
Flow 1.0.8 http://doctyper.com/archives/200906/flow-108/ http://doctyper.com/archives/200906/flow-108/#comments Sun, 14 Jun 2009 14:44:23 +0000 doctyper http://doctyper.com/?p=45 A tiny update that fixes IE 8 browser identification. It previously incorrectly identified IE 8 as IE 5.

]]>
http://doctyper.com/archives/200906/flow-108/feed/ 0
Pickleview shuts down http://doctyper.com/archives/200906/pickleview-shuts-down/ http://doctyper.com/archives/200906/pickleview-shuts-down/#comments Sun, 14 Jun 2009 14:44:12 +0000 doctyper http://doctyper.com/?p=46 It had a good run there for a few months. I don’t need to tell you about MLB’s At Bat app do I? It’s the better (and free) alternative, and I can’t really compete with baseball’s integrated setup.

My thanks to the founders, wherever you are. That was a great weekend.

]]>
http://doctyper.com/archives/200906/pickleview-shuts-down/feed/ 1
Fixed positioning in Mobile Safari http://doctyper.com/archives/200808/fixed-positioning-on-mobile-safari/ http://doctyper.com/archives/200808/fixed-positioning-on-mobile-safari/#comments Wed, 06 Aug 2008 00:34:07 +0000 doctyper http://doctyper.com/?p=44 11/16/2010: It’s been a long time since my fixed positioning script was released. I’m very pleased that it was the precursor for much more robust solutions to this problem. Please continue on if you’d like to read through the history of this hack. If you’re looking for a real-world solution please take a look at one of the following, ranked (subjectively) in order of scroll performance:

  • Sencha Touch – A complete framework with fixed scrolling, custom widgets, and more.
  • YUI Scrollview – Standalone solution built on YUI3
  • iScroll – Completely standalone, no library dependencies

Update: An anonymous genius in the comments suggested using translateY instead of top for the animation. After some edits I’ve updated my demo, and it flies! The scrolling animation is smooth as silk. Apparently Webkit transforms are the only hardware-accelerated animations at this point. Thanks, random dude on the internet!

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.

]]>
http://doctyper.com/archives/200808/fixed-positioning-on-mobile-safari/feed/ 95
Breaking out of a forEach loop http://doctyper.com/archives/200807/breaking-out-of-a-foreach-loop/ http://doctyper.com/archives/200807/breaking-out-of-a-foreach-loop/#comments Fri, 25 Jul 2008 00:40:02 +0000 doctyper http://doctyper.com/?p=43 An email going around the client-side mailing list at Schematic casually mentioned forEach loops. The sender liked them, but tended to avoid them because there was no way to break out of one.

Naturally, this sent me on the hunt to see if it was at all possible. A furious Google search led me to a comment by Dean Edwards (who else?). He suggested throwing yourself out of the loop and wrapping the throw in a try catch statement to silence the throw. Like so:

var array = [1, 2, 0, 3, 4, 5];
try {
  array.forEach(function(item) {
    if (item === 0) {
      throw new Error(); // Simulated break
    }
    console.log(item);
  });
} catch (e) {}

That does the trick. Fellow developer/comrade Lenny Burdette pointed out that this was exactly the method Prototype uses to break their own custom loops.

But of course, there’s caveats. With Prototype, you merely have to call $break to have it automate this for you. With Flow, you’re exposed to the elements and need to handle it yourself. It’s a neat trick, but quite honestly it’s not very user friendly, and looks a bit unwieldy as a workaround.

I browsed the forEach documentation and went through possible solutions. One was to extend forEach and include a custom break function in it. But I decided against this for a few reasons. One, it would violate the rules (#3, to be exact). Over-extending a native function would bring more hurt than it would good. Second, Safari 2 has a problem with extending forEach, so it wasn’t a viable solution either.

But I had a hunch. What if I simulated a break by splicing off the remaining objects in the array, thereby terminating the loop entirely? I gave it a try:

var array = [1, 2, 0, 3, 4, 5];
array.forEach(function(item, i) {
  if (item === 0) {
    array.splice(i, array.length - i); // Simulated break
  } else {
    console.log(item);
  }
});

Success! The loop terminates, because there are no more objects to continue to. There’s just one problem: there are no more objects to continue to. It mutates the array, so it’s not reliable if you need to reuse the array. You’re limited to using it only once, or having to rebuild the array.

Ah, but what if you splice the array, and immediately concatenate it? Would it have the same effect and stop the array in its tracks?

var array = [1, 2, 0, 3, 4, 5];
array.forEach(function(item, i) {
  if (item === 0) {
    array = array.concat(array.splice(i, array.length - i)); // F-f-f-forEach breaker!
  } else {
    console.log(item);
  }
});

Double success! In this example, the array is spliced from the current index point, and all remaining objects are dropped off, ending the loop. The magic happens when we rejoin the array using concat, and reassign the newly constructed object to the array variable. The array is mutated back to its original form, and you’ve broken the forEach loop.

Still, it’s not as satisfyingly simple as a break, is it? Well, we can’t call a break, but we can get close. The next Flow revision will contain the exit Array extra, which will provide you with a keyword (or, as close enough a keyword as I could get) to break a forEach loop:

var array = [1, 2, 0, 3, 4, 5];
array.forEach(function(item, i) {
  if (item === 0) {
    array = array.exit(i);
  } else {
    console.log(item);
  }
});

]]>
http://doctyper.com/archives/200807/breaking-out-of-a-foreach-loop/feed/ 0