A few nights ago, I received an email from Editor of EdenFantasys’s SexIs Magazine, Judy Cole, asking me to modify this Kink On Tap brief I published that cites Lorna D. Keach’s writing. Judy asked me to “provide attribution and a link back to” SexIs Magazine. An ordinary enough request soon proved extraordinarily unethical when I discovered that EdenFantasys has invested a staggering amount of time and money to develop and implement a technology platform that actively denies others the courtesy of link reciprocity, a courtesy on which the ethical Internet is based.

While what they’re doing may not be illegal, EdenFantasys has proven itself to me to be an unethical and unworthy partner, in business or otherwise. Its actions are blatantly hypocritical, as I intend to show in detail in this post. Taking willful and self-serving advantage of those not technically savvy is a form of inexcusable oppression, and none of us should tolerate it from companies who purport to be well-intentioned resources for a community of sex-positive individuals.

For busy or non-technical readers, see the next section, Executive Summary, to quickly understand what EdenFantasys is doing, why it’s unethical, and how it affects you whether you’re a customer, a contributor, or a syndication partner. For the technical reader, the Technical Details section should provide ample evidence in the form of a walkthrough and sample code describing the unethical Search Engine Optimization (SEO) and Search Engine Marketing (SEM) techniques EdenFantasys, aka. Web Merchants, Inc., is engaged in. For anyone who wants to read further, I provide an Editorial section in which I share some thoughts about what you can do to help combat these practices and bring transparency and trust—not the sabotage of trust EdenFantasys enacts—to the market.

EXECUTIVE SUMMARY

Internet sex toy retailer Web Merchants, Inc., which bills itself as the “sex shop you can trust” and does business under the name EdenFantasys, has implemented technology on their websites that actively interferes with contributors’ content, intercepts outgoing links, and alters republished content so that links in the original work are redirected to themselves. Using techniques widely acknowledged as unethical by Internet professionals and that are arguably in violation of major search engines’ policies, EdenFantasys’s publishing platform has effectively outsourced the task of “link farming” (a questionable Search Engine Marketing [SEM] technique) to sites with which they have “an ongoing relationship,” such as AlterNet.org, other large news hubs, and individual bloggers’ blogs.

Articles published on EdenFantasys websites, such as the “community” website SexIs Magazine, contain HTML crafted to look like links, but aren’t. When visited by a typical human user, a program written in JavaScript and included as part of the web pages is automatically downloaded and intercepts clicks on these “link-like” elements, fetching their intended destination from the server and redirecting users there. Due to the careful and deliberate implementation, the browser’s status bar is made to appear as though the link is legitimate, and that a destination is provided as expected.

For non-human visitors, including automated search engine indexing programs such as Googlebot, the “link” remains non-functional, making the article a search engine’s dead-end or “orphan” page whose only functional links are those whose destination is EdenFantasys’s own web presence. This makes EdenFantasys’ website(s) a self-referential black hole that provides no reciprocity for contributors who author content, nor for any website ostensibly “linked” to from article content. At the same time, EdenFantasys editors actively solicit inbound links from individuals and organizations through “link exchanges” and incentive programs such as “awards” and “free” sex toys, as well as syndicating SexIs Magazine content such that the content is programmatically altered in order to create multiple (real) inbound links to EdenFantasys’s websites after republication on their partner’s media channels.

How EdenFantasys’s unethical practices have an impact on you

Regardless of who you are, EdenFantasys’s unethical practices have a negative impact on you and, indeed, on the Internet as a whole.

• If you’re an EdenFantasys employee, people will demand answers from you regarding the unethical practices of your (hopefully former) employer. While you are working for EdenFantasys, you’re seriously soiling your reputation in the eyes of ethical Internet professionals. Ignorance is no excuse for the lack of ethics on the programmers’ part, and it’s a shoddy one for everyone else; you should be aware of your company’s business practices because you represent them and they, in turn, represent you.
• If you’re a partner or contributor (reviewer, affiliate, blogger), while you’re providing EdenFantasys with inbound links or writing articles for them and thereby propping them up higher in search results, EdenFantasys is not returning the favor to you (when they are supposed to be doing so). Moreover, they’re attaching your handle, pseudonym, or real name directly to all of their link farming (i.e., spamming) efforts. They look like they’re linking to you and they look like their content is syndicated fairly, but they’re actually playing dirty. They’re going the extra mile to ensure search engines like Google do not recognize the links in articles you write. They’re trying remarkably hard to make certain that all roads lead to EdenFantasys, but none lead outside of it; no matter what the “link,” search engines see it as stemming from and leading to EdenFantasys. The technically savvy executives of Web Merchants, Inc. are using you without giving you a fair return on your efforts. Moreover, EdenFantasys is doing this in a way that preys upon people’s lack of technical knowledge—potentially your own as well as your readership’s. Do you want to keep doing business with people like that?
• If you’re a customer, you’re monetarily supporting a company that essentially amounts to a glorified yet subtle spammer. If you hate spam, you should hate the unethical practices that lead to spam’s perpetual reappearance, including the practices of companies like Web Merchants, Inc. EdenFantasys’s unethical practices may not be illegal, but they are unabashedly a hair’s width away from it, just like many spammers’. If you want to keep companies honest and transparent, if you really want a “sex shop you can trust,” this is relevant to you because EdenFantasys is not it. If you want to purchase from a retailer that truly strives to offer a welcoming, trustworthy community for those interested in sex positivity and sexuality, pay close attention and take action. For ideas about what you can do, please see the “What you can do” section, below.
• If you’ve never heard about EdenFantasys before, but you care about a fair and equal-opportunity Internet, this is relevant to you because what EdenFantasys is doing takes advantage of non-tech-savvy people in order to slant the odds of winning the search engine game in their favor. They could have done this fairly, and I personally believe that they would have succeeded. Their sites are user-friendly, well-designed, and solidly implemented. However, they chose to behave maliciously by not providing credit where credit is due, failing to follow through on agreements with their own community members and contributors, and sneakily utilizing other publishers’ web presences to play a very sad zero-sum game that they need not have entered in the first place. In the Internet I want, nobody takes malicious advantage of those less skilled than they are because their own skill should speak for itself. Isn’t that the Internet and, indeed, the future you want, too?

TECHNICAL DETAILS

What follows is a technical exploration of the way the EdenFantasys technology works. It is my best-effort evaluation of the process in as much detail as I can manage within strict self-imposed time constraints. If any of this information is incorrect, I’d welcome any and all clarifications provided by the EdenFantasys CTO and technical team in an appropriately transparent, public, and ethical manner. (You’re welcome—nay, encouraged—to leave a comment.)

Although I’m unconvinced that EdenFantasys understands this, it is the case that honesty is the best policy—especially on the Internet, where everyone has the power of “View source.”

The “EF Framework” for obfuscating links

Article content written by contributors on SexIs Magazine pages is published after all links are replaced with a <span> element bearing the class of linklike and a unique id attribute value. This apparently happens across any and all content published by Web Merchants, Inc.’s content management system, but I’ll be focusing on Lorna D. Keach’s post entitled SexFeed:Anti-Porn Activists Now Targeting Female Porn Addicts for the sake of example.

These fake links look like this in HTML:

And according to Theresa Flynt, vice president of marketing for Hustler video, <span class="linklike" ID="EFLink_68034_fe64d2">female consumers make up 56% of video sales.</span>

This originally published HTML is what visitors without JavaScript enabled (and what search engine indexers) see when they access the page. Note that the <span> is not a real link, even though it is made to look like one. (See Figure 1; click it to enlarge.)

Figure 1:

In a typical user’s browser, when this page is loaded, a JavaScript program is executed that mutates these “linklike” elements into <a> elements, retaining the “linklike” class and the unique id attribute values. However, no value is provided in the href (link destination) attribute of the <a> element. See Figure 2.

Figure 2:

The JavaScript program is downloaded in two parts from the endpoint at http://cdn3.edenfantasys.com/Scripts/Handler/jsget.ashx. The first part, retrieved in this example by accessing the URI at http://cdn3.edenfantasys.com/Scripts/Handler/jsget.ashx?i=jq132_cnf_jdm12_cks_cm_ujsn_udm_stt_err_jsdm_stul_ael_lls_ganl_jqac_jtv_smg_assf_agrsh&v_14927484.12.0, loads the popular jQuery JavaScript framework as well as custom code called the “EF Framework”.

The EF Framework contains code called the DBLinkHandler, an object that parses the <span> “linklike” elements (called “pseudolinks” in the EF Framework code) and retrieves the real destination. The entirety of the DBLinkHandler object is shown in code listing 1, below. Note the code contains a function called handle that performs the mutation of the <span> “linklike” elements (seen primarily on lines 8 through 16) and, based on the prefix of each elements’ id attribute value, two key functions (BuildUrlForElement and GetUrlByUrlID, whose signatures are on lines 48 and 68, respectively) interact to set up the browser navigation after responding to clicks on the fake links.

var DBLinkHandler = {
    pseudoLinkPrefix: "EFLink_",
    generatedAHrefPrefix: "ArtLink_",
    targetBlankClass: "target_blank",
    jsLinksCssLinkLikeClass: "linklike",
    handle: function () {
        var pseudolinksSpans = $("span[id^='" + DBLinkHandler.pseudoLinkPrefix + "']");
        pseudolinksSpans.each(function () {
            var psLink = $(this);
            var cssClass = $.trim(psLink.attr("class"));
            var target = "";
            var id = psLink.attr("id").replace(DBLinkHandler.pseudoLinkPrefix, DBLinkHandler.generatedAHrefPrefix);
            var href = $("<a></a>").attr({
                id: id,
                href: ""
            }).html(psLink.html());
            if (psLink.hasClass(DBLinkHandler.targetBlankClass)) {
                href.attr({
                    target: "_blank"
                });
                cssClass = $.trim(cssClass.replace(DBLinkHandler.targetBlankClass, ""))
            }
            if (cssClass != "") {
                href.attr({
                    "class": cssClass
                })
            }
            psLink.before(href).remove()
        });
        var pseudolinksAHrefs = $("a[id^='" + DBLinkHandler.generatedAHrefPrefix + "']");
        pseudolinksAHrefs.live("mouseup", function (event) {
            DBLinkHandler.ArtLinkClick(this)
        });
        pseudolinksSpans = $("span[id^='" + DBLinkHandler.pseudoLinkPrefix + "']");
        pseudolinksSpans.live("click", function (event) {
            if (event.button != 0) {
                return
            }
            var psLink = $(this);
            var url = DBLinkHandler.BuildUrlForElement(psLink, DBLinkHandler.pseudoLinkPrefix);
            if (!psLink.hasClass(DBLinkHandler.targetBlankClass)) {
                RedirectTo(url)
            } else {
                OpenNewWindow(url)
            }
        })
    },
    BuildUrlForElement: function (psLink, prefix) {
        var psLink = $(psLink);
        var sufix = psLink.attr("id").toString().substring(prefix.length);
        var id = (sufix.indexOf("_") != -1) ? sufix.substring(0, sufix.indexOf("_")) : sufix;
        var url = DBLinkHandler.GetUrlByUrlID(id);
        if (url == "") {
            url = EF.Constants.Links.Url
        }
        var end = sufix.substring(sufix.indexOf("_") + 1);
        var anchor = "";
        if (end.indexOf("_") != -1) {
            anchor = "#" + end.substring(0, end.lastIndexOf("_"))
        }
        url += anchor;
        return url
    },
    ArtLinkClick: function (psLink) {
        var url = DBLinkHandler.BuildUrlForElement(psLink, DBLinkHandler.generatedAHrefPrefix);
        $(psLink).attr("href", url)
    },
    GetUrlByUrlID: function (UrlID) {
        var url = "";
        UrlRequest = $.ajax({
            type: "POST",
            url: "/LinkLanguage/AjaxLinkHandling.aspx",
            dataType: "json",
            async: false,
            data: {
                urlid: UrlID
            },
            cache: false,
            success: function (data) {
                if (data.status == "Success") {
                    url = data.url;
                    return url
                }
            },
            error: function (xhtmlObj, status, error) {}
        });
        return url
    }
};

Once the mutation is performed and all the content “links” are in the state shown in Figure 2, above, an event listener has been bound to the anchors that captures a click event. This is done using prototypal extension, aka. classic prototypal inheritance, in another part of the code, the live function on line 2,280 of the (de-minimized) jsget.ashx program, as shown in code listing 2, here:

        live: function (G, F) {
            var E = o.event.proxy(F);
            E.guid += this.selector + G;
            o(document).bind(i(G, this.selector), this.selector, E);
            return this
        },

At this point, clicking on one of the “pseudolinks” triggers the EF Framework to call code set up by the GetUrlByUrlID function from within the DBLinkHandler object, initiating an XMLHttpRequest (XHR) connection to the AjaxLinkHandling.aspx server-side application. The request is an HTTP POST containing only one parameter, called urlid, and its value matches a substring from within the id value of the “pseudolinks.” In this example, the id attribute contains a value of EFLink_68034_fe64d2, which means that the unique ID POST’ed to the server is 68034. This is shown in Figure 3, below.

Figure 3:

The response from the server, shown in Figure 4, is also simple. If successful, the intended destination is retrieved by the GetUrlByUrlID object’s success function (on line 79 of Code Listing 1, above) and the user is redirected to that web address, as if the link was a real one all along. The real destination, in this case to CNN.com, is thereby only revealed after the XHR request returns a successful reply.

Figure 4:

All of this obfuscation effectively blinds machines such as the Googlebot who are not JavaScript-capable from seeing and following these links. It deliberately provides no increased Pagerank for the link destination (as a real link would normally do) despite being “linked to” from EdenFantasys’s SexIs Magazine article. While the intended destination in this example link was at CNN.com, it could just as easily have been—and is, in other examples—links to the blogs of EdenFantasys community members and, indeed, everyone else linked to from a SexIs Magazine article or potentially any website operated by Web Merchants, Inc. that makes use of this technology.

