There’s a lot of talk about HTML5 and CSS3 these days, especially since Safari/Chrome, Firefox, and Opera have begun supporting some of the most anticipated features of both specifications.  If you’ve ever used border-radius or box-shadow then you’ve already touched on CSS3 a bit.  However, the chances are that, at least at the time of this writing, you haven’t done much with HTML5.  And, chances are, it’s probably because you’ve heard about the lack of browser support for HTML5 thus far (which is to be expected, considering that the specification is still just a draft).

That said, I stumbled across a very interesting framework today that may help bridge the gap between the present and the future — when HTML5 and CSS3 is supported by all major browsers.  52Framework boasts features such as rounded corners, text-shadow, box-shadow, HTML5 markup, a grid system, and a built-in CSS reset.  Best of all, it’s compatible with all major browsers, including the infamous IE6.  You can see a working demo of an HTML5 page using with 52Framework on their website or download the latest release from their homepage.  If you’re just curious to see what it’s all about, you can take a peak at what’s inside the box.

Although still in beta, 52Framework looks like a promising alternative for anyone looking to take advantage of the upcoming HTML5 + CSS3 specifications.  As nice as it is, however, I don’t think it’s something I would rely on for heavy production use…at least not without some very thorough testing on a lot of different browsers.

PHP is by far my favorite server-side scripting language, so it comes as no surprise that I’m really excited about HipHop for PHP.  HipHop was developed over at Facebook and serves as a means to speed up code execution and reduce server demand.  From the Facebook Developer Blog:

HipHop for PHP isn’t technically a compiler itself. Rather it is a source code transformer. HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it. HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features — such as eval() — in exchange for improved performance. HipHop includes a code transformer, a reimplementation of PHP’s runtime system, and a rewrite of many common PHP Extensions to take advantage of these performance optimizations.

What type of impact can HipHop have on your hardware?

With HipHop we’ve reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page. Less CPU means fewer servers, which means less overhead. This project has had a tremendous impact on Facebook. We feel the Web at large can benefit from HipHop, so we are releasing it as open source this evening in hope that it brings a new focus toward scaling large complex websites with PHP.

It’s great to see a company such as Facebook making this type of contribution back to the community, especially in the form of open-source software.  One thing is for sure, it will be interesting to see what HipHop can do for PHP as it evolves with the support of the open-source community.

Update (04 February 2010)

The creator of PHP, Rasmus Lerdorf, comments on HipHop:

[Lerdorf] continued to say that raw execution speed was “not a significant factor” for many applications. “Even if you double the execution speed of something that is 10% of your overall request cost, that is only a 5% overall improvement. If on every request you are hitting memcache/postgresql/mysql 10 times and spending a lot of time in system calls, don’t expect miracles from HipHop.”

He also worries that developers will see HipHop as “some kind of magic bullet” for performance, which could lead to lazy or bad development habits.  Instead, Lerdorf recommends holding off on HipHop until the runtime is the biggest thing that’s stopping a site from being as fast as possible.  This is a very good point, since many developers don’t even both to do basic optimization.

It seems as though HipHop may not be as “Hip” as Facebook claims — unless you’re running a Facebook-sized app.

Last week we released a new and improved version of Surreal CMS, and we couldn’t be happier with the feedback that everyone has provided so far.  We put a lot of effort into this version, even working through the holidays to make sure that everything was up to standard for the January release.  Needless to say, we’re very happy that everyone liked it.

As you can probably imagine, operating an online service for thousands of users means there is a lot of pressure to get things right.  You end up making a lot of promises and, at times, it can be difficult to accommodate everyone’s needs.  Part of our goal as a service provider is to balance out all of the features that people want with what is practical, feasible, and within the scope of what the average user expects to see from our service.  When the time comes, we combine all of the feedback that gets emailed to us with the suggestions that get posted on UserVoice to come up with a list of features that might make it into a future release.  Once we have a very concise list of ideas, we start evaluating, prioritizing, planning, and developing them.

With that in mind, here is an overview of some of the major features that went into this latest release.

User Interface

