Beckism.com

When I was testing Tumblr as a platform for beckbits, I discovered that their RSS feeds didn’t offer quite what I was hoping. Since I was primarily planning to use beckbits as a link blog, I wanted it to work Daring Fireball-style: link items should go straight to the source material, and all other items should be permalinks back to the site. I’ve always thought that was a brilliant design choice on John Gruber’s part, and I’ve always been a big believer in integrating aspects of great design that I find around the web into my own projects.

In the hopes that I could take the RSS feed and remix it easily on my own, I turned to Yahoo Pipes. Yahoo Pipes provides a relatively easy graphical interface to parse, modify, and combine data streams, JSON, and RSS and spit it back out as RSS, JSON, or PHP serialized code. I first discovered Pipes when I found someone’s “lifestream”, a website that displayed a list of their activity across numerous different services using Yahoo Pipes. These kind of RSS feed mashups seem to be the most common use of the service, but the service is quite flexible so it seemed well suited for repurposing Tumblr’s RSS feed to my own uses.

Over the course of creating the feed, I discovered some interesting features that I feel are worth sharing. For those of your who are curious about my specific implementation, here’s the actual pipe that is powering beckbits.

Moving data between elements

Very early on in my exploration of the default Tumblr RSS feed I realized that I was going to need to use the Tumblr API if I wanted to get direct access to the various components that make up Tumblr posts. Of course, the API provides completely different elements than an RSS feed, so one of the main tasks of my pipe is to move data around between elements.

For things with a one-to-one relationship, the “Rename” operator typically does the trick. For instance, using the external site’s URL for the RSS item link on Tumblr link items was as easy as throwing in a Rename with the rule “item.link-url renamed to link“.

But what about when I needed to combine multiple fields into one? Rename certainly wasn’t going to help me there, and I couldn’t find any way to pipe data between operators and string functions.

Fortunately, the Regex operator came to the rescue.

Although I couldn’t find any documentation for this, the regex module offers a couple great features:

• If you reference an element in the first column that doesn’t exist, it will be created.

• You can include the contents of other elements using the “named backreference” syntax (${element-name}). For instance, when I wanted my description element to include both the Tumblr “quote-text” and “quote-source” elements the “replacement” column looked something like this:

  <blockquote>${quote-text}</blockquote><p><cite>${quote-source}</cite></p>

Simple conditionals using regex

Thanks to the fact that everything in a Yahoo pipe is evaluated sequentially, you can use the regex operator to setup simple conditionals. For instance, regular Tumblr posts have an optional title. If the title existed, I wanted to use it as my RSS item’s title; otherwise it should default to a short excerpt of the text. To accomplish this, I setup the following rules:

Rename
item.regular-title copy as title

Regex
In item.title replace (.*) with $1```${excerpt}
In item.title replace ^```(.*)$ with $1
In item.title replace ^(.+?)```.* with $1

The basic idea is to combine two fields into one separated by some delimiter characters that are unlikely to ever show up otherwise. I chose to use three backticks, since it kept things pretty legible and I rarely use backticks. If you’re not comfortable with regex, the rules in order say:

1. Copy regular-title to title (because regular-title might not exist, this may result in an empty title element)
2. Append ``` plus the excerpt element to whatever is in the title element
3. If the title element starts with backticks (^```), replace its contents with whatever follows the backticks (the excerpt)
4. If the title element starts with one or more characters followed by backticks (^(.+?)```), replace everything with that starting content

Replacing your site feed with a pipe

Once I’d created my pipe it was time to replace beckbits’ feed with the pipe, and I discovered that Yahoo Pipes has a serious downside when it comes to using it instead of your default site feed: the pipe’s output always links back to the pipe page as the feed’s homepage. Although this wouldn’t be a huge deal, it has the unfortunate side effect of causing the favicon associated with your feed to be the Yahoo Pipes favicon, which is extremely non-ideal. In order to fix this, you actually have to post-process the pipe output.

For myself, I opted to do this by reading in the pipe as serialized PHP and then constructing my own simple RSS feed. If you’re interested in doing something similar and would like a starting point, here’s the gist of it.

If you’ve ever tried to make an HTML form look like the fancy PSD mockup that your graphic designer threw together, you know how much hate forms deserve. Forms are an integral part of the web, yet making them semantic, accessible, and visually appealing across browsers can be a major bitch.

There’s lots of information scattered about the interwebs about arm-wrestling forms into submission, but I recently ran across an issue that has not, so far as I know, been adequately discussed. That topic is legends.

