WYSIMBH (what you see is my bloody head)
My bloody head. And no, I don’t mean that in the british sense. I mean my head is bloody as it often becomes when hitting it as hard as possible against a brick wall for days, weeks, even months on end. So, “why not stop?” you ask. Simple, because clients keep asking me to do it and I have to oblige, right?
Okay, enough of the fun little word-games. What I’m really talking about is WYSIWYG (what you see is what you get). You know, those cute little Word-like editing windows used in so many CMS systems to allow non-technical people the ability to update their site? Yeah I hate those things! Now I don’t believe my hatred is all that misplaced. I’ve lost a good number of brain cells over this issue, but I still think I can see clearly on this. Let me explain.
So, In our company we rarely use WYSIWYG editors in the sites we create. Generally we try to control what is being input by users both for ascetic purposes (You paid a lot of money for that nice site design, don’t let your secretary screw it up!). We’ve also refrained because it can make data input more convoluted. I would prefer to offer a separate input field for a google map link and then automatically link that within the site in the appropriate place, then require the user to build the link themselves through a WYSIWYG editor. It allows us to streamline that process better for our end users, while keeping consistency throughout the site.
However. recently we rolled our own full-blown, CMS system allowing us to plug in a design and then let our clients loose to add and edit pages to their hearts content. One of our key objectives in building our own CMS was that we wanted to build an application that positively refrained the design-challenged secretary or marketing staff (no offense!) from making a change that was disingenuous to the overall site design. As a result, within our CMS, we give our users discrete formated blocks to input various types of content, we refer to these as widgets. Now this is all good and dandy and we’re really pleased with our effort to date (as are many of our clients) but one thing we quickly realized we overlooked in our foray into the wild world of site-builders and CMS was that people still felt the need for a WYSIWYG editor. They wanted to be able to bold and italic their text, indent it and add lists, as well as superscript and add links inline. All these things are fine and reasonable so we set out on our quest to install a nice WYSIWYG editor. And this is where all the head-bashing begins...
WYSIWYG on the Web is really a nasty beast. It’s akin to putting a square peg into a round hole. I knew, because of the method we were already employing to allow users to get content onto their sites that a VERY limited set of options was necessary for our WYSIWYG editor. We literally ended up with bold, italic, link, ordered lists, and unordered lists. Simple, right? wrong. After playing around with a number of text editors (most of them being entirely overkill for what we needed/wanted) we finally landed on a pretty decent, and small package. We customized it a bit since we still only needed a very small subset of it’s functionality. We did some testing and all appeared to be good. But boy were we wrong.
Like all things, in real life (IRL) people use the Web in ways that I never consider, because I don’t normally work that way myself. For instance, in all my testing I never thought to try and actually copy and paste from Word into the WYSIWYG editor. The first thing our client did was exactly that. Now if you are a Web professional, you know this is evil and wrong, but most clients don’t know that, and simply telling them not to do it won’t solve the problem, they’ll do it anyway. But Word has this great little feature called “roundtripping” where they copy a bunch of formatting code along with the text so, in the event that you paste what you copied out of Word into, say, PowerPoint the formatting will be retained. Well, this code also finds it’s way into WYSIWYG editors as well. So, even though our WYSIWYG editor shouldn’t allow the user to change the font (that’s dictated by the sites style sheet) Word pastes in that beautiful Comic Sans that the secretary loves to use in her Word documents! Now we have a font (along with a lot of other Word-specific formatting) that we don’t want on the site, but got there from Pasting directly from Word.
We’ll we jumped on this issue as soon as we realized what was going on and quickly added a Word Crap Stripper (that’s my official name for it, seriously). This bit of code will kindly remove any formatting that we didn’t want to allow in the first place (bye, bye Comic Sans, the world would be a better place if you never existed!). We’ll this works to a degree, but now we are still having some issues. When a user copies in their text the code copied in sometimes gets interpreted as a paragraph (<p>) or a block (<div>) or simply a line break (<br />) each of these can, and most likely will, vary in the amount of space they place after the block of text. There is really no easy way in most WYSIWYG editors to make this uniform (depends a lot on where you copied your text from, and how that program interpreted it). So my option now is to also remove any <p>, <div>, and <br /> tags upon copying text into the editor. But now my client is mad, and for good reason, they just spent a fair chunk of time formatting their document in Word with paragraphs and everything, just to have it blown away the minute they copy it over. What’s a guy to do?
So, we remove all the <p> tags and replace them with <br /> tags upon pasting new text into the editor. We’re getting closer here. (and I’m going to skip some other VERY frustrating middle steps that had to do with an optional clean-up routine we ran in the event that the user or the WYSIWYG editor input invalid XHTML... that’s a story for another day, and honestly, bringing it up may cause a relapse for me).
Finally we are at a place where our editor is doing what we want 99% of the time. But now comes another issue. We’ve used an out-of-the-box solution which was much better than writing this business ourselves (or so I told myself), but now we are realizing more and more that things like the link dialog box doesn’t really flow with the rest of our application. Overall the editor feels very disjointed from the look and feel of the application itself. The editor has officially become the most time-consuming support issue, as well as the most out-of-place piece of code for the entire application. We need a way to wrangle this into shape. This is where we sit now. Debating whether is is better to try to build off what is existing or create a new editor from scratch that is able to more closely resemble the feel of our product.
Ultimately the real problem is that WYSIWYG is a poor representation for how the Web works. Furthermore, the technology to do it appropriately is, at best, lacking. Most Web browsers have differing levels of support and ability especially in relation to how javascript WYSIWYG works (I’m talking about you ExecCommand). It’s really a tough place for us, as a company, when the editor churns out junk because it accepts anything that Word will throw at it, we are the ones to take the blame. When it artificially limits them because we have to keep it from allowing too much junk, we have to take that blame, and it causes our clients to think twice about our ability, Finally, when an editor simply chokes because of the way the browser interprets a style to the SetCommand function in Javascript, we take the blame. I find myself having to defend a solution that, personally, I hate. But clients are out there who want to be able to manage their content, and that isn’t unreasonable. Until the technology can progress to the point that a simple, XHTML compliant code-producing editor can be a reality, I guess we will simply have to live in this imperfect Web world.
Graceful Degradation
As a Web developer, I'm asked from time-to-time what Web browser I prefer. I always emphatically answer that I use Safari. Many people look at me funny when I say that. Unless they are fairly versed in technology, they may not even know that a browser called Safari exists. It's quite possible that their work requires them to use IE, or because their computer came with IE pre-installed they use it. IE definitely is the big player on the block, but, unfortunately high market share doesn't necessarily equate to good quality. In fact, the reverse is more often true.
I always encourage people to use Safari whenever possible. For starters, Safari is built on top of WebKit. WebKit has become one of the most advanced HTML rendering engines. It's not only used by Safari, but also Google's new browser, Chrome, as well as in the Android phone platform, and a number of smaller Web browsers.
Safari also uses the fastest javascript engine currently out there, Squirrelfish. As more and more Web sites become Web applications, (think of gmail, or MobileMe), so does the need for better javascript interpreters. Safari's beats them all.
Finally, and this point I cannot understate, Safari/WebKit have the best standards support of any browser on the market today. Standards are important. They allow us to play by the same rules. Games are only enjoyable when we all play by the same rules. However, IE doesn't, or at least hasn't, felt like the rules applied to them. They have misinterpreted the rules, ignored the rules, and flat-out broken the rules. But thankfully there our browsers out there that care about standards. That's why I love Safari. The Safari/WebKit team cares about standards and they get it right.
Here is a nice little screenshot of how this site should look in Safari:
Now in firefox, pretty good, just missing the drop-shadow around the content area:
Finally, IE... It still works, but no rounded corners, no drop-shadow, even the positioning of elements had to be forced into place.
Now, you can still surf the Web using any browser you wish, but ultimately you'll only see the Web the way it was meant to be, when using something other than IE and for me, that "other" is Safari.
Classic Status 1.0
I've created a new dashboard widget that I think is fairly useful. I still have to use one classic application for my day to day work (come on Helix 6. Save us from classic forever!). And although I only use it for a few minutes each day, the classic environment ends up staying open almost all the time. Furthermore, the Tru Blue Environment (part of what makes classic run) seems to eat a fair portion of my CPU even when I don't have a classic app running. So, previously, my solution has been to go into System Preferences, click on classic, and then click stop. This seems rather tedious to me (although I'm also just plain lazy). To add to that, there is no quick and dirty way of knowing if classic is up or not. Unless you are currently running a classic app, there is no visual distinction that the classic environment is running. Therefore, this new widget displays the status of the classic environment (whether it is up or down), and if it is up allows you to click anywhere on the widget to quit classic. That's it, pretty simple all in all. Hope someone can find some use out of it.