When we decided to revamp the user interface, we new it would be an extensive undertaking, but the end result was worth it.  What you may not realize at first glance is that the entire interface was completely rewritten for this version — from the markup all the way to the scripting that powers most of the functionality.  This was necessary for a number of technical reasons, but at the same time it allowed us to comply more closely with W3C standards.  Here is a glimpse of what the new UI looks like:

Character Encoding

Aside from the interface, we also took on some back-end encoding issues that previously made it impossible to support languages with characters outside of the ISO-8859-1 spectrum.  This includes languages such as Chinese, Russian, Polish, and many others.  Fortunately, this is no longer an issue with the new version. (You may have already noticed that Polish and Chinese are already available.)  We’re looking forward to translating Surreal CMS into a variety of new languages, so if you’re multilingual and we don’t support your language yet, get in touch with us and you may just earn yourself a free pro account.

Image Editor

This was something that people have been requesting for quite awhile, and we wanted to make sure that it made the cut this time.  The image editor allows you to resize, flip, rotate, and crop images without leaving the CMS.  You can access the image editor from within the File Manager by selecting a picture and clicking Edit Image. (You can also access the Image Editor if you have an <img class=”editable”> in your webpage.)

Customizable Toolbars

In the previous version, you could give your editors a Limited or a Full version of the rich-text editor.  Now, you can turn each and every button on and off, as necessary.  We’ve also enabled a few more options, including font size, foreground color, background color, underline, and a button for uploading and inserting documents.  (You can customize your editor’s toolbars by going to Editors > Configure > Advanced.)

Custom Paths

With the addition of custom paths for documents, images, and media, we were finally able to fix the permissions in the File Manager.  When you set custom paths, editors will be restricted to those locations when uploading, deleting, renaming, etc. In other words, your editors will only be able to upload and modify files and folders in the locations that you specifically set for documents, images, and media.  (You can set these paths on a per-website basis by going to Websites > Configure > Advanced.)

This is obviously more secure than allowing editors full access to every folder in their website, especially for novice users.  If necessary, you can re-enable full access to the File Manager by turning on that button in the editor’s toolbar.  Also, if you don’t set any custom paths, your editors will still have access to the entire website via the File Manager.

Welcome Emails

Many users wanted the option of disabling the welcome message that gets sent when editors are created.  In the new version, you can uncheck the Send Welcome Message button prior to adding an editor and the temporary password will be displayed on screen rather than being emailed.  You can also reset passwords without sending an email as well.

For those of you who would like to continue using the welcome messages, you’ll notice that they now come from Your Name <you@your-email.com>.  That is, the emails will appear to come from the name and email address that we have on file for you.  (You can change your name and email address by visiting My Account > Preferences.)

Larger Max Upload Size

We’ve increased the upload size from 10MB to 20MB.  This was actually updated a few months back, but we never formally announced it.

Help & Support Tab

By default, when editors submit a support request it gets emailed directly to their designer.  Now, you have the option to set a custom URL for the support tab, which can be used to direct editors to a custom support page.  You also have the option of completely disabling the Help & Support tab in case you’ve given your users alternative instructions for submitting help requests.

Search Filter

To help you sort through large numbers of websites, webpages, and editors, we’ve added a search filter to each page.  Whenever there are more than 10 items in any of these lists, you’ll be able to find exactly what you’re looking for with just a key keystrokes — no more scrolling, browsing, and squinting.

Payment History for Pro Accounts

If you’ve signed up for a pro account, you can see your complete payment history by accessing My Account > Payment History.

What’s to Come?

We have a lot more great ideas and features in store for you in upcoming releases but, for starters, we’re going to be working on some white-label documentation that you can provide to your clients for training purposes.  This will include both screencasts and printable material that you can hand out to them in person.

As usual, please keep the feedback coming!  You can submit your ideas through our UserVoice page or send them directly to us from the Help & Support section inside the CMS.

And, of course, if you’re reading this but you haven’t signed up for a free account with Surreal CMS yet, there’s never been a better time.