The EdenFantasys Outsourced Link-Farm

In addition to creating a self-referential black hole with no gracefully degrading outgoing links, EdenFantasys also actively performs link-stuffing through its syndicated content “relationships,” underhandedly creating an outsourced and distributed link-farm, just like a spammer. The difference is that this spammer (Web Merchants, Inc. aka EdenFantasys) is cleverly crowd-sourcing high-value, high-quality content from its own “community.”

Articles published at SexIs Magazine are syndicated in full to other large hub sites, such as AlterNet.org. Continuing with the above example post by Lorna D. Keach, Anti-Porn Activists Now Targeting Female Porn Addicts, we can see that this content was republished on AlterNet.org shortly after original publication through EdenFantasys’ website on May 3^rd at http://www.alternet.org/story/146774/christian_anti-porn_activists_now_targeting_female_. However, a closer look at the HTML code of the republication shows that each and every link contained within the article points to the same destination: the same article published on SexIs Magazine, as shown in Figure 5.

Figure 5:

Naturally, these syndicated links provided to third-party sites by EdenFantasys are real and function as expected to both human visitors and to search engines indexing the content. The result is “natural,” high-value links to the EdenFantasys website from these third-party sites; EdenFantasys doesn’t merely scrounge pagerank from harvesting the sheer number of incoming links, but as each link’s anchor text is different, they are setting themselves up to match more keywords in search engine results, keywords that the original author likely did not intend to direct to them. Offering search engines the implication that EdenFantasys.com contains the content described in the anchor text, when in fact EdenFantasys merely acts as an intermediary to the information, is very shady, to say the least.

In addition to syndication, EdenFantasys employs human editors to do community outreach. These editors follow up with publishers, including individual bloggers (such as myself), and request that any references to published material provide attribution and a link back to us, to use the words of Judy Cole, Editor of SexIs Magazine in an email she sent to me (see below), and presumably many others. EdenFantasys has also been known to request “link exchanges,” and offer incentive programs that encouraged bloggers to add the EdenFantasys website to their blogroll or sidebar in order to help raise both parties search engine ranking, when in fact EdenFantasys is not actually providing reciprocity.

More information about EdenFantasys’s unethical practices, which are not limited to technical subterfuge, can be obtained via AAGBlog.com.

EDITORIAL

It is unsurprising that the distributed, subtle, and carefully crafted way EdenFantasys has managed to crowd-source links has (presumably) remained unpenalized by search engines like Google. It is similarly unsurprising that nontechnical users such as the contributors to SexIs Magazine would be unaware of these deceptive practices, or that they are complicit in promoting them.

This is no mistake on the part of EdenFantasys, nor is it a one-off occurrence. The amount of work necessary to implement the elaborate system I’ve described is also not even remotely feasible for a rogue programmer to accomplish, far less accomplish covertly. No, this is the result of a calculated and decidedly underhanded strategy that originated from the direction of top executives at Web Merchants, Inc. aka EdenFantasys.

It is unfortunate that technically privileged people would be so willing to take advantage of the technically uneducated, particularly under the guise of providing a trusted place for the community which they claim to serve. These practices are exactly the ones that “the sex shop you can trust” should in no way support, far less be actively engaged in. And yet, here is unmistakable evidence that EdenFantasys is doing literally everything it can not only to bolster its own web presence at the cost of others’, but to hide this fact from its understandably non-tech-savvy contributors.

On a personal note, I am angered that I would be contacted by the Editor of SexIs Magazine, and asked to properly “attribute” and provide a link to them when it is precisely that reciprocity which SexIs Magazine would clearly deny me (and everyone else) in return. It was this request originally received over email from Judy Cole, that sparked my investigation outlined above and enabled me to uncover this hypocrisy. The email I received from Judy Cole is republished, in full, here:

From: Judy Cole <luxuryholmes@gmail.com>
Subject: Repost mis-attributed
Date: May 17, 2010 2:42:00 PM PDT
To: kinkontap+viewermail@gmail.com
Cc: Laurel <laurelb@edenfantasys.com>

Hello Emma and maymay,

I am the Editor of the online adult magazine SexIs (http://www.edenfantasys.com/sexis/). You recently picked up and re-posted a story of ours by Lorna Keach that Alternet had already picked up:

http://kinkontap.com/?s=alternet

We were hoping that you might provide attribution and a link back to us, citing us as the original source (as is done on Alternet, with whom we have an ongoing relationship), should you pick up something of ours to re-post in the future.

If you would be interested in having us send you updates on stories that might be of interest, I would be happy to arrange for a member of our editorial staff to do so. (Like your site, by the way. TBK is one of our regular contributors.)

Thanks and Best Regards,

Judy Cole
Editor, SexIs

Judy’s email probably intended to reference the new Kink On Tap briefs that my co-host Emma and I publish, not a search result page on the Kink On Tap website. Specifically, she was talking about this brief: http://KinkOnTap.com/?p=676. I said as much in my reply to Judy:

Hi Judy,

The URL in your email doesn’t actually link to a post. We pick up many stories from AlterNet, as well as a number from SexIs, because we follow both those sources, among others. So, did you mean this following entry?

http://KinkOnTap.com/?p=676

If so, you should know that we write briefs as we find them and provide links to where we found them. We purposefully do not republish or re-post significant portions of stories and we limit our briefs to short summaries in deference to the source. In regards to the brief in question, we do provide attribution to Lorna Keach, and our publication process provides links automatically to, again, the source where we found the article. :) As I’m sure you understand, this is the nature of the Internet. Its distribution capability is remarkable, isn’t it?

Also, while we’d absolutely be thrilled to have you send us updates on stories that might be of interest, we would prefer that you do so in the same way the rest of our community does: by contributing to the community links feed. You can find detailed instructions for the many ways you can do that on our wiki:

http://wiki.kinkontap.com/wiki/Community_links_feed

Congratulations on the continued success of SexIs.

Cheers,
-maymay

At the time when I wrote the email replying to Judy, I was perturbed but could not put my finger on why. Her email upset me because she seemed to be suggesting that our briefs are wholesale “re-posts,” when in fact Emma and I have thoroughly discussed attribution policies and, as mentioned in my reply, settled on a number of practices including a length limit, automated back linking (yes, with real links, go see some Kink On Tap briefs for yourself), and clearly demarcating quotes from the source article in our editorializing to ensure we play fair. Clearly, my somewhat snarky reply betrays my annoyance.

In any event, this exchange prompted me to take a closer look at the Kink On Tap brief I wrote, at the original article, and at the cross-post on AlterNet.org. I never would have imagined that EdenFantasys’s technical subterfuge would be as pervasive as it has proven to be. It’s so deeply embedded in the EdenFantasys publishing platform that I’m willing to give Judy the benefit of the doubt regarding this hypocrisy because she doesn’t seem to understand the difference between a search query and a permalink (something any laymen blogger would grok). This is apparent from her reply to my response:

From: Judy Cole <luxuryholmes@gmail.com>
Subject: Re: Repost mis-attributed
Date: May 18, 2010 4:57:59 AM PDT
[…redundant email headers clipped…]

Funny, the URL in my email opens the same link as the one you sent me when I click on it.

Maybe if you pick up one of our stories in future, you could just say something like “so and so wrote for SexIs.” ?

As it stands, it looks as if Lorna wrote the piece for Alternet. Thanks.

Judy

That is the end of our email exchange, and will be for good, unless and until EdenFantasys changes its ways. I will from this point forward endeavor never to publish links to any web property that I know to be owned by Web Merchants, Inc., including EdenFantasys.com. I will also do my best to avoid citing any and all SexIs Magazine articles from here on out, and I encourage everyone who has an interest in seeing honesty on the Internet to follow my lead here.

As some of my friends are currently contributors to SexIs Magazine, I would like all of you to know that I sincerely hope you immediately sever all ties with any and all Web Merchants, Inc. properties, suppliers, and business partners, especially because you are friends and I think your work is too important to be sullied by such a disreputable company. Similarly, I hope you encourage your friends to do the same. I understand that the economy is rough and that some of you may have business contracts bearing legal penalties for breaking them, but I urge you to nevertheless consider looking at this as a cost-benefit analysis: the sooner you break up with EdenFantasys, the happier everyone on the Internet, including you, will be (and besides, you can loose just as much of your reputation, money, and pagerank while being happy as you can being sad).

What you can do

• If you are an EdenFantasys reviewer, a SexIs Magazine contributor, or have any other arrangement with Web Merchants, Inc., write to Judy Cole and demand that content you produce for SexIs Magazine adheres to ethical Internet publication standards. Sever business ties with this company immediately upon receipt of any non-response, or any response that does not adequately address every concern raised in this blog post. (Feel free to leave comments on this post with technical questions, and I’ll do my best to help you sort out any l33t answers.)
• EdenFantasys wants to stack the deck in Google. They do this by misusing your content and harvesting your links. To combat this effort, immediately remove any and all links to EdenFantasys websites and web presences from your websites. Furthermore, do not—I repeat—do not publish new links to EdenFantasys websites, not even in direct reference to this post. Instead, provide enough information, as I have done, so visitors to your blog posts can find their website themselves. In lieu of links to EdenFantasys, link to other bloggers’ posts about this issue. (Such posts will probably be mentioned in the comments section of this post.)
• Boycott EdenFantasys: the technical prowess their website displays does provide a useful shopping experience for some people. However, that in no way obligates you to purchase from their website. If you enjoy using their interface, use it to get information about products you’re interested in, but then go buy those products elsewhere, perhaps from the manufacturers directly.
  • On the recommendation of my friend Dr. Charlie Glickman, I suggest Good Vibrations.

  • On the recommendation of my friend Shanna Katz, I also recommend Fascinations.
• Watch for “improved” technical subterfuge from Web Merchants, Inc. As a professional web developer, I can identify several things EdenFantasys could do to make their unethical practices even harder to spot, and harder to stop. If you have any technical knowledge at all, even if you’re “just” a savvy blogger, you can keep a close watch on EdenFantasys and, if you notice anything that doesn’t sit well with you, speak up about it like I did. Get a professional programmer to look into things for you if you need help; yes, you can make a difference just by remaining vigilant as long as you share what you know and act honestly, and transparently.

If you have additional ideas or recommendations regarding how more people can help keep sex toy retailers honest, please suggest them in the comments.

Update: To report website spamming or any kind of fraud to Google, use the authenticated Spam Report tool.

Update: Google provides much more information about why the kinds of practices EdenFantasys is engaged in degrade the overall web experience for you and me. Read Cloaking, sneaky Javascript redirects, and doorway pages at the Google Webmaster Tools help site for additional SEO information. Using Google’s terminology, EdenFantasys’s unethical technology is a very skilled mix of social engineering and “sneaky JavaScript redirects.”

Introduction

First, credit where credit is due.

I learned almost everything I know about SVG from an acquaintance I met in Australia named Dmitry Baranovskiy. He is a superb client-side web developer who I helped add documentation for a brief time for one of his SVG-related projects called RaphaëlJS. I’ll show you that in a little bit.

Okay, so what is SVG?

What is SVG?

In a sentence, according to Adobe, the originators of the technology:

Scalable Vector Graphics (SVG) is a text-based graphics language that describes images with vector shapes, text, and embedded raster graphics.

What does that mean?

• Scalable means that the technology is natively resolution-independent.
• Vector means that image data is described using relative mathematical coordinates:
  • 
  • 
• Graphics means that it’s used to create images, but also means it natively supports bitmapped graphics, and videos, using <foreignObject>.

But wait, there’s ”more”.

Why use SVG?

• It’s text-based, which means it’s highly searchable. Remember SEO in the heyday of the “Flash website”? Now Flash has all kinds of meta attributes to provide extra SEO oomph, but if we had just used SVG in the first place, we wouldn’t have had this problem.
  • That means we also get custom fonts, for free.
  • Oh, and it’s super accessible, too.
• Mobile support: SVG comes in a few flavors that are all interoperable with each other in order to define different levels of support. Whereas Flash is monolithic, SVG comes in profiles that support low-end devices with reasonable quality while still providing high-fidelity content. Just like the Web was designed to do.
  • Don’t believe me? Watch this: Raphaël Rotation on iPod touch
• Easy to learn: there isn’t much new here because it uses everything you already know about XML, CSS, and JavaScript to provide every feature it has. That’s right, you can use plain old HTML for your page content, add some CSS to style it and the SVG, and then JavaScript to script it. “The trifecta” just added another dimension.
• And, if you care about such things, SVG has been an open standard well before Flash was.

Browser support

• Opera has full support and has had some amount of support since Opera 8.
• Gecko has had increasing support since 2005.
• WebKit has had increasing support since 2006.
• Internet Explorer (still) has no native support. We hate you, Internet Explorer. (That said, however, Microsoft has just recently joined the W3C‘s SVG Working group, so there may yet be some hope.)

What can we do about IE today?

Here is the breakdown of options we have to deal with IE‘s frustrating lack of support.

• Rely on HTTP content negotiation to serve SVG to supporting browsers, and raster images to Internet Explorer. Works great, except now we’re still using raster images, so basically it feels like 1995 again. It’s also what Wikipedia does.
• Use plugins. Adobe has had one forever called the Adobe SVG Viewer. It’s pretty good…but it’s a plugin. I’m not sure how Flash got away with also being a plugin, but whatever.
• Relent and use Flash on the client-side, but revel in delicious SVG pureness for our source files: Using SVG Path Data in Flash.
• Use a cross-browser API. Turns out, there are quite a few:
  • SVG in The Dojo Toolkit – Early and solid, but it uses Dojo (and we don’t).
  • svgweb – Google’s experimental library. It’s got the biggest hyperight now.
  • RaphaëlJS, written by my acquaintance Dmitry Baranovskiy and, of course, my favorite cross-browser SVG toolkit. Since it’s stand-alone, you can actually mix-and-match with your favorite JavaScript framework. In other words, you take your pick of jQuery, YUI, Prototype, or whatever, and layer RaphaëlJS on top for all your SVG-related work. Now that’s creamy.