No, not like the legend of Jeffrey Zeldman and his big blue ox, although that’s a good one; I’m talking about the legend element that attaches to fieldsets in order to let your visitor know what the heck this group of form controls they’re supposed to fill out pertains to. Legends, it turns out, are some of the most annoying elements to style you can find. Not only do they by default have some bizarre formatting applied to them by every browser out there (usually in slightly different ways), but normal styling rules don’t apply. Display: block, anyone? Yeah, ain’t happening.

Recently I was asked to style a really nicely laid out form; it had everything lined up down the left side, clearly labeled sections, the works. Except that the headings for each section were occasionally long enough to wrap, and were displayed with many of the same rules as the H3’s on the page. Easy enough, I figured, I’ll just stick display: block and some margins on them.

Which is when I discovered that display: block has no effect on legends in any browser (any browser worth testing in, that is, which means IE 6, IE 7, Firefox 2, Firefox 3, and Safari for my company). Legends with lots of text in them tend to stretch themselves or, worse, their parent elements out to keep everything on the same line, and even if they’re supposedly block-level elements with a margin they’re still treated as inline. Not cool. Fortunately, my latent CSS superpowers were activated when I started swearing like a sailor (wish I had a more socially acceptable trigger, but there you go) and I pounded out some CSS that:

1. Forces long legends to wrap in IE, Firefox, and Safari
2. Encourages legends to act like they know what display: block is all about

The code looks like this (or see it in action):

HTML

<fieldset>
    <legend><span>Legend text</span></legend>
</fieldset>

CSS

legend {
    margin: 0 0 15px;
    float: left;
    white-space: normal;
    *margin-left: -7px;
}

legend span {
    width: 400px;
    display: block;
}

Seem weird? That’s because it is. Here’s the reasons for the insanity:

If you’re like me, you’ll want a margin on your block level elements; in order to get your margin recognized in Firefox 2, you have to put it on the legend element. Of course, margins won’t be recognized on inline elements or legends, but since display: block does squat for a legend you have to float the legend left. For the full display: block effect, of course, there should be a width on the legend, but since Firefox will collapse the legend’s width down to its content anyway, I left it off.

Instead, the semantically meaningless span gets the width and display: block. The span not only forces Firefox to bump the legend’s width out the correct amount, but it also is necessary for long legends to wrap in some browsers. I’m using a pixel width mainly because IE 6 requires a different pixel width (more on this later). Although in a perfect world your legends would not have anything in them other than the legend text, we don’t live in a perfect world.

Adding white-space: normal to either the span or the legend will fix the wrapping problems in Firefox 3 (I chose to attach it to the legend in the hopes that in fifty years or so I can rid myself of that span with less effort).

The *margin-left: -7px line is a hack to fix an IE-specific problem. Even with no padding, margin, and left: 0px IE will still indent your legends seven pixels. The star-property hack targets both IE 6 and 7 (while being ignored by sane browsers) and bumps the legend back over where it should be. I’m using the star-property hack here because it makes the source a lot less verbose; however, you should probably migrate that rule into an IE-specific stylesheet behind a conditional comment.

There is also one more IE-specific adjustment that you have to make thanks to the seven pixel indent. When calculating its box model, IE 6 will determine the width of the legend and add the seven pixel indent before shifting the legend to the left. Long and short of it is that the parent element will be bumped out seven pixels wider than it should be, so you’ll need to give the span a width seven pixels less than your target width for IE 6. For instance, to make the code above work in IE 6 I would add an IE 6 conditional comment with legend span { width: 393px; } inside somewhere.

And that’s it! You will, of course, want to be using an intelligent CSS reset (I recommend Eric Meyer’s CSS reset), but otherwise the above CSS should give you a legend element that acts like a block-level element instead of some weird border-loving pseudo-element with wrapping issues.

There are some further gotchas to be aware of if you start playing around with legends. IE by default colors all legends blue, for instance, and if you want the legend to overlay the fieldset border (or not) you’ll need to go about things slightly differently. However, if you’ve been frustrated by the inability to get your legends to behave like display: block means something, hopefully this snippet will help you out.