Last night I received a very unexpected email from the Google Apps Team claiming that, in late 2010, they will start phasing out support for Microsoft Internet Explorer 6.  From the email:

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology.  This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010.  After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting next week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser.  We will also alert you again closer to March 1 to remind you of this change.

This is obviously great news for designers and developers all over the world, as this kind of encouragement from a company as big as Google will help outmode the infamous browser a lot sooner than expected.  As you may recall, some other popular online services have recently made similar announcements:  YouTube, Orkut, MobileMe, 37 Signals (the makers of BaseCamp) and, of course, our very own Surreal CMS.

After spending some time looking for a plugin to do this, I was amazed to see how easy it was to get a smooth scrolling effect using one line of jQuery.  You can use this inside of any callback function.  It works especially well with click.

$('html, body').animate({
	scrollTop: $("#elementID").offset().top
}, 2000);

Although LocalScroll is good for more advanced applications, this snippet is useful for one-time use applications.  Simply adjust #elementID and 2000 to set the element and duration, respectively.

It’s been awhile since our last major update to Surreal CMS, but that’s what happens when you’re busy making an awesome CMS even more awesome. The good news is that we’re finally ready to show the world all of the great new features and enhancements that we’ve been working so hard on!

beta.edit-content.com

That said, next weekened we will be releasing the newest version of Surreal CMS.  We’ve already received incredible feedback from some of our users, but now it’s time to hear from the entire Surreal CMS community.

What to Expect in the New Release

Here are just some of the new features and enhancements that you can expect to see:

Improved User Interface / Icon Set

The general idea is the same, but we’ve made the CMS a lot cleaner and much more professional looking.  Now you can see at a glance how many webpages each site has and which websites editors are assigned to.  We also got a shiny new logo :)

Image Editor

Now you can resize, crop, flip, and rotate images right from the CMS:

Customizable Rich-text Editor Toolbar

Now with more options than ever!  You can easily enable or disable every feature in the toolbar on a per-editor basis.

Custom Paths for Images, Documents, and Media

Now you don’t have to worry about editors cluttering up the root directory with documents, images, and other files.  When you set custom paths, editors will only have access to those directories on the website.  (Websites > Configure > Advanced)

Edit CSS, JavaScript, and XML Files

Now you can enable CSS, JavaScript, and XML files as if they were regular webpages.  (Syntax highlighting is coming soon!)

Optional Welcome Email

Because sometimes it’s more convenient to send editors a welcome email yourself.  There is also a no-email option to reset editor passwords now.

Purge Webpage History

As a Designer, sometimes you may not want your editors to access certain page revisions.  Now you can purge one or all revisions of each webpage.

View Payment History (Pro Accounts Only)

Now you can see all of your payment history under the My Account tab.

During the Release

We really hope that you’ll enjoy all of the new features that we’ve been working on for you.  In the past, we’ve launched enhancements with virtually zero noticable downtime.  We plan on carrying on that same tradition on launch day next week, so you have little to worry about.

Speaking of launch day, the new version will be available a week from today on Saturday, January 23, 2010.

Update (23 January 2010): The new version is up and running, so go check it out!

The Problem

When it comes to textareas, the concept of word-wrapping is not as easy as it should be. In most browsers, including Firefox, Safari, Chrome, and Opera, you can set the textarea’s wrap attribute to on or off to achieve your preference.  Internet Explorer, on the other hand, requires a special value for the wrap attribute.

Although it should be simple enough to check for the browser type and toggle the appropriate value for wrap on-the-fly, there’s one more problem.  Because it’s not technically a valid attribute, most browsers (other than IE) won’t respond to changes to the wrap attribute that occur via JavaScript.  This means that if you want to have a checkbox next to your textarea that enables and disables word-wrapping dynamically, you’re out of luck.

The Solution

To work around this problem, we need to first check for the browser type and go from there:

1. If IE, update the wrap attribute to be either soft or off
2. If not IE, clone the textarea, set the appropriate wrap attribute, and update the DOM

Here is a really simple jQuery plugin that I’ve created to do just that.