How do SVG-writing JS frameworks work?

1. Provides a cross-browser JavaScript API (think jQuery) for writing SVG commands.
2. Writes to the DOM based on your Raphaël commands:
   • Writes SVG to supporting browsers.
   • Writes VML¹ to Internet Explorer.
3. Makes you coffee.

Hype it up

• Sun Labs’ Lively Kernel – A full “web OS” implemented in native SVG and JavaScript (no frameworks). Like SmallTalk, you can actually change the runtime environment yourself by editing JavaScript within the environment. Now that’s meta.
• Ajax and PHP SVG Demo: Realtime Charting

Sources and additional resources

• SVG Is The Future Of Application Development – Describes other awesome uses of SVG.
• Start Using Web Vector Graphics Today – Web Directions South presentation by Dmitry Baranovskiy.
• SVG – a slideshow overview by Dmitry Baranovskiy.
• SVG Intro on W3Schools.com. (Quick ‘n’ dirty and not highly recommended, but an oft-cited reference so you might as well know it exists.)

1. VML is Microsoft’s proprietary, non-standard Vector Markup Language. It’s basically the exact same thing as SVG, but only works in Internet Explorer. Because whereas Apple only thinks differently, Microsoft has to do it differently. We hate you, Microsoft.

Social media. Internet publishing. Privacy. Three phrases that have seemed to be at tenacious odds with each other in a multitude of subtle and not-so-subtle ways. For people like me, who have progressive views about sexuality, these three things are constantly on our minds. How do we participate in the online revolution without being forced to “come out” about every sex act we enjoy, some of which are still illegal thanks to draconian restrictions on sexual freedom, even (and especially?) in America.

This month, a new social network called Blackbox Republic (BBR) is attempting to tackle this head-on and aims to create a place for, as Marshall Kirkpatrick put it, this particular large and unserved group of people. Although BBR is clearly a business, it’s a business whose creators have laudable intentions for positive social and cultural change. In that respect, and in many others, Blackbox Republic is worth a close look.

I was informed about the venture via Clarisse Thorn many months ago. I got in touch with BBR and signed up for a limited-offer “founder” account—basically a private beta. The founder account gave me free access to the features of the BlackboxRepublic.com website for what would normally be a $25 monthly subscription fee.

So, without further ado, here are my impressions about Blackbox Republic, and how its launch may be just what the Internet needs to get us moving in the right direction with regards to personal privacy, and mainstream awareness of the different needs of different people on the Internet.

Mainstream sex-positivity or a VIP room in cyberspace? Or both?

Over the past few months, Blackbox Republic has been building a marketing arsenal of anticipation and intrigue. Its creators are successful in non-sexuality-focused spheres of influence: Sam Lawrence is the respected former Chief Marketing Officer of Jive Software, Inc., and April Donato, has experience in community management. They also both jive (pun!) well with the sex-positive movement, discussing it at length in the early stages of their marketing efforts after de-cloaking the new company.

In an interview for Social Networking Watch, Sam Lawrence said,

[Sam Lawrence:] The co-founder [April Donato] and myself are part of [the sex-positive] community. Sex positive means that your sexuality is not an issue. You don’t have an issue with other people’s sexuality. You’re open to what other people are interested in and what their boundaries are, and you’re open with your own.

[…]

[Interviewer:] To what extent do you practice a sex-positive lifestyle?

[Sam Lawrence:] From the perspective of sex not being an issue, I think that love is generated by people being open enough about who they are as people to put all of themselves out on the table. As far as putting all of myself on the table, it’s something that I do every single day.

I have an enormous amount of respect for anyone able to so capably present themselves as authentically as Sam does. On the eve of KinkForAll New York City 2, I met Sam and April at one of their “founder meetups” and had the chance to talk to them face-to-face. Our conversation revolved around the importance of steadfastly holding true to one’s own desires and having appropriate places to express those things with appropriate communication tools. I really liked their emphasis on self-identification over labeling throughout our discussion.

I also really appreciated the way that Sam and April spoke about their target audience. Blackbox Republic will welcome everyone, but it’s not designed for everyone, and I think that’s a good thing. David Evans writing at Online Dating Post says,

BBR has room for everyone, but is not for everyone. Definitely catering to non-mainstream folks, it will soon feature a constellation of micro-communities, or groups, called Camps. BBR doesn’t tell people how to organize their camps; we’ll do it ourselves, thankyouverymuch.

So is Blackbox Republic a dating site, or a social network? Well, both, kind of. Part of BBR’s slogan includes, “Dates will happen. Sex will happen. It matters how you get there.” The implication, of course, being that the current suite of tools for finding love or play online—sites like Alt.com, OkCupid, and countless personals boards—focus too strongly on the end result, turning matchmaking into a meat market instead of the natural process of getting to know one another. The focus BBR is placing on each person’s “journey” is an extremely welcome paradigm shift in the online dating world.

Along with the welcome and (IMHO, painfully obviously better) new approach to online dating, however, Blackbox Republic faces some real challenges. For new users, the service costs a minimum of $5 a month to use (and $9 per month for new sign-ups starting in 2010), which gives access to basic features like a personal profile. For $25 a month, members get added features like the ability to list real-world meet-ups, send private messages, and partake in a virtual “gifting” economy (think LiveJournal’s “virtual gifts“).

For that reason, BBR has been called a “members-only club.” There are some legitimate differences of opinion as to whether this is a positive or a negative thing. In a press release over the summer, Blackbox Republic is reported as stating:

Blackbox Republic will be a members-only experience that will unite the sex-positive community and give them a personal, private and secure way to connect online and in person.

Writing for ZDNet, Oliver Marks likens Blackbox Republic’s approach to online dating to the fashionability of owning an Apple computer:

Think of Blackbox Republic as a fashionable online ‘members-only’ club where you might expect to meet people with similar interests to your own, and ideally the person of your dreams. […] Blackbox Republic is arguably an Apple product to Facebook’s Windows look & feel: a much more intimately crafted, fuller featured personal user interface which should appeal to Apple generation sensibilities.

Many pages on Blackbox Republic's website showcase fashionably dressed women.

Indeed, almost everything about Blackbox Republic’s marketing and design seems to me as though it’s positioning itself as the equivalent of the hip, new, and exclusive nightclub down the street. There are images of super-chic women in short skirts and tight pants all over the Blackbox Republic promotional pages—way more than there are pictures of men. I was (yet again) put-off by this over-prevalence of women in all advertising material.

This isn’t really a criticism of the site, but rather a statement of disappointment that the marketing gurus behind the effort seemed to me to have succumbed to overwhelming cultural pressure to sell their site with old-school sex appeal: women’s sex appeal, of course. How…traditional.

Not only is the Blackbox Republic intro video markedly gender-skewed, but somewhere along the line Sam and April decided to drop the “sex-positive” phraseology from their marketing:

[L]ike most startups, Blackbox decided it needed to change up. Observers were confused by the sex-positive label.

Oh well. I think this just goes to further showcase how much more social change we really need in our culture.

However, while the clubby, cliquey feel is totally my own subjective perception, there are other issues at play here, too. Most notably, as Clarisse Thorn and many others rightfully remind us very often, the sex-positive movement is overwhelmingly white, middle- to upper-class, college-educated, and privileged in a huge number of ways that many people often take for granted. Even without a for-pay social network, not everyone who wants to can participate in the great-sex-for-everyone party atmosphere of many sex-positive niches.

Will creating a “members-only club” of sex-positivity on the Internet really be a positive thing for “the movement”? Well, maybe. Although it has the potential to exclude lower-income people from the experience, who are sadly also often the people with the most pressing need for the kinds of privacy-related tools BBR offers (school teachers spring to mind!), one upside is that Blacbox Republic promises to pledge a portion of membership dues to a charity of the user’s choice.

It’s $25 a month and $5 of those community dues go to charity. One way to think about it is if you’re sex-positive, you can either spend money on expensive coffee every month or upgrade your social life and meet other sex-positive people like you.

Inescapably, the major selling point of any social network is, of course, the network! If your friends aren’t on Twitter, then you’re probably not going to find it useful. The same truth holds for Blackbox Republic: if the users you want to interact with aren’t there, I doubt you’re going to find the experience fruitful. Due to the membership fees and the socioeconomic realities of the sex-positive community, I’m concerned that BBR’s current business model is too exclusive, and as a result it will have a lot of trouble attracting the kind of diverse community its creators seem to be hoping for.

Yet, some others think differently (pun!). For instance, Dennis Howlett welcomes the for-pay model for a social network:

anyone can join provided they’re willing to pay the $25 a month (I like that he has a pay model from the get go. That sorts out the weirdos and hangers on from day one)

I wonder if adopting a free-mium approach might work better. Still, there are real-world limits to business. Everyone needs to make money, and I don’t think Blackbox Republic’s business model is inherently more exclusive than, say, purchasing access to porn. If anything, BBR’s got some real promise to inject much-needed financial awareness to the sexually insensitive corporate infrastructure of our society. Nevertheless, convincing people to join “the Republic” is going to be a hard sell.

Show me the features!

Let’s say you do decide to join. What do you get? Other than the sex-positive mindset, what’s the benefit?

Well, the bulk of the experience is what you’d expect. Profiles (called “personas”), messaging, user search capabilities (called “explore”), and so forth. A Twitter-like “activity stream” dominates the main page where you can post text, picture, or video status updates. Event listings fill the sidebar. (I’m not going to provide internal screenshots in deference to BBR’s strict confidentiality rules.)

While that’s fun, it’s nothing special. What makes Blackbox Republic different is flexibility, and privacy.

Goodbye drop-downs, hello sliders!

An innovative new interface acknowledges (most of) the diversity in human sexual experience and desire.

Blackbox Republic’s most visible feature is the way its interface allows you to flexibly self-identify various facets of yourself. Rather than give you static drop-down menus or radio buttons for things like your sexual orientation and relationship status, you’re presented with sliders you can change at will. Perhaps you’re feeling particularly same-sex attracted one day. Just move the “Orientation” slider towards the “Gay” end and away from the “Hetero” end. If that changes tomorrow, just move the slider back. Sho-weet!

BBR offers you 5 different sliders for your profile. In addition to the one for sexual orientation, you also get one for relationship “status” (ranging from attached to unattached, with Facebook’s famous “it’s complicated” neatly in the middle), whether you’re available for more partners or not, how comfortable you are with casual sexual activity, and how eagerly you’re looking to par-tay. I’m instantly reminded of FetLife‘s innovative, if dull-looking, mechanism for specifying multiple relationships. Blackbox Republic gives you similar flexibility as FetLife does but presented in a superb and far more intuitive interface.

All that said, one slider is conspicuously missing: the one for gender. The sliders are a very interesting idea and might just be the most innovative feature of the entire site. It speaks volumes about the sensitive and thoughtful mindset of the developers, and that’s why I’m so disappointed that the interface for self-identifying gender is relegated to the Sex 1.0 days of a single, binary option of “male” or “female.”

What gives? Are polyamorous people more welcome here than those who don’t fit the gender binary? I hope this is simply an omission that will be fixed as the service matures, since I couldn’t find any other reason why gender was absent from the sliders. For extra credit, I hope to see different profile options for “Sex” and “Gender,” two distinct concepts that frequently and incorrectly get used interchangeably. This would make it possible to represent complex gender presentations like additive gender on a social networking interface for the first time ever, and that’d totally be something to write home about!

Privacy and security

The other major selling point of Blackbox Republic is its careful attention to privacy. The entire offering, including its name, is predicated on letting users very carefully segment their information based on their privacy boundaries. I love some of the things BBR has done to enable this, and I can only imagine it’s going to get better from here.

Blackbox Republic’s Web of Trust

There are three levels of privacy, which (as far as I can figure out) map directly to the level of trust other members have gained within the Republic’s community. It works like a web of trust. New users are “un-vouched.” As they begin to interact with others on the site and, hopefully, make some friends, they should receive “vouches”—or votes of trust—from previously-vouched members. As a member, you get to control whether something you do, such as posting a status update, gets sent to the “public,” (i.e., the entire public-facing Internet), to all Blackbox Republic members (i.e, to both vouched and un-vouched members) or only to vouched members.

Additionally, privacy settings allow you to specify whether you want to allow un-vouched members to send you private messages, to follow your updates, to comment on your posts, or to see you in search results.

Unlike Facebook, which has very good privacy controls that almost nobody on Earth is aware of (thus negating the control’s usefulness), Blackbox Republic makes it a point to highlight their privacy controls at just about every sensical turn. Each of the settings I found defaults to the most private setting, not the most public, which is exactly the right move. I gotta say, I found turning off privacy settings instead of having to turn (or leave) them on to be a really empowering feeling.

You’re not a “friend,” you’re an acquaintance!

Moreover, the Blackbox Republic platform makes a native distinction between “friends” (again, like Facebook, or FetLife) and “followers” (like Twitter). When I friend someone, I’m connected to them in a way that I’m not if I just follow someone. I’m not yet certain what the practical distinction between “friending” and “following” are, other than the fact that your view of the people you’re connected with is segmented based on which button you clicked, but I think the distinction is a very appropriate and natural one to embed in the software.

This separation is probably the single most important innovation in the space of social networks as a medium of communication and collaboration that I can point at. I love that I can indicate without ambiguity which people I want to remain in constant communication with and which I simply want to watch from a distance. After all, aren’t at least some of your “friends” on Facebook really just “acquaintances” in reality? I think that for the first time ever in a social network, Blackbox Republic gets this feature right. Now, if only I could figure out what it actually does. :)

What? No on-the-wire encryption?!