As is usually the case, I discovered this particular combination of HTML and CSS by taking previous solutions, mixing them into a putrescent green cocktail, and force-feeding it to my browsers, tweaking the constituent ingredients until they were saying “Mmm, tasty!” instead of puking a bunch of crap all over my lovely webpage. Specifically, John Faulds provided some basic concepts and examples for styling legends and Stephanie Sullivan wrote up the strategies for encouraging legend wrapping in Firefox 2 and 3. Thanks, guys; you rock.

If you want to see the code in action with various permutations for More Pretty, check out this page o’ examples.

This week’s A List Apart included Understanding Progressive Enhancement by Aaron Gustafson. I was pretty jazzed to read the article, because I’ve been hoping for a simple explanation of progressive enhancement to show my supervisor for some time.

Unfortunately, after reading Understanding Progressive Enhancement I realized that the article didn’t actually define progressive enhancement. It had a great description of the concept of graceful degradation, but when it got to progressive enhancement it became abstract to the point that I don’t think someone who isn’t already passingly familiar with the idea would understand it.

I am not a mover and thinker when it comes to web design and development, but at the least I can offer a complementary explanation for Gustafson’s workflow-oriented description.

As Gustafson says, graceful degradation focuses on building out a great site, and then testing on older browsers and tweaking things to make sure the users have at least a half-assed experience.

Progressive enhancement has very similar results (cutting-edge users get the best experience, users with older or otherwise limited technology get a less ideal experience), but comes from a different angle. Gustafson says that progressive enhancement is all about the content, and then goes into a long, slightly flawed metaphor about Peanut M&Ms. Mildly wonky metaphor aside, he’s right about content being the important thing; he just needs a succinct definition and concrete examples.

Progressive enhancement is the idea that you should design your content in a way that is accessible no matter how your users access your site, and then add Javascript interactions and advanced CSS afterwards to make the lives of people who have capable browsers easier and more beautiful.

For me, I find this best illustrated with a pair of examples.

I have two sites I have been working on recently. For both of them I am the interface coder; I receive Photoshop designs, and am responsible for building them in HTML, CSS, and enough PHP to tie into the developer’s backend. The first project is a Web 2.0 startup that I inherited from a previous developer. The second was designed by a professional print and web design house and handed off to me for conversion to HTML.

For the first site, the code I inherited uses a lot of Javascript to make the interactions work. The user enters the site, types some information, and things swoop across the screen to quickly lead them through what the site has to offer before depositing them on a signup form. If the user has Javascript disabled links don’t work, the form fields remain populated with filler text (apparently a background image), and the user never sees the signup form. This site was designed for (eventual) graceful degradation. The designers and coder took their perfect world vision and implemented it, and were planning to go back over everything once it was done to make sure that some semblance of a workflow would exist in older browsers or browsers that don’t support Javascript.

For the second site, the designers provided me not only with the Photoshop files, but with a complete user experience description. The user experience description included a semi-interactive Flash file on the homepage, an automatically scrolling list of article titles that reacted to mouse movements, and other bells and whistles. First, I built out the in HTML and CSS and once I had tested everything I added the Flash and Javascript interactions (making sure that should those technologies not be present the site would fallback to my original vanilla designs).

This second approach is a limited example of coding using the idea of progressive enhancement. I knew that what was important was that no matter what technology the user had available, they should be able to reach the content, so in my first iteration of code all links lead somewhere, all navigation elements were present, and even a user with a stripped-down mobile browser would be able to navigate and read the site (even if it looked terrible). The Javascript and Flash thus enhance the user’s experience, but are not necessary for the user to experience the basic content and interactions the site has to offer.

The problems with graceful degradation in the first site should be self-evident. By focusing solely on making their interactions slick and perfect immediately, the first coder crippled the site for any number of users. Content delivery in all situations isn’t the focus; instead “fixing” old browsers will eventually be the focus.

The reason progressive enhancement is an important idea for web designers to get their heads around is that if you use progressive enhancement to guide your design you don’t have to patch obvious failings but instead build an ever-improving user experience on a solid foundation. Not all browsers may look and feel the same, but regardless of the tools at their disposal users will be able to access and interact with your site’s content in ways that were part of your overall design. Even if they can’t articulate it, users can tell when their experience is an afterthought rather than a priority, and as a result you only stand to gain.

Cuil, a newly released search engine, is extremely interesting. I love the multiple column approach (perfect for today’s widescreen monitors), and the idea of sorting by relevance rather than popularity (even if it’s a total pipe dream) is something I can get behind. I’m happy to find that it’s a lot simpler than Google, too, which is great. Google is easy, but Cuil is way easier (and more helpful when it comes to constructing queries).

