So just what exactly is behind my dislike of Flash?

Caveat emptor. This is going to be a really long post. But I’ve been saving this up for a long time, and hopefully I can purge myself of it in one sitting. Also, I apologize for that vaguely vomitous metaphor, but it fits my feelings about Flash. And, perhaps, by the end yours as well. So if you have a strong stomach (and care at all about this crap), read on. Otherwise, see you next time.

OK, so I’ve chimed in on the whole Apple vs. Adobe, no Flash on iPhone OS situation before. (And, if you care to scroll back through my history of mostly beer-fueled tweets about the Minnesota Twins, you’ll find a few choice 140-character missives on the matter from me on Twitter as well.) But up to now I’ve never made a clear — or, failing clarity, at least a verbose — argument for why I so strongly dislike Flash. The time has come.

I am well aware that Flash means different things to different groups of people. Essentially, as I see it, there are three main groups of people where Flash is concerned: pro-Flash designers/developers, anti-Flash designers/developers, and users. I don’t bother to distinguish between pro- and anti-Flash among users, because ultimately I don’t think most users (unless they’re also in one of the other two groups) give a crap what technology is behind the content they’re consuming on the Internet. They just want it to work.

So, with this in mind, I’m splitting this post into two sections: my arguments against Flash from the user perspective, and my arguments against it from the designer/developer perspective. I don’t bother representing the third group, because there’s really no part of me that supports it. I have reluctantly used Flash for a few, very limited purposes in recent years1, but I am actively striving to eliminate even those rare instances of it from my work.

But enough about my work (for now). Any web designer or developer worth their hourly rate knows the user comes first.

Part one: the user’s perspective

1. Flash-based designs look bad. I know I’m not an ordinary user, given my professional background, but I can spot Flash-based content in an instant, and it’s always a turn-off. There’s just something… cheap-looking about most of it. More often than not, I notice that Flash-based content has bad text rendering (both because of kerning and leading issues and because of Adobe’s abysmal anti-aliasing technology, far surpassed by the built-in anti-aliasing of plain HTML text in modern Mac web browsers and Mac OS X itself). And beyond the text, most Flash content I see has cheesy, cookie-cutter animated effects. It’s not as objectionable as a PowerPoint presentation, but it’s almost as immediately identifiable, and equally uninspiring.

Now, it’s true I’ve seen some excellent Flash-based web design. But it’s definitely the exception, and it’s rarer as an overall percentage (or at least feels that way) than first-rate design is on non-Flash sites. Plus, since I can never entirely turn off my professional perspective, knowing the drawbacks that an all-Flash website brings, my experience even of these best examples of Flash-based design are tainted beyond redemption.

2. The most high-profile use of Flash is for ads — and annoying ones at that. OK, there’s a lot of Flash content out there that’s not ads. I’d like to believe that ads make up a minority — hopefully a small one — of all Flash content on the web. But I think most of the interesting Flash web design is never seen by most people. The only Flash-heavy content that draws a lot of traffic is either online games (some good, some… meh), kids’ interactive sites (probably the only use of Flash I unabashedly support), and promotional sites for blockbuster movies and console video games. Of course, the number one use of Flash these days is probably to watch video online, from sites like YouTube, Vimeo, Funny or Die, Hulu. Flash-based video is everywhere. But that’s changing.

So, set aside the sites that require heavy-duty interactive content or (for now) video, and what are you left with? Where else does the average Internet user encounter Flash most often? Ads. Annoying, intrusive, obnoxious ads. I realize perfectly well that unless a website is actually selling stuff (including, potentially, access to the site itself, and good luck with that unless your content is either targeted at highly-specialized professions or X-rated), the only viable revenue source is advertising. But websites that operate on an ad-based business model walk a fine line: the ads need to be attention-getting enough to encourage the user to click on them, but they can’t get in the way so much that people stop visiting your site altogether. As a user, when I encounter a site with an over-abundance of intrusive ads, it’s a double negative: not only do I think the site’s design is too annoying to deal with, but I automatically assume its content must be crap, not worth wading through the ads to get to anyway.