With all that being said, there’s still at least one really frightening problem with Blacbox Republic’s careful attention to privacy: as far as I could tell, no part of my session is SSL/TLS encrypted!

Stunningly, for a site that sells privacy, not even Blackbox Republic's login form is on a secure page.

The entire BlackboxRepublic.com website is served over HTTP, including the login form and—again, as far as I could tell—every page on the inside of the site. This means that it’s trivial for malicious people who don’t even have a Blackbox Republic subscription to intercept, eavesdrop, and modify my interaction with the site. They could watch—and save—private messages between me and one of my friends (or lovers!), for instance.

In Blackbox’s defense, I don’t know of any social network that protects you from this. FetLife is another example of a website that should seriously consider HTTPS-only pages, but as of this writing hasn’t implemented it. Therein lies one of the most frightening oversights in the entire social networking space: regardless of so-called privacy settings, everything you do on the vast majority of social networks, blogs, and other sites on the Internet are the equivalent of passing notes between friends in a classroom. Better hope that big bully who likes to steal your lunch money doesn’t open the note and read it himself while he’s passing along your login details!

The thing is, few other social networking sites place so strong a spotlight on user privacy and security. Since Blackbox Republic seems to be nobly and rightfully holding itself up to a new standard of privacy, I feel justified in pointing out this glaring omission in their service offering. Given everything else they’ve done so well, and how well-aligned the majority of their technical implementation seems to be with their philosophy, this omission came as a big surprise to me.

Until Blackbox Republic only serves HTTPS traffic for all private areas of their site, I can’t make a recommendation in good conscious that it’s the place to be for privacy-conscious people. But again, despite public opinion to the contrary, I’ve never been able to make that claim for FetLife either.

Conclusion

Blackbox Republic is one of the most interesting websites on the Internet today. Its privacy-conscious and sexually open approach to social networking and online dating deserves huge praise. Its technical implementation—although plagued with some glaring oversights for now—is to be seriously respected.

From a social change perspective, I think the site is a mixed bag. Its exclusivity arguably makes the insularity of the sexuality communities an even bigger problem than it already is. On the other hand, the market-value of that very same exclusivity, if steered toward a benevolent purpose, can end up benefiting philanthropic, non-profit, and other sex-positive endeavors that often struggle to find necessary financial support.

Moreover, Blackbox Republic’s internal gifting economy does seem to encourage a sort of altruistic nature among members. How that may or may not translate into increased support for non-commercial activists has yet to be seen. Nay-sayers should remember that this kind of thing simply hasn’t been done before and the net effect could be quite positive.

Having just launched, however, I don’t think Blackbox Republic should be touted as the go-to site for sex-positive people quite yet. Like other social networks, it needs to grow to become truly useful, and its subscription fee business model poses a serious obstacle to many people. I was fortunate to get in with a free “founder” account, but I have mixed feelings about encouraging my friends to join me knowing they—or someone nice enough to “gift” a limited-time subscription to them—will have to pay for the service.

Additionally, its focus on being, well, a black box and its commitment to not allow Google or other search engines to index its internal content simply doesn’t resonate that strongly with me.

Lawrence emphasizes that what members say in Blackbox Republic will stay private. There’s no danger of what they post inside becoming part of their “Google resume,” as he puts it. He says he would resist efforts from search engines to index content the way Facebook and Twitter allow. “The value proposition is this is the first private, large social network out there,” Lawrence says.

Put simply, and noting that I’m probably not the majority case here, I rely on my “Google résumé,” to use Sam’s words, to live the life I want. My lukewarm reaction to this isn’t a criticism of the goal, simply an observation that it turns out I’m not in the ideal target market for Blackbox Republic’s value proposition.

In other words, I think I’m “too out” for this site to be immediately useful to me. The fact that FetLife is not readily available to the public Internet is the single biggest reason why I don’t sign on to that site very often, and so I have the same reason not to spend all that much time behind the curtains of Blackbox Republic.

Nevertheless, many other people do. If you’re among the cross-section of the populace who’d like a sociosexual experience online and would also like to effectively outsource your social reputation management, if you will, but you feel that sites like Facebook just aren’t cutting it, then Blackbox Republic is definitely worth checking out.

If you do check it out, or even if you don’t, I’d love to know what you think in the comments. And if you’re definitely sold, consider signing up via my partner link. Full disclosure: signing up that way earns me a small commission. If you’d rather sign up but not give me a commission for the referral, just register from the front page.

The books are full-color PDF downloads, and include some really awesome titles. These are precisely the kinds of books you want as PDFs, too, since you can search through them and always keep them with you while you’re coding and looking for inspiration or a reference (even when you’re without Internet access). I couldn’t help but pounce on this deal, and I’m now the proud owner of the following books, which have all received some pretty great reviews:

• No Nonsense XML Web Development With PHP
• Build Your Own AJAX Web Applications
• The Principles of Beautiful Web Design (on Raena‘s recommendation)
• The Photoshop Anthology: 101 Web Design Tips, Tricks & Techniques
• The Art & Science Of JavaScript

In just 3.5 hours, SitePoint has managed to raise over $15,000 AUD, according to employee Kevin Yank on Twitter. And that’s just on this side of the world. All my North hemisphere friends were asleep when this was announced, but not to worry. SitePoint’s sale will last until this Friday, so there’s plenty of time to take advantage of it.

Obviously, I think you should do so. Not only are you getting some really quality content and helping disaster victims at the same time, you’re also sending a loud and clear message that companies whose humanity outshines their accounting are the ones you’re going to support. I’m thrilled to see that SitePoint is one of these human companies, and ever more thrilled to be a part of it.

Clickjacking does not rely on bugs in any software. Instead, the technique is simply an abuse of the growing graphical capabilities that advanced web standards like CSS provide to web browsers. A good introduction to clickjacking is provided by Steve Gibson and Leo Laporte on their Security Now! podcast.

As far as I’m aware, only Firefox when combined with the NoScript add-on and Internet Explorer when combined with the GuardedID product provide any measure of protection against clickjacking attacks. To date no other browser can detect, alert, or otherwise help you to avoid or mitigate the risks of clickjacking attacks.

That said, there’s gotta be something users of other browsers can do. Well, it may not be as much as what NoScript can do, but there is something: use a user style sheet to help expose common clickjacking attack attempts.

clickjane.css helps detect clickjacking attacks for all browsers

Until browser manufacturers provide built-in protections against clickjacking attacks in their software (which is arguably the best place for such logic in the first place), I’ve started putting together a user style sheet I’m calling clickjane.css that attempts to instantly reveal common clickjacking attempts. Since it’s a CSS user style sheet, this approach should be cross-browser compatible so that users of any browser including Safari, Opera, and other browsers that don’t have other means of protecting against clickjacking attacks can use it.

I’ve only recently learned about this class of exploits and so I’m not supremely well-informed on the topic. As a result, the clickjane.css file is relatively sparse and currently only reveals what I’m sure is a small set of clickjacking attmpts. However, as I research the topic further and learn more about the actual underlying HTML and CSS that clickjacking uses, I’ll be updating the clickjane.css code to reveal those attempts as well.

Naturally, contributions and assistance in any form are most welcome! Learn more about clickjane.css as well as how to use it at the Clickjane CSS Github wiki.

Before and after clickjane.css

Here are two example screenshots of a benign clickjacking demo.

1. Before:
   

   Screenshot of Safari before clickjane.css is used to expose clickjacking attempts.

2. After:
   

   Screenshot of Safari after clickjane.css is used to expose clickjacking attempts.

Good habits you should get into to mitigate clickjacking risks

Here is a list of behaviors that you should make habitual while you browse the web. Engaging in these behaviors can dramatically reduce the likelihood that you will be victimized by a clickjacking attack.

• Explicitly log out of any service you have logged in to when you are done. That log-out button is there for a reason: use it!
• Avoid providing your browser with “Auto-Complete” information for critical sites, such as your bank.
• Make sure you are running Flash Player 10 or greater, which mitigates this vulnerability for Adobe Flash content.

More resources to learn about clickjacking

• Hackademix.net – More clickjacking links to the OWASP presentation, the white paper, and a blog post showing several CSS-based exploits.

Translations of this article:

• Belorussian (thanks, Bohdan Zograf)
• Ukrainian (thanks, Alyona Lompar)

Here’s the summary of my argument.

Adding many “programmatic” features to the CSS language such as variables, macros, or flow control is a mistake. However, CSS‘s failure to simply encode visual relationships (instead of merely typographic properties)—a severe deficiency in the core language itself—requires the addition of delegation features. With the additional capability to reference an arbitrary element’s computed value regardless of its hierarchical context, CSS will be more accessible to both amateur and professional web designers, more capable, and will more forcefully promote the semantic Web and its ideals.

In this corner: CSS variables are harmful

Bert does a great job of summarizing the conclusion of his argument himself. In his essay, Bert says:

Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.

As we all know, one of the wonderful things about CSS is that the core language itself is remarkably simple. (What’s not simple is the spectacular way browser manufacturers have destroyed everyone’s hope that implementing CSS-based designs in the real world will ever be easy, but that’s a whole different can of worms.) Fundamentally, CSS‘s syntax can be explained with a mere three major components: property/value pairs, declaration blocks, and rule sets.

What this means is that CSS as a language is stupidly easy to learn. I think everyone would agree that it’s certainly easier to learn than, say, JavaScript or XSL. Now, that’s important because, without putting too fine a point on it, Bert mentions multiple times that CSS‘s “intended audience” are the diverse and likely relatively technically ignorant content authors that are responsible for the overwhelming majority of web pages on the public Internet today.

He makes the very good point that The value of the semantic Web isn’t defined by how well structured the best documents are, but by how well structured the vast majority of documents are. In other words, CSS needs to remain instantly useable and reusable to these untrained, amateur web content publishers for the benefits of self-describing documents (i.e., the semantic Web) to see mass adoption.

To wit:

reusing other people’s style sheets is more difficult if those style sheets contain user-defined names. Class names are an example. Their names may suggest why the author created them (assuming they are in a language you understand), but typically you will have to look at the document to see where they occur and why. Symbolic constants make that problem worse.

And, later:

For many people, style sheets with constants will thus simply not be usable. It is too difficult to look in two places at once, the place where a value is used and the place where it is defined, if you don’t know why the rule is split in this way. Many people are confused by indirection anyway and adding an extra one, in addition to the element and class names, has the same effect as obfuscating the style sheet.

Whether or not you believe Bert Bos is underestimating the average web designer, it’s pretty clear that these are really good points. Nobody wants CSS to be obfuscated, hard to learn, or hard to reuse. That’d just be crazy talk.

In the other corner: CSS variables are a real-world requirement

The more features you add to an application, a programming language, or indeed any software, the more difficult it becomes to grok it. As the Python people would say, the larger a language gets the more difficult it is to hold all of it in your head. Nevertheless, adding “features” is sometimes the only way to add capabilities, and I don’t think anyone in their right mind would argue that, once written, software should never change. (That’d just be crazy talk, too.)

In his opposing arguments, Matt Wilcox recognizes this when he says, Yes, the syntax should be simple, but the capabilities of CSS should not. What he’s alluding to without verbalizing it is the balance between adding necessary capabilities without unnecessarily growing the “size of the language.”

However, Matt says that modern web design methodologies (e.g., separation of concerns between structure, presentation, and behavior) dictate that CSS needs more capabilities than it currently has:

CSS lacks capabilities to allow truly flexible design, requiring layer upon layer of ‘tricks’ to accomplish certain objectives, requiring content to be structured ‘just so’ to achieve a display objective, or in the case of some designs proving instead to be completely incapable.

[…]

CSS’s positioning is a cludge. It’s a cludge because you can only position relative to the last positioned parent container. Well, that limitation in itself dictates that all positioning relies upon how the content is structured. And that means the presentation and the content are not truly separable.

To align CSS‘s capabilities with the requirements of real-world web design objectives, he says, CSS needs to be capable of describing relationships between semantically and structurally arbitrary but visually related elements.

Visual design is fundamentally about relationships between elements. For all of the artistic flourishes and creativity, it’s about relationships. ‘That yellow’ only grabs your attention because of its contrasting relationship with ‘that blue’. ‘This heading’ only works as a heading because of it’s exaggerated relationship to the size of the body text. […] CSS has no clue about relationships, period. And that’s why CSS as it stands right now, is not good enough. That’s why CSS without variables (true variables), without basic logic, without maths, can never be as flexible as we need it to be.

This is what web designers have been complaining about for (what feels like hundreds of) years. The fact that CSS has no capability to describe presentational relationships between elements in addition to directly describing an individual element’s presentational properties is a gaping hole that sorely degrades its ability to be a media-agnostic styling language. Every single web designer I’ve worked with has gasped at this omission, and though at first I didn’t understand why, the more I understood the principles behind graphic design the more I came to realize how fundamentally problematic this omission really is.

Adding delegation makes CSS easier for designers

As Matt eloquently stated, design is all about relationships. Good web designers create designs by constructing visual elements that have strong, often exacting relationships with other visual elements. There are many names and examples for this: visual language, visual hierarchy, the golden ratio, the grid, visual balance, the typographer’s scale, and so on.

What happens when the designer tries to define a relationship between elements? “How do I say that the whitespace between element A and element B should always be the same? How do I define element A’s height as half of element B’s?” These definitions, which are natural and necessary to the way designers work in both their mind and their mediums, are impossible to encode in CSS.

The closest you can get is declaring the same values to each element’s properties, not describing the relationship itself. This suffices only so long as these values are known ahead of time and are the same as one another, which severely limits the design possibilities we are capable of (without resorting to what Matt calls “tricks”). That’s why achieving simple visual effects are actually very complex and so, sadly, that’s where you’ll find the majority of indirection and obfuscation in CSS today. (I’m looking at you, faux columns.)

So who wins?