The jQuery Word-wrap Plugin

The plugin is really easy to use.  Just make sure to include jQuery and the plugin in your page:

<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
<script type="text/javascript" src="jquery.wordWrap.js"></script>

To enable and disable word-wrapping on-the-fly, simply call the wordWrap() method at any time:

$(document).ready( function() {

	// Enable word-wrapping
	$("TEXTAREA").wordWrap('on');

	// Disable word-wrapping
	$("TEXTAREA").wordWrap('off');

});

You can use any standard jQuery selector.   Note that browsers have word-wrapping enabled by default for textarea elements.

Demo

View a working demo of this plugin.

Download

Version 1.0

This plugin is provided to you as-is, at absolutely no cost. If you would like to support its development, feel free to contribute any amount you prefer via PayPal. As always, you are welcome to contribute code for bug fixes and feature enhancements as well. Either way, thanks for supporting our efforts!

Back in November, I wrote about an incredible NES emulator written entirely in JavaScript.  Today I would like to introduce you to Effect Games, a company that provides free, online tools that enable you to build JavaScript-based games.

These aren’t just any games, though.  We’re talking about games that include music, sound effects, and multiple layers of scrolling.  These are games that work in all popular browsers, including IE, without any noticeable speed issues.  (You might recall that JNES can’t currently run in IE and is miserably slow even in Firefox.)  If you’re the kind that has to see it to believe it, try out one of their demos.

The Super Mario Bros. demo was recreated (read: not emulated) using the Effect Engine.  Proof of this exists in the fact that you can move back and forward through the levels, unlike the original where you can only move forward.  The Crystal Galaxy demo uses a unique mouse control scheme, which makes game play really interesting and intuitive.  If you prefer shooter-style games, try out the absOrb demo, a reverse-shooter game being created by GoldCartridge.com.

This remarkable JavaScript-based game engine helps prove that JavaScript has the potential to do many of the same things that Flash can.  As it continues to evolve and browser vendors continue to optimize their JavaScript engines, it’s very likely that we’ll see native support for hardware such as gamepads, webcams, and microphones in the future.

Flash? Silverlight?  No, thanks.  I’ll stick with good ol’ fashioned JavaScript!

If you’ve ever worked in, on, with, or around the Internet, you’ve undoubtedly heard the terms “Web Designer” and “Web Developer”.  Oftentimes, the two phrases are used interchangeably by someone who is not familiar with the industry.  Perhaps the concept is irrelevant to a client who just wants to get their website up and running.  Or to a server administrator who has his concerns in the silicon, steel and software that power your website.  And what about the nice lady over in Human Resources who blotches up the job posting during the hiring process?  I mean — designer and developer — they’re the same thing, right?

Let’s face it, if you have the word “Web” in your euphemism, you’ve probably been hammered with questions from both sides of the playing field.  Designers will hear things like “how can we add a database to the website?”, while developers struggle to answer questions about layout, color selection, image placement, and font styles.

The truth is, however, that most Web Designers don’t know a thing about Base64 encoding, MIME types, SOAP requests, regular expressions, or SQL injection.  On the flip side, there aren’t a lot of Web Developers that can create visually stunning websites which gloat the type of appeal that Rembrandt himself would appreciate.

Due to the demanding nature of the industry, it’s all too common to find individuals who are unqualified, inexperienced, or simply not very good at one or the other trying to make their way through a project that requires both creative and technical skills.  This is why many underfunded, poorly planned Web-based projects fail.  Most of the blame can usually be attributed to the fact that not a lot of people actually understand what the difference is between a Web Designer and a Web Developer.  This includes everything from skillsets to the actual role each position plays in the formation of a Web-based project.

Perhaps the most effective way to differentiate between the two positions is to establish a clear line that separates the roles and responsibilities of each position in the context of a Web-based project.  This will, of course, vary from project to project and from person to person, but we can define a reasonable boundary which the average Web Designer and Web Developer will be comfortable with.

What Exactly is a Web Designer?