3. It’s a plug-in. A plug-what? A what-in? This is beyond the level of most users’ interest in their computers. I just want it to work, I don’t want to fiddle around with downloading extra crap, especially when the installer was written by Adobe. (See, it’s hard for me to divorce my mind from my professional experience, even for a few minutes.) Once it’s installed, you’re done forever (or… well… until a new version of Flash comes out), so it’s easy to forget about it, but get a new computer and it’s either not installed, or you’ve purchased a PC that’s not only preloaded with Flash but 3 dozen other crappy OEM add-on applications that you’ll spend a week trying to get rid of (or, more likely, leave on your desktop gathering metaphorical dust along with 100 other icons, including every Word document you’ve ever created, forever).

The point is, despite Adobe’s efforts to make us think Flash is a natural part of the web, a sibling to HTML, CSS and JavaScript, in fact it is not a web technology at all. It’s just this proprietary thing Macromedia (now part of Adobe) developed for creating interactive media (first as Director, and then as Shockwave) and decided at some point to turn into something that could be embedded in web pages: Flash. (I’m sure the longtime Macromedia fanboys will want to correct me on some point of that history, but for anyone who doesn’t give a crap, that’s the gist of it.)

Flash filled a niche, but web standards have caught up (or are well on their way to doing so), and a proprietary add-on just isn’t necessary in the way that it used to be. And, of course, on any device running iPhone OS, it’s not even that. It’s this.

4. You can’t “deep link.” I realize that to anyone who doesn’t know what a “plug-in” is (as I joked about in the previous item), the concept of “deep linking” may cause a spontaneous mental breakdown. But just because the average user doesn’t know what “deep linking” means doesn’t mean they don’t want to do it. The best example of this (though sadly I don’t have an example of it at the moment) is the scenario of a Flash-based photo gallery. Want to send your friend a link to the 14th photo in the gallery? Too bad. If you copy and paste the URL from your browser into an email, they’re going to be taken to the first photo, or, more likely, to the obnoxious crap you didn’t bother watching when you first landed on the site, because the designer at least had the courtesy of including a “Skip Intro” button.

It’s possible now to work around some of these limitations, but in my experience most Flash-based websites don’t.

5. It’s sometimes used when it’s not really needed. This is closely related to the previous item, and is probably more of a complaint I have as a developer than as a user. But there are just some sites that don’t need Flash. Or even if they do, the whole thing doesn’t need to be in Flash. If Flash were restricted to the parts of the site that require its capabilities, and things like the main navigation and text content were in plain HTML, then deep linking and a host of related problems could be alleviated.

6. Mobile. Note that I said “mobile” and not “iPhone OS.” It’s true that Apple is the only mobile device manufacturer who is actively and aggressively keeping Flash off the platform, but up to now no other mobile device has a working, readily available version of Flash either. And even though Android 2.2 (on the Android-based devices that are actually upgradeable to it) does finally offer Flash support, the jury is still out on how usable it is. Adobe is working hard (apparently), but there are major technical hurdles in optimizing Flash both for the low processing power of mobile CPUs and for reasonable battery consumption. But even if those technical issues are resolved, there’s the interface issue. Flash simply was not designed for touchscreen devices, and even though, from what I’ve read, Adobe has added programming hooks for touchscreen input, a lot of existing Flash-based interactive content will not be usable as-is on a touchscreen device. This is an issue for “regular” web technologies too, but the open standards of HTML and JavaScript make building a mobile web browser that overcomes these differences far easier than with Flash — and Adobe doesn’t need to be at the center of the process.

7. The security and privacy settings you don’t know about, but should. There’s a reasonably good chance you’ve looked at the privacy settings in your web browser’s Preferences dialog box. But have you seen this screen before?