Both Bert Bos and Matt Wilcox have made some great points. Bert rightfully wishes to keep CSS lean and simple, even at the expense of some arguably beneficial styling power. Matt, on the other hand, argues that our needs as web designers have evolved faster than the technology to the point where CSS is too limited, fundamentally so.

The truth is, they’re both right. And they’re both wrong. Or rather, they are each taking a position that is too extreme. Bert’s absolutely correct when says that many of these proposed extensions are redundant and harmful, and yet Matt’s also correct that CSS lacks some fundamental capabilities that designers expect to be present.

Bert says that the CSS capabilities everyone’s asking for can be implemented using techniques that don’t rely on CSS whatsoever. These techniques, he says, make things like true CSS variables “redundant.”

There are examples of CSS with constants to satisfy all styles of programming, e.g.: David Walsh (in PHP), Tedd Sperling (in PHP), Digital Web Magazine (in PHP), Eco Consulting (in SSI), and Christian Heilmann (SSI and PHP).

Quite simply, he’s correct in stating that programmatic features need not be added to CSS proper to achieve desired results, but he’s incorrect in his apparent thinking that designers will be able to use these other tools to leverage CSS. Take, for instance, the probably more familiar (though not linked above) notion of using JavaScript to manipulate CSS values.

var x = document.getElementById('SideBar'); // get #SideBar element
var y = document.getElementById('MainColumn'); // get #MainColumn
var z = document.defaultView.getComputedStyle(y, '').getPropertyValue('height'); // get computed height of #MainColumn
x.style.height = ( parseInt(z) / 2 ) + 'px'; // set #SideBar's height 1/2 of #MainColumn's

This is an example of programmatic code that uses variables and expressions. It sets the element with the ID of SideBar to half the pixel height of the element with the ID of MainColumn. It does this by obtaining the MainColumn‘s height (at the time this code runs) and saving it in a variable, then performs some trivial math to half the value and use the result as the pixel height of the SideBar.

Doing this is currently impossible with CSS alone, yet it’s something that clearly belongs with whatever other “presentational” code exists and not in “programmatic” scripts that would otherwise be charged with defining “functionality.” As Matt states, using JavaScript to “script” solutions to CSS‘s shortcomings like this is not an acceptable answer.

CSS doesn’t have [basic logic or maths]. Nor is it the job of JavaScript to make up for this lack of abilities. JavaScript is about interaction behaviour, and what we are talking about here is pure display logic. Not interaction logic.

Moreover, the place designers expect to put code like this is, of course, into a CSS style sheet. The way designers expect to put code like this into CSS is by adding delegation features. Requiring designers to learn JavaScript (or any other programming language) to encode such design relationships is nothing short of ridiculous. In what world is that easier for untrained laymen to understand than CSS?

Adding delegation to CSS is worth the effort

One of Bert’s arguments against such additions to CSS is that implementations would become harder to create, and that we’ll (almost certainly) see more bugs.

extending CSS makes implementing more difficult and programs bigger, which leads to fewer implementations and more bugs. That has to be balanced against the usefulness of the extension.

Although I do agree with his statement that an extension’s usefulness has to be balanced against its potential costs, I think something so fundamental to design methodology as delegation greatly overcompensates for the cost of such implementation efforts. Moreover, if I understand Bert correctly and as he also discusses, the majority of implementations that would need to implement such delegation already have relatively complex internal structures to make the implementation effort somewhat easier:

There is no scoping [in proposals that only define global constants]. That means that an implementation needs a symbol table, but no stack. A stack would require a little bit more memory, but mostly it would make implementations more complex. (Although every programmer has, one hopes, learnt to program a symbol table with lexical scope during his training.) Constants in CSS are thus easier than, e.g., XML Namespaces, which are lexically scoped.

It is different for those CSS implementations that provide a CSS Object Model (an API for manipulating a style sheet in memory). Those implementations do need to keep track of scope in some way, because adding or removing a line of the style sheet can make a previously redundant definition become meaningful.

In order to use JavaScript to solve many of the shortcomings of CSS, as huge numbers of professional web developers do routinely, we use the very CSS Object Model whose prior implementation already exists for us to build upon.

CSS delegation doesn’t grow the size of the language

For the sake of argument, let’s simplify our requirement somewhat so that our somewhat contrived example of design intent is to create a relationship between the MainColumn and the SideBar elements such that they are of equal height. This is more informally known as “making columns.”

Here’s what a natural, hypothetical snippet of CSS would look like if the language supported delegation features such that it could encode visual relationships.

#SideBar { height: #MainColumn; }

This code theoretically says almost the exact same thing as the JavaScript shown earlier (save for the division, of course); it takes the computed value of the MainColumn element’s height property and applies that value to the SideBar element’s height property. In other words, “The SideBar’s (element B’s) height is always the same as the MainColumn’s (element A’s).” (Of course, this is a parse error in reality today.)

This extremely trivial example has some remarkably far-reaching implications, and yet there is really nothing radical about its syntax. Making this a reality significantly expands the capabilities of CSS without dramatically increasing the size of the language. This capability would not only beat the pants off “CSS tables,” it also potentially obsoletes the arguably misguided efforts of the CSS3 Advanced Layout and Grid Positioning modules, too.

We’ve long since abandoned table layouts because they force us to use presentational markup. That’s still what “CSS tables” force us to do, too. In other words, with display: table, the SideBar needs to be a child of the MainColumn element or, maybe worse and more likely, a child of a semantically meaningless wrapper element.

CSS positioning was introduced with the promise of freeing us from source-order-dependent styling, without which there is no hope of efficiently abstracting presentation away from structure. Moreover, abstracting presentation away from structure is the single most important prerequisite needed to improve document reusability and strengthen the semantic Web. Absolute positioning works, but limitations elsewhere in CSS mean its use is problematic for many designs, so in practice it doesn’t gain widespread adoption.

Here’s a theoretical solution to a two-column and a footer layout using CSS delegation with this semantic HTML:

<body>
    <div id="MainColumn">I'm the main column.</div>
    <div id="SideBar">I'm the right-hand sidebar.</div>
    <div id="Legalese">No one will read me.</div>
</body>

The CSS would look extremely familiar, possibly like this:

#MainColumn { margin: 0 25% 1em 0; float: left; }
#SideBar { width: 25%; min-height: #MainColumn; }

Using the same HTML, the same solution using the CSS3 Advanced Layout module would look something more like this, although to be frank I’m not certain I fully understand this syntax even after staring at it for months:

body {
    display: "a  b"
             ".  ." /1em
             "c  c"
             75% 25%
}
#MainColumn { position: a; }
#SideBar { position: b; }
#Legalese { position: c; }

Not only does there seem to me to be far more indirection in this method than there would be using CSS delegation, there is also an enormous increase to the size of the CSS language: a new (ASCII-art?!) value to the display property whose syntax is clunky at best. A similar story can be said of the CSS3 Grid Positioning module, which does lots more than just add a new (already complex) gr CSS unit.

The upshot is that the Advanced Layout and the Grid Positioning modules are doing some of the right things in many of the wrong ways. Both those modules add unnecessary complexity to CSS without giving designers a natural way to say what they mean. They do more to introduce obfuscation and indirection than simple delegation would, and they aren’t as broadly capable. Both of them try to solve a specific problem instead of dealing with fundamental deficiencies in the toolset designer’s have to work with.

Designers want relationships via delegation, not variables

Adding delegation such as that I’ve just shown is a natural, necessary addition to CSS because it is how designers create visual components—such as grids—in their designs. Variables (and constants, and macros, etc.), which simply reuse and modify pre-defined statements aren’t what designers care about. Adding them will bloat CSS without adding useful functionality.

“Okay,” you may be saying to yourself, “but delegation is itself a kind of variable, isn’t it?” Technically yes, however adding delegation resolves the core deficiency in the CSS language that designers need to use every day. Yes, it’s technically a form of variable, but that’s not how designers think of it. To say that one element’s visual properties is like another makes a variable only by creating a logical and visually appropriate mapping from the first element’s property to the second independent of markup, thereby avoiding indirection in the form of a variable name or other unfamiliar symbol.

Delegation like this doesn’t require the addition of anything other than what already exists in CSS. Class names and ID values are identifiers whose indirection people already have to deal with. Using them for delegation (to reference another element’s style) doesn’t increase the cognitive load any more than using them to reference HTML elements does. Though untested, the cognitive load might actually be even less since the CSS delegation’s references could be in the same (style sheet) file.

Moreover, delegation will increase the likelihood of document reusability by enabling style sheets to be more self-describing, more self-referential, in a similar way as good markup is. It satisfies a very fundamental need that designers have to define graphical relationships between elements. At the same time, it does so in a way that is natural to both their way of thinking and beneficial to the separation of concerns principle on which the “web stack” (the trifecta of HTML, CSS, and JavaScript) is based.

This page is a live example, so if you’re using a JavaScript-enabled browser you should see a microformat icon on the top-left of the viewport that is pulling data from (at least) my “The bio” section in my sidebar. Go ahead, click it. I’ll wait.

Pretty nifty, isn’t it? Naturally, all of the credit for this functionality belongs to the Oomph team, not me. If you want to learn how to add microformats to your blog, I’d recommend Emily Lewis’s latest series of blog posts, Getting Semantic with Microformats. If you want to learn how to easily add the Oomph microformat overlay to your WordPress blog, read on.

The backstory

After Ask.com’s announcement that they are adding semantic search capabilities to their search engine, there’s little doubt in anyone’s mind that the semantic web is the future’s web. As far as I know, Google has yet to reveal similar initiatives but they are clearly in the know as well. Mark Birbeck, one of the smart folks who devised RDFa, recently gave a Google Tech Talk that made the point that semantics are the next big thing in the Internet search engine game.

However, for semantic web stuff to really take hold, two things need to happen first. I think these things need to look like this:

1. Developers must create tools, plugins, and other software that makes it possible for the wider community to create compelling, interoperable applications that support semantic encoding. Thankfully, we are already at this point, with toolkits like the Oomph Microformat toolkit coming out of MixLabs.
2. Armed with these software tools, CMS and other publishing platforms need to adopt semantics as first-class features of their platforms, and build interfaces that end-users can make immediate use of. This is where we still need to go, though some platforms like Drupal have begun to pave the way for this.

Drupal 7 will be fantastic, I’m sure, but we live in the here and now. I saw the Oomph microformat overlay on Emily Lewis’s blog and was more convinced than ever that if everyone—programmers and laymen alike—had easy access to these tools, they’d simply be pounding down the doors to use them. So that’s why I sat down and wrote a completely idiotic plugin for WordPress that makes it completely, utterly, brain-dead simple for anyone with a microformats-enabled WordPress theme to add the overlay to their site.

WP-Oomph: Download the plugin

My request to add the plugin to the WordPress.org Plugin Directory has not yet been completed, so in the mean time I’m hosting the plugin right here. (When/if it’s accepted it’ll end up being The plugin is hosted on that site permanently.)

The latest version is: 0.1.1.

Download the latest version of the WP-Oomph plugin.

Thanks to the Oomph team’s work, the plugin is a ridiculous 1-liner (for now) that uses WordPress’s wp_enqueue_script() function to call both its included jQuery library and the Oomph library itself. And, well, that’s it. I told you it was idiotic, but at least now the whole process of microformat-enabling a WordPress blog is 100% point-and-click.

WP-Oomph: Frequently Asked Questions

I installed and activated the plugin, but nothing is different. How come?

First, view the source of your WordPres-generated page and make sure you see a line similar to the following near the top:

<script type='text/javascript' src='http://visitmix.com/labs/oomph/1.0/Client/oomph.min.js?ver=1.0'></script>

If you see that but there’s still nothing different about your page, then you probably don’t have any (valid) microformats. You might consider switching to a WordPress theme with built-in microformat support, or modifying your theme’s code to add some of your own. You can learn more about the support WordPress offers for microformats in the Microformat wiki.

The plugin does let me do X thing that I want to do! Why not?

Most likely because I haven’t taken X thing into account. Sorry, I’m not a psychic (as much as I wish I were). However, you’re encouraged to leave a comment on this post or to contact me elsewhere to request that I add capabilities to the plugin. Better yet, if you’re comfortable doing so, send me a patch.

• parameter-based post limit to define how many posts the plugin function will print
• parameter-based format option to output the posts in real <li> elements

The wp-category-posts.php patch file is available for download here. To apply the patch, run the following commands at your shell promp:

cd path/to/wordpress/installation/wp-content/plugins/wordpress-category-posts
patch -p0 < path/to/downloaded/wp-category-posts.patch

I’m hoping this will get integrated as the next version of the plugin, perhaps version 2.1.

I find working without an accurate awareness of the situation at large very disorienting, and software and web development are notorious for being circumstances that change rapidly. That’s why one of my favorite things about Scrum is the burn down chart. This is nothing more complex than a simple graph that depicts how much work you bit off and how far along trying to chew it you actually are. The benefit, of course, is that it’s pretty obvious pretty quickly if you’ve bit off more than you can chew. ;)

So up ’til now, my team and I have been doing this all on paper. There’s a certain tactile appreciation I have for doing this sort of thing on paper, but of course there are disadvantages, too. For instance, you can’t easily archive the information. You can’t easily share it with remote contractors. You can’t automatically mine this valuable data with software tools. You get the picture.

There are a few cool plugins to some tools like Trac that do all this, but at first blush most of these tools seem to require that you move all of your Scrum’s planning into the digital world. That is, you can’t just do the burn down chart, you have to do all your estimation (MoSCoW desirability, sizing, estimating ideal hours) through some tool. That’s a big step, and I wanted something simpler.

So naturally, I came up with a spreadsheet in Numbers.app as my solution. I mean, how much simpler can you get? Sure, it’s not exactly “well integrated” with other tools, but your non-tech-savvy boss will probably love it, and AppleScript can be used to automate data extraction. Here’s what it looks like:

An example Scrum-style burn down chart in Apple's iWork '08 Numbers spreadsheeting application, complete with an actual chart.

(Click the screenshot to get a full-size view.)

As you can see, the Numbers sheet is a simple table and a line chart. I’ve embedded instructions for how to use the chart into the example itself, which I’ll quote here:

This is a sample Scrum-style iteration burn down chart for software development created by Meitar Moscovitz. It can be used to plot a team’s progress throughout a development cycle (aka. “iteration” or “sprint”). This sample chart depicts a 3-week iteration (15 working days) with a 150-point target goal.

The X-axis represents time, and is thus labelled Time in Days, while the Y-axis represents the work to be completed, and is labelled Points.

The green line shows the team’s ideal velocity based upon the total number of points—termed the Remaining Initial Value—scheduled for completion in the graphed iteration.

The blue line shows the team’s actual velocity (or “completed work”), which is entered by the team leader (aka. Scrum Master) after each day in the Done column.

To use this chart: duplicate this sheet, enter your iteration’s total points in the Initial Value row of the Remaining column, and delete the values in the Done column except its initial value of 0. To add more days, copy and paste more rows into the table. Optionally, give the sheet and its contents new titles. ;)

Feel free to download the Example Burn Down Chart.numbers file and use it yourself. If you do use it, please leave a comment and let me know how you’re going. Thanks, and enjoy!

(Mike Cohn of Mountain Goat Software has got a similar spreadsheet for Excel you can download.)

When this happens, it’s generally a good idea to show your visitors a web page that briefly explains the situation. This is typically a page that politely explains that the “site is temporarily down for maintenance” and so on. I’ve taken to calling such a page a “curtain” because it’s a little like putting a curtain up in front of construction work.

You put the curtain up, do whatever you need to do to fix or upgrade or maintain your web site in the background, then take the curtain down. For delicate servers, this has the added benefit of dramatically reducing server load while you do your maintenance tasks. You can even allow access to specific visitors, such as QA testers or remote admins while this curtain is up, while still redirecting normal users to the “down for maintenance” page.

Obviously, the first thing you need is the page that explains your site is down for maintenance reasons. This can be anything you like, but it’s simplest to make it a static HTML page and place any and all resources you need for this page (like images) into the same folder. I often use a directory named down-for-maintenance and I place an index.html file in that folder to use as my “curtain” page. Images go straight into the down-for-maintenance directory, too.

Once you have that, you can then use the following Apache configurations to create an “on/off switch” for putting your curtain up and taking it down.

# To take the web site into a maintenance mode, create a file named
# maintenance-mode-on at the document (website) root, such as this:
#
#     touch maintenance-mode-on
#
# To bring the web site back, remove or rename the file, such as this:
#
#    mv maintenance-mode-on maintenance-mode-off
#
# To enable the site for your IP address only but nobody else's
# uncomment the second RewriteCond directive.
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{DOCUMENT_ROOT}/maintenance-mode-on -f
    #RewriteCond %{REMOTE_ADDR} !^your.IP.address.here$
    RewriteRule !^down-for-maintenance/.*$ /down-for-maintenance/ [R,L]
</IfModule>

What this does, step by step, is:

1. Determines whether or not you have mod_rewrite enabled. If you don’t, then nothing happens.
2. Enables the mod_rewrite rewriting engine.
3. Checks for the existence of a file called maintenance-mode-on at your site’s root. If such a file does not exist, nothing happens.
4. With the second RewriteCond directive uncommented, it also checks the visitor’s IP address and if it does match the one listed nothing special happens. If it does not match the one listed, the next line, which is the redirect, is executed.
5. Checks the requested URI and if it does not begin with down-for-maintenance, a temporary redirect (HTTP status code 302) is issued that points browsers to the down-for-maintenance directory you created earlier. Obviously, if you named this directory something else, you should change this RewriteRule.

This isn’t perfect. For example, if a visitor is filling out a multi-page form then they might get interrupted half way through when you enable the curtain since the curtain takes effect starting at the next HTTP request after you enable it. That said, the only way to do truly graceful maintenance with zero downtime is load balancing, and that is beyond the capability of most simple sites, but this curtain is extremely simple and extremely effective.

designing for the web is a lot less about making something dazzle and a lot more about making it work. The design decisions that matter pertain directly to the constraints of the materials. What form elements to use. What font sizes. What composition. What flow. Those decisions are poorly made at an arm’s length.

I’ve worked with many web designers in the past who only did abstractions and then handed over pictures to be chopped and implemented by “HTML monkeys”. It never really gelled well. The things that got strong attention were all the things that Photoshop did well. Imagery, curvy lines, and the frame. All the around stuff, never the it stuff.

In other words, to do great web design you have to design in the Web, not in some other medium for the Web. I mean, serious magazine firm employs designers who don’t understand how to work with page layout programs like InDesign. Why, then, do so many web design agencies employ designers who don’t know how to work with web technologies, or even how to use programs like Dreamweaver? It doesn’t really make any sense, and it’s no wonder that the resulting implementation is rarely top-notch work.

But if you’re a graphic designer who doesn’t know much about Web technologies, what are you to do? Well, as a first step, I think you should pick up my new book, Foundation Website Creation. It’s available from all good booksellers (and probably some crappy ones) as of today. The book is targeted towards all manner of web professionals, including graphic designers and website producers, who want to learn more about what it takes to actually implement a site.

If I do say so myself, the chapters on XHTML and CSS are exceptionally thorough. The book doesn’t try to turn you into an exceptional programmer. Instead, it will explain the foundational concepts you need to know to understand how XHTML and CSS actually work, and in so doing will enable you to use the tools you already know to solve problems and get things done.

I think this book will be an excellent starting point for lots of designers and other web professionals. However, it is not going to take you from zero to hero—no book can. That’s why I recommend that, after you read Foundation Website Creation and have a solid grasp of what the technology can do for you and how it actually does it, you next take a look at these excellent books:

• DOM Scripting by Jeremy Keith — if you’re a designer that needs to add a behavioral layer with JavaScript and Ajax to your pages, you need to read this book next.
• Mastering CSS with Dreamweaver CS3 – if you’re familiar with Dreamweaver and want to keep using it to create standards-based web sites, then I recommend you follow Foundation Website Creation with this book by Stephanie Sullivan and Greg Rewis to take your Dreamweaver skills to the next level.

As always, most of all, have fun. Because if you’re not having fun, you’re not going to make good web sites no matter what you know.

Note: As of this writing, the book listing on Amazon still publishes the wrong author list, which is very frustrating but out of my hands. At least the image of our book’s front cover lists the correct authors.

I came across Vaibhav’s post on the topic and noted that his solution uses the query_posts() function to alter WordPress’s query object before The Loop has run. While this is a great solution if your exclusion criteria is simple enough to be supported directly by the WordPress query object, other times the query_posts() function doesn’t provide you with the hook you need.

In these cases, you can run the original query, note any modifications you need to make, and then create a new, modified query and display the results you get from running that one instead. For instance, you might need to do this if you need to exclude posts based on category and, say, the beginning of their title, or their category and a certain piece of content in the post itself, or all three, or any other combination you can think of.

Another advantage of this technique over simpler ones is that this method maintains the same behavior you’d expect to see in every other way. Most notably, this means that if you’ve told WordPress to display the 10 most recent posts on the home page (in the WordPress settings), you’ll still see ten posts on that page even after you exclude some of them.

To do something like excluding posts if they are in the “Uncategorized” category (traditionally the category with an ID of 1 in WordPress) and their title begins with “Some title”, you can do this:

// original query runs in The (real) Loop first
while ( have_posts() ) : the_post();
    // detect pots matching our exclusion criteria
    if (in_category(1) && (0 === strpos(the_title('', '', false), 'Some title')) ) {
        $wp_query->post_count++; // increment the post counter
        continue;
    }
    endif;
endwhile;
// now make a new query and show the posts for real, with the adjusted post count and filtering
$my_new_query = new WP_Query($query_string.'&showposts='.$wp_query->post_count);
// do another The Loop (and display the results this time)
while ( $my_new_query->have_posts() ) : $my_new_query->the_post();
    // detect and exclude these same posts
    if (in_category(1) && (0 === strpos(the_title('', '', false), 'Some title')) ) { continue; }

// ...the rest of the WordPress template goes here...

This is neat because it gives you the capability to define arbitrarily complex exclusion patterns and directly modify your new query object however you like before you execute it. Once you know this works, you’ll probably want to extract the filtering code into a function. Using the above example, your new code might look like this:

// define criteria for filtering
function matches_filtering_criteria () {
    if (in_category(1) && (0 === strpos(the_title('', '', false), 'Some title')) ) {
        return true;
    } else {
        return false;
    }
}
// original query runs in The (real) Loop first
while ( have_posts() ) : the_post();
    // detect pots matching our exclusion criteria
    if (matches_filtering_criteria()) {
        $wp_query->post_count++; // increment the post counter
        continue;
    }
    endif;
endwhile;
// now make a new query and show the posts for real, with the adjusted post count and filtering
$my_new_query = new WP_Query($query_string.'&showposts='.$wp_query->post_count);
// do another The Loop (and display the results this time)
while ( $my_new_query->have_posts() ) : $my_new_query->the_post();
    //
    // detect and exclude these same posts
    if (matches_filtering_criteria()) { continue; }

// ...the rest of the WordPress template goes here...

For more information on these functions, see:

• The Loop
• in_category()
• the_title()
• WP_Query()

My co-authors on the book, called Foundation Web Standards Foundation Website Creation (you can pre-order now) and published by Friends of ED, an Apress company, are Jonathan Lane of Industry Interactive, Inc. and Joe Lewis, who blogs at Sanbeiji.com. I’m not going to say much more until after the book is released in late July.

For the eager, here’s the description of the book posted on the Friends of ED website:

Foundation Website Creation explores the process of constructing a web site from start to finish. There is more to the process than just knowing HTML! Designers and developers must follow a proper process to flush out goals and objectives and determine requirements both prior to, and during project development.

Large Web projects are rarely completed by a single person. Producers, project managers, designers, developers, writers, and editors all play critical parts in a project’s evolution. This book provides an overview of the entire process, and also shows project development from the perspective of these different roles. It introduces the key concepts and duties performed by every member of such a team, and gives you the skills necessary to tackle projects like a professional.

It’s quite exciting getting a book out, and it’s quite a bit more work than I’d have ever originally thought. That being said, it’s extremely rewarding. There’s a lot more work I need to do on it between now and the time it gets released to publishing, so, well…back to work I go.

Now you all know where I’ve been spending my time writing.

I’m going in!

Apple’s WikiServer keeps each group’s data segregated. There’s currently no way in the GUI to search across multiple wikis from a single wiki, or move one wiki page in one wiki to another wiki. Luckily, because the Apple WikiServer is a rather lightweight application, it’s not that hard to move things around. Doing so doesn’t seem to cause any problems with the application, either—a testament to its apparent simplicity.

Most simply, say you have created a number of different wikis for different groups, and in so doing you’ve created segregated spaces for different parts of your organization. Now say you’ve got a wiki page in one wiki that you’d rather place in a different one, or that you’d like to copy. Sure, you can edit the first wiki’s page, copy the WYSIWYG editor’s text, and paste it into a new page on the second wiki. But where’s the fun in that?

Instead, let’s move some files around to get a sense for how the Apple WikiServer stores its data.

First, recall that the Apple WikiServer stores its content inside the /Library/Collaboration directory on the computer hosting the wiki web site. Inside of this directory you’ll find four items:

$ cd /Library/Collaboration/
$ ls -la
total 8
drwxrwxr-x   6 _teamsserver  _teamsserver   204 Mar  2 13:50 .
drwxrwxr-t@ 60 root          admin         2040 Mar  3 19:16 ..
drwxr-xr-x   2 _teamsserver  _teamsserver    68 Mar  2 13:50 ArchivedGroups
drwxr-xr-x   6 _teamsserver  _teamsserver   204 Apr  4 18:48 Groups
drwxr-xr-x   2 _teamsserver  _teamsserver    68 Mar  2 13:50 Users
-rw-r--r--   1 _teamsserver  _teamsserver   249 Mar  2 13:50 dataVersion.plist

First, note that all of these files are owned solely by the _teamserver user, and only that user can access these files in any way. This keeps people like you and me from accidentally tampering with the Apple WikiServer data store. However, for the purposes of this exercise, we’re going to tamper anyway. To do so, you’ll need root permissions, which comes with a big caveat: be careful whenever you are root—one typo could erase your hard drive (and there is no undo)!

Become root by saying:

sudo su -

and supplying your password. Once you are root, you can explore further into the depths of the Apple WikiServer.

Inside the Apple WikiServer data store for wiki pages

The Apple WikiServer, which runs under the username _teamserver, is really just a bunch of organized flat files, supplemented with a number of SQLite databases (also flat files, really), and glued together with a bunch of Python scripts running under the Twisted networking framework. We’re not going to cover Python or Twisted in this post, so for further information check out their respective homepages. There’s also a great introduction to Twisted at ONLAMP.com.

To make the wiki go, the WikiServer runs these scripts to read and write data to these flat files. Let’s dig into this data store. Since the wikis are each associated with an existing group, all of the wiki files are inside the Groups subdirectory. In this directory, you’ll find one directory for each group that has a wiki. Each group directory, in turn, contains 6 other directories, 2 regular files, and 1 SQLite database:

# pwd
/Library/Collaboration/Groups/chiefs
# ls -p
discussion/	index.db	metadata.plist	resources/	wiki/
extrainfo	mailinglist/	public/		weblog/

The two regular files are metadata.plist and extrainfo. The metadata.plist file maintains the preferences of the individual wiki web site that you set from the “Group Settings” page on the wiki web site itself. That is, these settings are all editable via the web directly at http://your-server.local/groups/your-group-name/settings/. That page is also accessible to an admin user from the wiki home page under the “Admin functions” header in the sidebar of the web page (the key names in the plist file are pretty self-explanatory and map easily to the GUI options).