That said, I did a vanity search for “beckism” (though I sometimes am tempted to vanity search my name, it’s always useless thanks to another, rather more famous Ian Beck; the fame doesn’t bother me, but what really pisses me off is that he’s an author and writes fantasy, which means if and when I’m able to get published I won’t even be able to use my own name). In any case, it turned up an interesting result:

Aside from the fact that the link (and as a result their index) is woefully out of date (I redesigned the blog back in February, which was when I changed my link structure), I’m curious how that image got associated with Dirt Man. It’s clearly some sort of clothing accessory, but aside from the fact that it’s an image that has never been on my servers, why on earth would it be associated with my site? I don’t sell clothing. I don’t even like clothing. Well. It’s nice when it keeps off the rain, I suppose.

I want to love Cuil, but it definitely has some kinks to work out.

In other news, the last time I updated Dirt Man was February 2006. Jesus. No wonder no one ever reads it.

This is a pretty simple tip, but when I was looking around online I couldn’t find any information about it.

If you’re using FeedBurner (or some other feed that you don’t have direct control over) and you want your site’s favorite icon (often called a favicon, typically favicon.ico) to show up in association with the feed, stick it in the directory that the feed directs visitors to (this is usually your root directory).

I’d been wondering why my Tagamac and Beckism.com favorite icons weren’t showing up for anything except my browser; copying the favicon.ico file to the root directy of my website solved the problem.

If you control your RSS feed, of course, you can directly reference an image to be included with it instead of relying on auto-detection.

Down for everyone or just me asks a simple question: Is [_____] down for everyone or just me?

I will definitely be using this service. I just wish it has some sort of explanation about what’s going on behind the scenes, since as things are you pretty much have to take it on faith.

Chyrp’s installation instructions are worthless, and the installation script’s errors even worse. If you’re trying to install Chyrp and getting “Could not modify database settings file” errors, make sure that you’ve followed all of these steps:

• If you don’t already have a database ready for Chyrp, set one up and make sure you have the details on hand (host/database/user/password).
• Unzip the package and upload the files to the desired location on your server.
• In your FTP program, open up the includes folder and change the files named config.yaml.stock and database.yaml.stock to config.yaml.php and database.yaml.php respectively. Set both files’ access permissions to 777 (read/write/execute for everyone).
• You may also need to rename chyrp.htaccess to .htaccess and give it 777 permissions, as well. There were conflicting reports online, and I did it just in case.
• Navigate to Chyrp’s install.php script in your browser, and follow the instructions. This will probably be somewhere like http://yourserver.com/chyrp/install.php.
• Delete the install.php file with your FTP client once you’ve finished.

That should get Chyrp up and running! Hopefully one of these days there will be some useful installation instructions included with the download. For such an easy process, it sure was difficult to figure out.

Update: I had an opportunity to install Chyrp again, and you do indeed need to rename .htaccess and make it writable or you’ll get an error about Chyrp not being able to write to the .htaccess file. Please note that these instructions are for Chyrp 1.1.3.2. They may or may not apply to future versions of Chyrp.

Wow. Like others around the web, I am shocked to learn that IE 8 will render pages in standards-compliant mode by default; Microsoft has spoken out and reversed their decision to have IE 8 require a meta tag for standards mode.

This is so mind-boggling that it’s hard for me to process. Microsoft is giving improved web standards priority over backwards compatibility and, more importantly, listening to the developer community (many of whom spoke out vehemently against IE 8’s proposed requirement of a meta tag to operate in standards mode). Thank you, Microsoft. I’m really happy to know that you’re actively working to support web standards, and especially that you’re willing to listen to the community.

HarperCollins has a web program called Browse Inside that allows you to browse books on your computer before buying them. Although most of the books in the program offer 20% of the book for your reading pleasure, HarperCollins is testing the effect on sales of offering full text versions. For the next month (March 2008) you can read Neil Gaiman’s American Gods for free, along with a number of other titles that don’t excite me as much.

If you’ve never read American Gods, this is a fantastic opportunity. It’s a wonderful book, and the Browse Inside application is pretty slick. For iPhone users, there is also a version of Browse Inside specially formatted for your phone.

Go. Read. Enjoy.

What is the coolest 3D browser game using the Unity plugin you’ve played recently? Was it Off-Road Velociraptor Safari? Yeah, I thought so.

Who doesn’t like running over velociraptors in an off-road jeep? Freaking hilarious.