Probably not. But maybe you want to check it out. It’s here. You see, Flash really isn’t a part of your web browser. Flash has its own privacy settings, its own cache, its own cookies. Web sites that use Flash can store and retrieve information on your computer, completely apart from the capabilities and limitations in your web browser. And Flash can access information on your computer that the web browser by itself can’t. That’s the whole reason Flash-based file uploaders exist, and why they work better than a regular browser “upload” form field: because Flash can read information about files on your computer that is strictly off-limits, for security purposes, to HTML and JavaScript.

I’m not claiming the sky is falling or crying wolf. I don’t personally know of any major security exploits that have come out of this particular capability of Flash. But what happens if there is an exploit? There’s no one who can fix the problem but Adobe, and no alternative means for you to access Flash-based content. If Internet Explorer has a security exploit, you can always browse the web with Firefox, but despite some noble open source efforts, there really is no alternative to Flash. Adobe has an absolute monopoly on Flash-based web content.

8. Performance. Flash is notoriously much slower on the Mac than it is on Windows. Always has been, always will be. Apparently, according to none other than Steve Jobs himself, it’s also the number one reason Macs crash. I don’t doubt it, though I haven’t experienced it myself, mainly because I avoid Flash-based content as much as possible. But even though it performs well on Windows (largely due, I suspect, to more direct access to the system’s hardware — another security concern, incidentally — on Windows compared to the abstracted hardware access the Mac grants applications), it’s a resource hog everwhere else. I already talked about Flash’s performance issues on mobile devices. The upshot is that Flash seems to be pretty bloated and inefficient, and since Adobe won’t let anyone else look under the hood, I suspect there’s a good chance that it is… perhaps even more than anyone thinks.

In other words, if there’s a better way to do something, use it. Dump Flash.

Part two: the designer/developer’s perspective

1. Flash created a rift in the community. You don’t say! Just as there’s a big wall in the corporate software development world between .NET and Java, there’s a huge wall in the web design/development community between those who use Flash and those who don’t. This may stem in no small part from Adobe’s (and, previously, Macromedia’s) marketing tactics. There are almost unlimited options available for free (or at least cheap) IDEs for web and application development (or you can just use Notepad), but the only way2 to create Flash content is to pony up.

The result of this — and I speak from my own experience, which was a contributing factor in which side of the fence I fell on — is that designers who were given Adobe Creative Suite had Flash on their desktops, and developers who did not have CS were shut out. Flash, with ActionScript, became a gateway drug for designers looking to get into programming. Adobe capitalized on familiarity with their applications’ user interfaces, and a generation of Flash evangelists was born.

Or, on the other hand, you had developers or, like me, designer-developers who happened to fall just slightly more into the “developer” column, who were maybe given a copy of Photoshop, but encouraged not to use it. There have been periods over the past decade where I have been receptive to the idea of getting into Flash development, but was denied access to the necessary tools. It doesn’t take too long playing that role — in the context of all of the criticisms I’ve already levied from the user’s perspective — before you just decide it’s a piece of crap; you’re better off without it; and you’ll do everything you can to prove that standards-based alternatives are better.

The war between Apple and Adobe over Flash support on the iPhone OS has brought the situation to a head, with the Flash development community up in arms over Apple’s war (in which they are at least collateral damage, and at worst Adobe mercenaries), and the standards community cheering what they see as the overdue demise of public enemy number one.

2. Flash developers use it unnecessarily. There’s the rift in the community again. Because Flash developers were often weaned on Adobe Creative Suite and don’t know how to program in anything other than ActionScript, nor often how to build a simple web page in HTML/CSS, and because it’s easy for them to dazzle clients with a Flash-based site, it’s often tempting to just build an entire site in Flash. It looks impressive, the client thinks they’re getting what they want, and the check’s in the mail.

The problem is, although you can build an entire website in Flash doesn’t mean you should. In addition to the aforementioned mobile devices, Flash content is invisible to screen readers, meaning visually impaired users can’t access it, and, probably more important to the client’s bottom line, to search engines. As far as Google is concerned, that whiz-bang all-Flash website you just created for your client may as well not even exist.