At the moment, the extrainfo file is a bit of mystery. It stores single lines of plain ASCII text in the form:

groups/your-group-name/web-service/page-id

where your-group-name is the name of the associated group for the file, web-service is one of wiki, weblog, and I assume can also be mailinglist or discussion, although I’ve only seen the first two on my server in practice.

What we’re most interested in for the purposes of wiki pages is, unsurprisingly, the wiki directory. This directory stores as many subdirectories as there are pages on your wiki. Every time you create a new page, a new directory is added here. If you delete that page, however, this directory is not deleted outright.

Each directory is named with the unique page identifier that the Apple WikiServer automatically generates followed by a .page extension. The exception is the welcome.page directory, special in that it contains the content of the wiki’s main (front) page. The Mac OS X Server Web Technologies Administration for Version 10.5 Leopard manual explains the contents of this directory as follows:

• /Library/Collaboration/Groups/groupname/wiki/pagename.page/ contains the component files of a wiki page.
• /Library/Collaboration/Groups/groupname/wiki/pagename.page/page.html contains the main text of the wiki (html content).
• /Library/Collaboration/Groups/groupname/wiki/pagename.page/page.plist contains the metadata for the wiki page.
• /Library/Collaboration/Groups/groupname/wiki/pagename.page/revisions.db contains the version history database for that wiki page.
• /Library/Collaboration/Groups/groupname/pagename.page/images/ contains the images for that wiki page.
• /Library/Collaboration/Groups/groupname/pagename.page/attachments/ contains all attachments for that wiki page.

Here are some additional details:

• The “page.html” file contains all of the (X)HTML that appears inside the WYSIWYG editor field when you click the “Switch to HTML View” button (the arrow brackets). Nothing more, and nothing less.
• The “page.plist” file maintains the metadata that associates a single wiki page to its group as far as the Apple WikiServer is concerned. If you take a closer look at it, you’ll find property list keys such as commentUID and uid whose values are both strings—URLs, in fact—that the Apple WikiServer uses to, for example, call the appropriate wiki theme to render around the page content. This file also stores self-explanatory data such as author, createdDate, page kind, a last modifiedDate and lastModifiedAuthor and, of course, the page title. The most interesting key in this file is the versioned key, which is a boolean that can turn versioning on or off. By default, wiki pages have this key set to true and (for example) weblog pages have this set to false. However, you can manually turn off versioning for a specific wiki page by changing this key yourself. It won’t delete past revisions, it will just stop new revisions from being saved. This is especially cool, because it means you can version-control weblog pages simply by editing the page’s associated plist file.
• The revisions.db is the SQLite database in which all revisions are stored. The database contains a single table, revisions, that looks like this:

  CREATE TABLE revisions(revision INTEGER PRIMARY KEY AUTOINCREMENT, editType, comment, lastModifiedBy, content, time DEFAULT CURRENT_TIMESTAMP);

  The interesting bit is the content field, which itself is just a string—but a string stored as an Apple property list, in full. Some keys in the property list inside the SQLite database are the same as those inside the page.plist file for the page, but with some differences. For instance, there is no versioned key in the plist in the database (for obvious reasons), and there is a tags key (which is missing from the filesystem equivalent). Most importantly, there is a content key, which stores the content of the page.html file.

• The revisions.db file is created automatically only if the versioned key in the page’s page.plist file is set to true.

Finally: move a wiki page from one wiki to another

Now that we understand some of the internals of the Apple WikiServer data store, let’s mess with it just a little by moving that one test wiki page from one wiki into another. Since almost everything is flat files, it’s remarkably easy to do:

# mv /Library/Collaboration/Groups/your-group-name/wiki/page-id.page /Library/Collaboration/Groups/new-group-name/

Be certain that there isn’t already an existing page in the new-group-name wiki with the same page-id as the one you’re moving. So far, Apple WikiServer appears to generate unique page IDs across the entire system (as opposed to just per-group), but I haven’t verified this yet.

With the wiki page files physically moved into the new wiki, you can now access the page at the new wiki URL. Trying to access it in the old URL will result in an HTTP 404 “Not Found” error. However, the page at the new wiki URL has the same theme as the other, old wiki. To correct this, you need to edit the page.plist file in two places: the uid string value and the commentUID string value relative URLs need their your-group-name changed to the new-group-name, whatever it is.

After you save this this change, simply reload the wiki page in your browser. Voila. Page moved.

Apple WikiServer: Mac OS X Server’s built-in Intranet builder

At work, I’m finally getting the opportunity to try the Apple WikiServer out. Its strongest asset, by far, is the integration it has with Apple’s Mac OS X permission scheme. Apple WikiServer makes heavy use of the OS‘s built-in user accounts to define users and groups, and the permissions those users and groups have to edit, view, and comment on pages in the wiki you create with it. And, because Leopard Server has full support for Access Control Lists, those permissions schemes can be as complex as you like.

This is very important because many large (and small) organizations have sensitive material that they’d like to keep private, or restricted to certain groups. Historically, wikis are a free-for-all. Anyone and everyone who has access to any part of the wiki can change any other part of the wiki. Recent wiki implementations such as later version of MediaWiki and some other wiki software have implemented permissions systems to allow administrative users to control access rights, but these are often complicated or require code-level configurations.

With Apple’s WikiServer, all of these permissions can be managed via the Workgroup Manager application, and because you can take advantage of the built-in ACL support, you can model your organizations permissions scheme directly in the Server OS permissions structure, giving you a much easier way to control information access. Take note, however, that like almost all other things that have to do with your Apache configurations, your Server’s Web Service will likely need to be stopped and started again for any changes you make to a wiki’s permissions take effect.

The Workgroup Manager application is also where you go to create new wikis for groups. To enable a wiki, you need to already have created a group and assigned users to that group. For instance, I created a Developer Wiki where all of the in-house developers can share tech tips, so I created a group called “Developers” and assigned individual developers, as well as the company executives (by way of the “Executives” group) to that group. The group-within-a-group technique is key, because if the company executives change, the members of the Developers group does not need to change, too. In all of Apple’s publications, Apple refers to the wikis hosted by WikiServer as an “intranet website.”

It’s clear that Apple intended this product for use within small companies, and not necessarily out on the open Internet. What follows are just a few notes I’ve compiled about how the Apple WikiServer works.

Front-end Code Generation from the Apple WikiServer WYSIWYG Editor

The Apple wikis are very nice to use. Their functionality is relatively straightforward to find and activate. However, the HTML code that the Apple wikis generate can be a little confusing. By default, new page text is entered into a semantically meaningless <div> element. This can be changed by highlighting text and then selecting “Paragraph” from the formatting toolbar. Subsequent paragraphs that are typed seem to then use <p> elements. However, some paragraphs revert back to <div>s when I used it, and I’m still not sure why or when this occurred.

On the plus side, so far, all the browsers I’ve used with the Apple WikiServer function the same way. This include Firefox 2, Safari 3.1, and Internet Explorer 6 and 7.

Typing actual code and having it marked up as such can’t be done in the GUI formatting toolbar to select a <code> element. The “Monospace” item in the text formatting toolbar creates <pre> elements and <pre> elements only. However, Apple does provide a “Switch to HTML view” button (the arrow brackets button) and one can enter standard HTML, including <code>…</code> elements in that view, and then switch back. This behaves perfectly on all browsers except Internet Explorer, in which your text area field shows no line breaks whatsoever.

Apple’s WYSIWYG editor handles escaping special characters when those special characters have HTML entity reference equivalents, such as double quotes (“), arrow brackets (< and >), and ampersands (&). It does not seem to handle Unicode characters, such as the ellipses in the prior paragraph. However, such Unicode characters need not be escaped as long as the document’s character set is UTF-8 (or UTF-16), which the Apple WikiServer specifies and supports out of the box.

Pressing the Return key twice causes the Apple wiki to generate an empty <div> or <p> element with an explicit break (<br />) inside of it. One can deduce that this is a design choice in order to help transition users who are used to plain <textarea /> inputs to Apple’s WYSIWYG editor. It’s also the only way to space paragraphs properly if the user hasn’t selected the “Paragraph” option in the text formatting toolbar. Otherwise, simply hitting the Return key once is enough to space paragraphs apart properly (i.e., the functionality is equivalent to the way Microsoft Word or Pages handles paragraph breaks).

Interestingly, the “Enter URL…” functionality form the toolbar is smarter than one might first assume. For instance, it recognizes email address and prepends a mailto: scheme to the link if it finds one. This is contrary to what the Apple-provided manual states, which tells you to enter the “mailto:” portion as part of the URL. In fact, you should omit this, else your final mailto link will actually read “mailto:mailto:your.email@address.com”.

This means linking to “mailto: links” is as simple as typing an email address. Similarly, the WYSIWYG doesn’t complain if your fully-qualified URL doesn’t include a scheme, so you can enter //apple.com/ and the subsequent link is generated as <a href="//apple.com/">Link text</a>. This is one step above and beyond even WordPress’s new WYSIWYG editor, which forcefully prepends an http: scheme to URLs without one.

For the most part, copy-and-paste works as expected, except in cases where the WYSIWYG editor does not understand the current formatting, such as a specific font and (and this is a biggie) for links. At first, the editor will appear to show that the formatting (including links) is saved, but when you actually save the page, only the formatting that the WYSIWYG editor understands is actually saved. Worse, all your links are turned into underlined—but unlinked—text. In short, this means that if you are copying and pasting page content that contains links, you need to do so in the HTML view of the page editor.

Inexplicably, the editor generates <i> and <b> tags for italics and bold, instead of the preferred <em> and <strong> elements. I’m not sure I understand why this is the case. There does exist a an “emphasis” option in the toolbar, as does an “important” option, but these generate strange spans instead. The “Important” item wraps the selected text inside a <span class=”Apple-style-span custom_forecolor_important”>…</span> and the “Emphasis” item wraps the selected text inside a <span class=”Apple-style-span custom_forecolor_emphasis”>…</span> element.

There’s also one other item, “Highlight,” which wraps the selected text inside of a <span class=”Apple-style-span custom_backcolor_highlight”>…</span> element.

The only explanation that makes sense to me, after much speculation, is that perhaps Apple does not want to encode semantic information such as what <em> and <strong> would imply from users who use a WYSIWYG editor. This shows either a blatant distrust of users or incredible foresight. I’m not sure which.

Page names and URLs

Currently, the search functionality built into Apple’s WikiServer only searches on the text of a page’s title.

Apple’s WikiServer generates unique page names for each new wiki page. These names consist of two parts, but only one seems to make any difference. For example, if you create a new Wiki page called “Hello”, you might get an address in your web browser’s location bar that looks like this:

http://your-server.local/groups/your-group-name/wiki/1d06a/Hello.html

Most of this is standard URL stuff (the protocol, the server address), and most of the rest is self-explanatory (the group name, the wiki section). The important bits in this URL are the last two:

• 1d06a
• Hello.html

Obviously, “Hello.html” came from the fact that you named your new page “Hello”. WikiServer appended “.html” on its own. The other bit, the short string of random characters, is a unique identifier used across all of this group’s web services (the wiki, blog, calendar, and mail list, if these other services are enabled) to uniquely identify this page. What’s interesting about this is that only the unique string of characters seems to matter in regards to accessing the page. That is, if you next ask for:

http://your-server.local/groups/your-group-name/wiki/1d06a/Some-Random-Page.html

you’ll still get the same “Hello.html” page from before, even though you’re seemingly asking for “Some-Random-Page.html”. In fact, it doesn’t seem to matter what you replace “Some-Random-Page” with. So long as there is some text in that part of the URL, that the URL ends with “.html” and that the unique identifier remains untouched, you’ll always end up retrieving the “Hello.html” page.

This means that if you change this page’s name later to, for instance, “Hello world”, old links that point to “…/1d06a/Hello.html” will continue to work, even while new links will start to point at “…/1d06a/Hello_world.html”. From a usability perspective, this is simple and effective; it ensures that users have a reminder of what the page is about by looking at the last part of the URL. However, once page names change, it becomes a bit non-optimal, because the same page can be referred to by multiple names—a “no-no” in the SEO world and a practice discouraged by most semantic-web types.

I would imagine that Apple made this design decision because the company envisioned their WikiServer to be used, again, primarily in intranet and SOHO environments, and as a result are not too concerned with search engine optimization. As an aside, this unique string is also how Apple’s WikiServer identifies the stored content on the filesystem. Read on for more details.

Hacking the Apple WikiServer

There isn’t a lot of information out on the Web right now about how to work with the WikiServer, especially for developers. Therefore, some digging is needed. After a bit of research, I discovered the following key directories that the WikiServer uses. They are as follows:

• /usr/share/collaboration - This has a few developer tool support files as well as the majority of the client-side code for the Wiki (javascripts, etc).
• /usr/share/wikid - This directory holds the Python sources and compiled bytecode for all the “Teams” components (including wiki, blog, calendar, etc.). It seems to run on Twisted and a number of other familiar-sounding components.
• /Library/Application Support/Apple/WikiServer - This is where most the data is stored, inside of plist files and a few others. The Themes subdirectory here is where Apple recommends that look-and-feel changes be made.
• /Library/Collaboration – This is the default data storage location for all the “Teams” components. The actual content of the wikis and blogs will be kept somewhere in this directory, which means that this is the directory you want to backup to backup the content of your wikis. This location is the only user-configurable one of the bunch. To change it, change the “Data Store” value in Server Admin. (A more detailed listing of this directory hierarchy is available on page 62 of the Mac OS X Server Web Technologies Administration For Version 10.5 Leopard manual.)