The best Web Designers are of the creative type.  They have a knack for getting inside of their clients’ heads and realizing their clients’ vision.  They take this vision and masterfully convert it into an aesthetically pleasing, artistic Design that aims to impress millions of potential viewers.  Some designers study typography, user interface design, and usability.  Most include tools such as Photoshop, Illustrator, and DreamWeaver in their arsenal and frequent sites such as iStockPhoto, Kuler, and a long list of CSS galleries.

It is common, albeit arguable, that a designer’s role should also include slicing images, writing (X)HTML, coding CSS, and drafting or editing copy.  For the most part, you can think of a Web Designer as a creative expert.

What Exactly is a Web Developer?

Web Developers are usually more technical in nature.  They tend to have excellent problem solving skills and are generally good at math.  On a daily basis, a developer will write code in five or more different languages including (X)HTML, CSS, JavaScript, [PHP, ASP, ColdFusion, Ruby, Python, Perl, etc.], and some flavor of SQL.  Web Developers can usually be found wielding some kind of text editor or IDE, an FTP client, three or more web browsers, and development plugins such as Firebug.  They frequent sites similar to the PHP manual, the Mozilla JavaScript reference, and the jQuery Documentation.  A developer also knows what an API is and how to develop with it.

Although Web Developers are sometimes referred to as programmers, their skills usually exceed those of a conventional software developer.  Think of a Web Developer as more of a technical expert with programming skills.

What About People That Do Both?

As suggested earlier, it is actually quite common for Web Designers and Web Developers to be expected to take on tasks that are outside of their personal skillsets.  In my experience, I would only consider a very small number of people that I’ve worked with to be proficient in both design and development.  In most cases, you’ll find a cocky developer that thinks his designs are the greatest thing that ever hit the Internet when, in reality, they’re mediocre at best.  It’s far less common to find a designer who thinks he can code up an entire Web application.

So, Which One Should I Choose?

Which one you choose depends on what exactly you are trying to do, but in many cases your project will require skills from both.  If you’re looking to start a new website or to redesign your old one, you’ll want to look for someone with design talent.  If you’re looking for some kind of database, E-Commerce solution, or integration with another application, you’ll want to look for someone with strong development skills.

Despite the fact that this writing strives to define the difference between Web Designers and Web Developers, the reality is that you’re bound to find designers who know at least a little bit about development and developers who know at least a little bit about design.  Although both are very different positions which provide entirely different skillsets, the fact of the matter is that most designers and developers have, or will at some point, become factotums — at least to a certain degree.  Some may never bother to differentiate themselves as one or the other.

Perhaps the most important aspect of managing a Web-based project is being able to determine what skills a particular project requires, and who is the right person for the job.  In this industry it is very clear that, despite a reasonable separation of roles and responsibilities, an individual’s job title is not always a reflection of their personal expertise.  It is, alas, more often an indication of their position in terms of demand and naivety.

There are two reasons that TinyMCE might be removing non-breaking space entities (&nbsp;) from your HTML source code.  The first one is a common mistake people make when populating textareas.  This is covered in the TinyMCE FAQ, so there’s really no need to elaborate on this particular reason.

The second reason, however, is a bit more complicated, and only occurs if you have the entity_encoding property set to raw:

tinyMCE.init({
	mode : "textareas",
	theme : "advanced",
	...
	entity_encoding: 'raw'
});

If your configuration looks similar to this, you’ll most likely see all of your &nbsp; entities get converted to regular spaces when you switch between HTML view and WYSIWYG view.  The easy solution would be to set entity_encoding to either named or numeric.  Fortunately, if you’re using ISO-8859-1 for your character encoding, you’re all set.  Unfortunately, if you’re using UTF-8 you’ll need to take an additional step to prevent many of your non-English characters from appearing as HTML entities.

The solution is simple.  Set your entity_encoding to named and overwrite the entities property:

tinyMCE.init({
	mode : "textareas",
	theme : "advanced",
	...
	entity_encoding: 'named',
	entities: '160,nbsp'
});

The above is the same thing as using raw entity encoding, except that your non-breaking space entities will be preserved.