Again, there are ways around a lot of these limitations, but I can think of a better one: just don’t use Flash.

And so on. I had a few other items on my list of complaints from the developer’s perspective, but they’re mostly facets of these same points: it’s a closed system entirely dependent upon one company; it’s expensive; it’s increasingly unnecessary as web standards evolve; it encourages bad user experience (UX) design; it distracts designers-turned-developers from learning web standards; etc.

Arguing for or against Flash is a lot like arguing politics and religion. It’s a polarizing issue. Everyone who has any interest in the debate also has investment in a particular perspective — baggage and biases they may not be fully willing to admit even to themselves, much less throw into their arguments. And a lot of it isn’t entirely rational.

As Upton Sinclair famously wrote, “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” It’s also easy to use that argument when you’re entirely convinced that it’s describing the other person’s position. I’m sure there is more behind most pro-Flash arguments than a vested interest in the ongoing potential for work developing for the platform. But from my perspective, it’s difficult to see.

Notes

1 I said there were “a few” things I’ve used Flash for in recent years. In fact, there are three: 1) YUI Uploader, on the administrative side of my CMS, for handling file uploads with a user-friendly progress bar; 2) JW Player, on a few client sites running my CMS, for displaying Flash-encoded video (FLV) in a skinnable player; and 3) sIFR, that damnable bastard Flash/JavaScript hybrid solution to the problem of customizing fonts on the web. I’m pleased to say I haven’t used sIFR in nearly two years (though, sadly, I’m still avoiding promising CSS3-based solutions like Typekit and the new Google Font API because of poor rendering on Windows, especially in Firefox). And I’ve just — temporarily, at least — pulled YUI Uploader out of my CMS after upgrading to CakePHP 1.3, due to an incompatibility I have yet to troubleshoot. As for JW Player, well, I’m still using it for now, but I’ll actively pursue HTML5 video solutions on future projects.

2 OK, owning a $700 copy of Adobe Flash isn’t the only way to create Flash content. Knock yourself out. Adobe will be standing by to take your order when you get back.

Migrating from CakePHP 1.2 to 1.3: My Story (Part One of… Possibly More than One)

For the past couple of years I’ve been working on a rapidly evolving CMS project called, not-so-creatively, cms34. It’s built on the open source CakePHP framework.

I love CakePHP. I’ve dabbled with a couple of other frameworks (notably, Zend Framework), and while CakePHP certainly isn’t perfect, I’ve found it by far the easiest to jump into and quickly get a powerful and reliable web application running.

When I started cms34 in late 2008, it was using CakePHP 1.2.0. Since then I’ve kept up with most of the minor point releases, upgrading as far as the current version, 1.2.7, as easily as simply swapping out the cake directory. And in that time, cms34 itself has gone through several major and minor revisions, currently up to what I’m calling version 3.2.

In preparation for version 3.3, I’ve decided to take the plunge and upgrade from CakePHP 1.2.x to the newly released CakePHP 1.3.0. Version 1.3 offers a number of improvements, but it also includes the kinds of changes typical of a major point release that mean an upgrade is not such a simple task. I’ve run into a few issues with the migration from 1.2.x to 1.3.x, many of which are not covered in the project’s official migration documentation, partly due to the incompleteness of the documentation, and partly due to some idiosyncrasies of my application that I wouldn’t expect the documentation to cover. But since I’m probably not in this boat alone, I thought I’d share some of the problems I encountered, and the solutions I found.

Getting started: RTFM

First things first. Download CakePHP 1.3.0. Be sure to get the release version (the one in the list with no hyphenated qualifiers after “1.3.0”). Unzip it and then follow the migration instructions to get started. For the most part this means swapping out the cake directory along with a couple of other files, and then going through all of the notes and making any necessary changes to your application.