If you take a peek at the /Library/Collaboration directory, and follow that into the Groups/your-group-name/wiki directory, you’ll find a list of all the pages in your wiki stored as .page bundles, identified with the unique character string WikiServer generated when it first created the page.

It should be noted that anything in the /usr/share directory will likely be overridden whenever Apple releases an update that modifies the WikiServer. As a result, any and all changes you make to WikiServer’s templates or themes should be done by creating new files in the /Library/Application Support/Apple/WikiServer/Themes directory.

It’s interesting to note that the WikiServer seems to use Python for its back-end processing. This may open up some interesting integration possibilities for Python programmers in the future.

More help eslewhere

Even though Apple WikiServer is relatively new, there’s a load of helpful information about it on the web. Most of the good stuff is on Apple’s own Discussions boards, but more and more info is beginning to show up on blog posts. A Google search should give you what you need. For the really lazy, however, here are a few helpful items:

• Server Admin 10.5 Help: Customizing Wiki Themes and Layouts
• Apple Discussions: How to customize Apple WikiServer templates and themes
• Mac OS X Server Web Technologies Administration For Version 10.5 Leopard

This was just a brief introduction to WikiServer from some notes I’ve been collecting in my experimentations, but I hope it’s helpful to someone somewhere. Cheers. Or, continue to Part 2.

Thankfully, there’s an easier way. Especially if you’re accustomed to “old-school” development workflows that you learned through, say, PHP or perhaps Perl scripting, then ditching Rails and starting purely with Ruby might be the way to go. Doing things on your own without the “magic” of Rails will let you learn Ruby in a simple, yet fully-featured environment, much like the way you might have learned classic CGI programming.

Specifically, by using eRuby, the Embedded Ruby interpreter, you can make Ruby web development feel just like PHP development. Install it, upload an HTML file with some embedded Ruby code in it, and—voila—you have a single-page web application.

Why this tutorial?

Hivemind’s Getting Started with Ruby on the Web is an excellent resource that described this process from start-to-finish for Windows users. In fact, it was after finding that article that I realized web development with Ruby didn’t have to be governed by Rails and, being a web developer like the authors of Hiveminds, I wanted an easy way to use my Ruby knowledge on the Web.

However, I couldn’t find any similar tutorial or walkthrough for those of us who use Macs. Even the Linux walkthroughs are lacking (or at least my Googling skill for them is). After spending a little while successfully getting eRuby set up on my Mac running Mac OS X 10.4 Tiger, I thought I’d share what I learned with others, so I wrote this article. Its content mirrors the one from Hiveminds to a great degree but focuses on getting eRuby installed on Mac OS X instead of Windows (obviously). I imagine these instructions should be pretty similar if not identical for any other *nix-like platform.

The Setup

Getting eRuby installed and configured with your web server is actually pretty straightforward and won’t take an experienced web developer much time at all. All we’re going to need is the Apache web server and the Ruby programming language to start, both of which are already pre-installed on Mac OS X 10.4 Tiger. (And in Mac OS X 10.5 Leopard, Apple is even shipping new Macs with Ruby On Rails preconfigured, but that’s a subject for another time.) However, Apple typically ships an older copy of Ruby than is readily available, so you might choose to use a newer version of Ruby that you download yourself.

The easiest way to get a copy of eRuby (and an updated Ruby, if you want it) is with a package manager such as MacPorts. With MacPorts installed (which is a simple, standard package installation downloadable from the MacPorts home page), simply run

sudo port install eruby

from your terminal to download the latest stable Ruby and eRuby in one fell swoop. After this runs, you’ll have a new Ruby in /opt/local/bin/ruby and an eRuby in /opt/local/bin/eruby. Alternatively, of course, you could compile and install eRuby yourself. Instructions for that are on the eRuby homepage.

As a quick test to see if everything is installed and working correctly, create a plain text file with your favorite editor that contains the following code:

Hello world! The time is now <%= Time.now %>.

All this does is print out a “Hello world!” greeting and then announces the current time (as reported by your system clock, of course).

If you named the above file helloworld.rhtml then you can feed this file to the eruby interpreter as follows:

eruby helloworld.rhtml

Note that the file extension doesn’t actually matter. You could use .erb, if you like, or any other arbitrary file extension. The file extension is, as you’ll see later, only used for telling Apache which kind of file it is. So once you come up with file extension you like, stick with it. The standard file extensions are either .rhtml or .erb, so I’d recommend using one of those. (I prefer .erb, myself, since I don’t necessarily only want to create HTML pages. I might want to create XML documents like news feeds or even XML databases, so .erb seems a more reasonable file name extension, though most of the eRuby documentation uses .rhtml.)

If things worked properly, you should see output similar to the following:

Hello world! The time is now Wed Oct 24 21:58:54 -0400 2007.

Serve it up!

Now that eRuby is installed and working, the next step is to set it up as a CGI so that when your web server (Apache, in my case) fetches the file it will first feed it through eRuby for processing before sending it back to the browser. The simplest way to do this is to configure Apache to use a specific directory somewhere on your filesystem as a CGI directory—that is, a directory whose contents are all treated as CGI programs. You do this via Apache’s ScriptAlias directive.

Conveniently, standard installations of Mac OS X already come with a CGI directory. It’s located at /Library/WebServer/CGI-Executables. This directory is just like any other, except that Apache treats it specially. It treats it specially because Apache’s configuration file, /etc/httpd/httpd.conf contains a line of text that reads as follows. (On a standard installation of Mac OS X client, this is line 671 of the file.)

ScriptAlias /cgi-bin/ "/Library/WebServer/CGI-Executables/"

This line basically just tells apache, “Treat every file in the /Library/WebServer/CGI-Executables directory as though it were a CGI program.” So, since that’s how we’re treating eRuby, we’re going to want to put our eruby binary in that directory. However, we don’t actually want to make copies of the binary. Having too many copies of a program on your system can easily get confusing. So instead, we’ll make a symbolic link (or an alias to use the classic Mac terminology) to the binary.

ln -s /opt/local/bin/eruby /Library/WebServer/CGI-Executables/eruby

With our eruby CGI executable in the proper place for Apache to find it, we can now tell Apache which files we want it to send to this program. We do this using the AddHandler and Action directives.

AddHandler simply tells Apache to treat files with a certain extension in a certain way. For instance, you can say something like, “Treat all files ending in .php as PHP scripts.” Similarly, you can (and will) tell Apache, “Treat all files ending in .rhtml or .erb as eRuby CGI pages.”

To do this, we add the following line to our /etc/httpd/users/username.conf file somewhere inside the <Directory> and </Directory> block. Naturally, replace username with, of course, your Mac OS X user’s short name:

AddHandler rubypage .erb .rhtml

Again, this just tells Apache that files ending in .erb and .rhtml should be treated the same way other rubypages are treated. But how are eRuby pages supposed to be treated? They’re supposed to be handed off to the eRuby program, of course, so we need an Action directive that applies to the rubypage handler we just defined.

Right below the above line, add the following line, too:

Action rubypage /cgi-bin/eruby

This line tells Apache that any file that it is treating as a “rubypage” file should be sent to the program at the URL accessible at /cgi-bin/eruby, which we’ve defined earlier to be our symbolic link to the eruby interpreter.

Your completed user-specific Apache configuration file should now look something like this:

<Directory "/Users/username/Sites/">
…
    # Let eRuby files get parsed through the proper CGI binary
    AddHandler rubypage .erb .rhtml
    Action rubypage /cgi-bin/eruby
</Directory>

Are You Being Served?

That’s it, everything should now be in place. To make sure, move your earlier helloworld.rhtml file into your user’s Sites folder, and now simply point your browser to http://localhost/~username/helloworld.rhtml (again, replacing username with your Mac OS X user short name, of course). Congratulations, you’re serving up Ruby-coded applications via eRuby.

Additional Reading

This is just the set up, of course. Now the real fun begins: learning Ruby. Here are some suggested places to start.

• Programming Ruby: Ruby and the Web — A chapter out of the free book Programming Ruby all about Ruby as a CGI programming language.
• Hiveminds: eRuby: How to use Ruby CGI and ERB templating for Web Pages — a quick’n'dirty article explaining the basics of using Ruby on web pages in classic CGI style where program logic and HTML templates are kept separated, as opposed to classic PHP style, where the two are mingling together on one page.
• COOLNAMEHERE: Simple Ruby CGI — Like the Hiveminds example above, another quick’n'dirty Ruby CGI how-to.
• cgi: Ruby Standard Library Documentation — Ruby’s standard library contains a rich set of features, and the CGI objects are among them. They are well-documented in the official Ruby Documentation Project.

Naturally, feel free to leave comments if you have more resources that you found helpful.

document.body vs. document.documentElement

In IE 6, in order to access the current width of the window in JavaScript you need to get document.body.clientWidth only if you’re in quirks mode. If you’re in standards mode, this property not only still exists, but it means something entirely different! It instead refers to the width of the body element.

This causes real trouble for some scripts when the value of the this variable seems to suddenly become frozen or fixed at a single value instead of changing appropriately on a window resize event. Instead of document.body.clientWidth, in standards mode, use document.documentElement.clientWidth. (Reference table at QuirksMode.org)

Internet Explorer crashes when attempting min-width

If you use IE‘s proprietary expression() syntax to script a CSS value, beware of calculating widths or heights that exactly match the value you’d like to set. If you do something like the following to set a minimum width on #someElement, IE will crash when you actually resize that element to be 500 pixels wide.

#someElement { width: expression(document.body.clientWidth < 500 ? "500px" : "auto"); }

Instead of doing the above, you should check for almost exactly the size you want, like so:

#someElement { width: expression(document.body.clientWidth < 501 ? "500px" : "auto"); }

However, the really important thing to keep in mind is that the minimum width you’re testing (501 in that second case) needs to be at least one pixel greater than the total content and padding width of the element. So if you have an element that needs to be no less than 500 pixels wide but also has 10 pixels of left and right padding, you need to check not for 501 pixels in width, but rather for 521 pixels in width. (Reference on CameronMoll.com.)

I’m beginning a new project at work where, for the first time, I’m working with a large team of developers, and not just integration developers but front-end developers like myself. Since I’m the new guy, I’m finding myself required to learn the teams established vocabulary and this is making me realize just how much of my own vocabulary I have developed myself without even realizing how large it’s grown.

It all comes down to how we organize our code and that, of course, depends very much on how we are used to thinking about things. On a team of people working together for a common goal, such implementation-specific details are much more central to the success of the project than when working alone, such as in a freelance situation.

It’s interesting to me to see how many of the the established coding standards and naming conventions are obviously built off of the same kinds of ideas that I’ve already had and have been using for quite some time, and yet how different they are in implementation. This extends beyond the obvious case of using dash-separated class and ID names instead of camel case lettering or vice versa. It goes so far as to project management and workflow considerations, file name conventions, and semantics.

In some cases, optimizations are actually sacrificed on a team in favor of clarity, but this is actually a good thing. In my freelance work, I typically squeeze every last ounce of optimization into a project by using shorter names, more optimized files, and extremely dense code to ensure the best possible result. In a project with other developers however, the success of the project is far more dependant on everyone’s collective understanding of the code, so clarity is and should be prioritized above optimizations.

In some industries, such as construction (for example), people are very careful about what they do because they know how hard it will be to change something after the fact. In the digital workplace, however, people don’t seem to think as much about this sort of thing because it’s relatively easy to change things. After all, everyone’s dealing in bits and bytes at a fundamental level. However, if you take a higher-level look, you’ll see that many times things are not as easy to change correctly as you might think, and the costs associated with these mistakes and after-the-fact edits can be enormous.

Take a web site, for instance. (I bet you saw that coming.) After a web site is launched (and even before, sometimes), changes have to go back and forth between designers and coders, production and design, and back again. Many times so-called final versions are just the next revision and not actually set in stone, no matter what anyone says. For a web developer, all these changes can be really troublesome, however they also provide an opportunity for rapid, iterative improvement of your (X)HTML and CSS code.

In a recent project I worked on, I found myself faced with the challenge of positioning two columns of data that each had a different number of elements inside of them but that ultimately had to be the exact same total height. My production manager, who fell in love with floated layouts a long time ago, wanted to position the page using one column floated left and the other floated right, with their dimensions fixed so as to give them both room to fit inside their parent. This seemed perfectly logical to me, so I implemented it that way.

As the project moved forward, however, I realized that in our design changes to this kind of floated layout would require a minimum of editing two files. First, we’d need to edit the HTML source of our page to change the order of the content boxes inside the floated columns, and second we’d need to change the dimensions of the elements in our style sheets. Instead, reimplementing the design with absolute positioning would require edits to only one source file, the style sheet itself, where both the position and the element dimensions could be specified in a single CSS declaration.

With all the frequent changes the design department was making, this argument ultimately won everyone over, and the site uses absolute positioning for the design. The key concept to take away from this experience is that part of making things easy in the future is to design with change in mind, to be as flexible as possible from the get-go, but also to think about the actual implementations in such a way as to lower your edit-per-change ratio as much as possible. The fewer things you have to change, the easier it will be to change things moving forward.

I’ve just spent the past three and a half hours at the site watching the presentations and I’ll have to blame them for making me sleepy at work tomorrow. Nevertheless, they are some of the most compelling and fascinating presentations I have ever seen in my life. I highly, highly recommend that you spend a few moments to check them out.

For those interested in Human-Computer Interface design, you absolutely must view Jeff Han’s talk on an “interface-less” touch-screen-like display which will very likely obsolete the traditional mouse and keyboard.

For those interested in global health and economics, you absolutely must view Hans Rosling’s talk on the myths of the third world.

And for those who just want more proof how much Apple Computer rocks our socks, you must view David Pogue’s excellent presentation on the woes caused by software frustration (and it’s partially set to music).

My personal favorite (so far) was Sir Ken Robinson’s almost stand-up comedy approach to explaining to us why the current state of the world’d public education systems will not serve us for our future.