In my own experience, I didn’t have to change much: I’ve been trying to keep up with the recommendations in the version 1.2 docs, so I haven’t been using any functionality that got dropped or deprecated. The writing has been on the wall for some time with most of these features and unless your application started with version 1.1 or 1.0, you’re probably not using any of these dead methods anyway.

A few specific issues I did need to address:

  1. Unlike with minor 1.2.x updates, there are a few files outside of the cake directory that need to be replaced. I found it best to just go through the entire release package and replace all files (except those I had modified) with their new versions.
  2. Update your config/core.php file, using the new version as a model. Mine had lots of changes, and I had stripped out all of the instructional comments to make the file less cumbersome to deal with. I wanted to keep those comments stripped out, so I just updated my file with what I needed, and then I kept the distribution’s version of the file in config as core.dist.php so I can refer back to it in the future if I run into any issues.
  3. There are some mixed messages in the documentation regarding the deprecation of AjaxHelper: the migration appendix says it’s deprecated but the main documentation doesn’t indicate that. I’m using it a fair amount and don’t want to have to rework all of that code, so for now I’m leaving it alone.
  4. JavascriptHelper is another matter, but since it appears there are perfect replacements for its functions now in HtmlHelper, I just did a straight-up find-and-replace, changing all instances of $javascript->link() to $html->script() and $javascript->codeBlock() to $html->scriptBlock(). I should note that so far I haven’t really tested any of this functionality to ensure that it’s still working, but no obvious errors have cropped up.

But wait, there’s more!

After following the migration docs, I was overly optimistic that things would just work. They didn’t. First up, I encountered this:

Notice (8): Undefined property: PagesController::$Session
[APP/controllers/app_controller.php, line 383]

Your line number will probably be different, but if you’re using sessions at all (and why wouldn’t you be?), you’ll get this error somewhere. It’s not mentioned in the migration docs, but I found out here that the Session component and helper are not instantiated automatically anymore. The solution is quite easy though. In app_controller.php just make sure that you add 'Session' to the arrays defined for var $components and var $helpers.

That was the biggest and most obvious problem I encountered. Once I had fixed that, I could at least get (some) pages to load, albeit with a few other issues. Namely, my theme was not being applied to the site. I’ll get to that in a minute though, because the problem I decided to fix next came in my CMS admin interface.

Pagination (even if you don’t want it)

I use the PaginatorHelper a lot, especially in the CMS admin. My CMS is modular: there’s a “module” (my term for any model-view-controller group) for pages, a module for blog posts, a module for uploaded files, a module for project porfolios, a module for the event calendar, etc. Each module is represented in the admin interface by a navigation tab, which when clicked takes the user to an index page with a paginated, tabular list of all of the records in the database for that module. In practice (on my own site — yes, I use my CMS to run my own site, of course!), it looks like this:

Unfortunately, the pagination was mysteriously hosed, with the following error:

Unsupported operand types in CAKE/libs/view/helpers/paginator.php
on line 616

What the…? Well, as it turns out, the methods $paginator->prev(), $paginator->next() and $paginator->numbers() have had changes to their input parameters that are currently not very well documented, in that the documentation doesn’t mention that they exist. They are mentioned in the API, but as usually happens when I refer to the API, I found it wanting, to the point that I resorted to digging into the source code directly to try to make sense of what these methods actually do.

In short, where you could previously pass these methods a URL as a string (as the second parameter for prev() and next() and the first for numbers()), now they expect arrays. And numbers(), in particular, really doesn’t like that parameter to be a string (because at one point it uses the += operator to merge two arrays, one of which is the first input parameter), resulting in the Unsupported operand type error.

Fortunately, in my case at least, I found that I didn’t need to pass the URL into any of these methods at all, and that just removing them altogether from the calls fixed the problem.

There was an ancillary problem once I got past the PHP error: inactive “Previous” and “Next” links were appearing on the page when there was no pagination. This was an unwanted addition, but I quickly realized this was an intentional change, and is well-documented. I was able quite easily to make them go away with a little CSS:

span.prev, span.next { display: none; }

With that minor crisis resolved, I could move back to the matter of the theme not showing up.

Changing themes

First, some background on my CMS: I’ve built the application so that I can have a single “core” system that works for numerous client websites, organized in a way that it’s easy to deploy updates across a number of separate sites. The system is also built to support multiple sites running on a single installation (by way of a Site model, with every piece of data in every other model having a site_id field keying the content to the proper site).

There are two key features of CakePHP that I rely on to make this all work: the look-and-feel (and site-specific view functionality) of each site is managed using Themes, and any site-specific controllers and views are handled with Plugins.

It is documented, unfortunately not in the migration appendix, that version 1.3 of CakePHP has changed how theme assets (static files like images, JavaScript and CSS) are organized. Now, instead of placing these in a directory under app/webroot/themed, you create a webroot directory inside the appropriate theme folder in app/views/themed. This is nice, in that now all of the files for a theme are in one location. It can cause a performance hit though, as these files are now being processed through PHP. You can still put the files under app/webroot to avoid this performance hit, but, annoyingly, the path has changed, as noted in the documentation. I decided to go with the new approach under app/views, as performance is not a major issue with the current implementations of my CMS, and the benefit of a single, consolidated directory for each theme is worth the trade-off. If performance does become an issue, though, at least now I know what to do about it.

More to come…?

After completing the above changes, I spent some time exploring my test application, both the user-facing site and the CMS admin interface, and so far I haven’t come across any other problems. Which is not to say I’m ready to roll this out to all of my clients tomorrow morning. I want to make the switch soon, as maintaining two separate code bases is a cumbersome task for a solo freelancer. But while things look good for now, this kind of major upgrade requires some solid testing and troubleshooting. If I run across any other issues, I’ll post them in Part Two.

Apple vs. Adobe: This is fargin’ war!

I’m sure I’m not the only child of the ’80s who watched Johnny Dangerously several (hundred) times as a kid. One of my favorite characters was Roman Moronie, whose command of the English language — well, more specifically, English profanities — was tenuous at best. I’m sure he would be highly offensive to a particular nationality or ethnic group, if it were possible to tell where he was actually from. (That mystery itself being a joke in the movie; at one point a newspaper headline reads: “Roman Moronie deported to Sweden — claims he’s not from there.”) Yes, I was a big fan of ’80s Michael Keaton movies that, in retrospect, are somewhat problematic. Johnny Dangerously, Mr. Mom. I think I partly liked him because I thought maybe he was related to the characters on Family Ties. OK, I was old enough to know better than that.

What does this have to do with Apple vs. Adobe, or anything for that matter? I’m not sure, but I do know that their battle has escalated to fargin’ war!

Steve Jobs fired the first metaphorical salvo last month with his Thoughts on Flash. I thought he nailed it, as expected. Of course Adobe can’t let him win, so yesterday Adobe retaliated with their “We [heart] Apple” / “We [heart] Choice” ad campaign and an open letter of their own.

The idea that Flash is somehow open — or that Apple is somehow trying to “close” the web — is both disingenuous and misguided. My natural inclination is to blather on ad nauseum about such things, but as I’m home with a sick kid today (which is to say, there’s enough nauseum in this house already), I’ll let some more pithy writers say it for me.

First, an excellent and concise response from Jim Whimpey in Brisbane, Australia (by way of John Gruber in Philadelphia):

Adobe: not open, claim to be.
Apple: not open, don’t claim to be, contribute heavily to that which is truly open.

If that’s not pithy enough for you, a picture is worth a thousand words. Via Jeffrey Zeldman in NYC:

Update: Over on the Macworld website, the Macalope has some choice words on this topic. It’s worth reading in its entirety, but here’s my favorite bit, dissecting excerpts from the Adobe open letter:

If the web fragments into closed systems, if companies put content and applications behind walls…

You mean like the wall of a lousy runtime environment that would just as soon crash the Macalope’s browser as play back a Daily Show clip? The wall of a development environment controlled by one company that makes some pretty good coin off the deal?

Oh, no. That’s not the wall you were talking about. Sorry. Go on.

…some indeed may thrive — but their success will come at the expense of the very creativity and innovation that has made the Internet a revolutionary force.

The Internet is an open range where anyone can compete in any way they like. But Adobe didn’t make the Internet. In fact, they tried to wall off a section of it. Apple, on the other hand, made its own walled garden with a scenic view of the Internet.

iPad: Son of Newton

There’s some buzz going around concerning Apple’s new iPad commercial and its similarity to one Apple produced for the Newton two decades ago. Though I’m not the first to comment on this, I have a few thoughts of my own, so here goes…

First, let’s watch both commercials. I did not remember this (apparently) “classic” (in John Gruber’s words) ad for the Newton:

Now, watch Apple’s new iPad ad:

Wow. Homage indeed. I doubt very many people remember the Newton commercial, but the iPad commercial is stunningly similar. This had to be deliberate, but I’m wondering what exactly that deliberateness is supposed to mean.

Well, I’ll tell you this: watching the two ads back-to-back, I’m left feeling that a) the Newton really was way ahead of its time, and b) the Newton ad seems like one of those futuristic concept videos Apple (among other computer makers) seemed to love producing in the 1980s.

Newton was a vision of the future. iPad is the reality. That Newton actually became a shipping product says a lot about Apple’s ability to realize its vision (compared to the long line of never-to-be-made concepts that have come from Microsoft over the years, most recently… well… this). But the Newton was too far ahead of its time. Then again, it ushered in the PDA era, which ushered in the “smartphone” era, which led to the iPhone and now the iPad. So maybe Apple was really seeding (if you’ll pardon the pun) its own future with the Newton.

There are two key lines that for me define the difference between the two ads:

“Newton can receive a page and sends faxes and, soon, electronic mail.”

“(iPad is) 200,000 apps and counting. All the world’s websites in your hands.”

Granted, paging and faxing were still relevant technologies when the Newton was released, but they were already doomed, and the best Apple could say was that “soon” Newton could handle “electronic mail” (even then, using a soon-to-be-antiquated term). In contrast, the iPad hits the ground running, leveraging the existing success of the iPhone, and with forward momentum for future technologies. Newton was about what could be, but iPad is.

TinyMCE and the relative URLs SNAFU

My CMS, cms34, uses a few third-party tools for certain complex features. One of the most useful is TinyMCE, a JavaScript/DOM-based drop-in WYSIWYG text editor. If that doesn’t mean anything to you, you probably want to stop here, but in case you’re a glutton for punishment, it is, in short, a way to produce HTML-formatted text with a word processor-like interface. Think Microsoft Word in a web browser, with the results being formatted for display on a web page. Slick.

Anyway, there’s been one nagging problem: When users paste in URLs for links, TinyMCE converts any on-site links into “relative URLs” — it strips out the domain name. This is not necessarily bad; in fact, for the most part I would want it to do that. But for some reason the nature of my CakePHP-based CMS seems to confound TinyMCE’s ability to properly determine the relative URL. And what’s worse, the CMS includes an enewsletter editor which has to have absolute URLs, but TinyMCE was converting them to relative URLs even if the user pasted in an absolute URL.

A little research led me to a handy explanation in the TinyMCE Wiki. Basically, if you want your URLs to always be absolute, make sure your TinyMCE configuration includes the following:

relative_urls : false,
remove_script_host : false,
document_base_url : “http://www.site.com/path1/”

Of course, you’ll want to change the value of document_base_url to be the actual base URL of your website. As it happens, my CMS has a global JavaScript file that creates a variable called baseUrl that I can use anywhere in JavaScript to substitute for the full base URL of the website. So, in my case, I set the value for document_base_url equal to baseUrl.

And, voilà, it seems to work!