Die Entwicklungsumgebung Aptana PHP steht in einer ersten Version 1.0 zum Download bereit. Die Software basiert auf Eclipse und bietet Funktionenwie z.B. ein integrierter Codeassistent, eine Debuggerunterstützung, Syntaxhervorhebung, Codegenerierung und Refactoring. Dazu noch PHP-typische Funktionen wie ein eingebetteter PHP-Server, Unterstützung für Remote-Debugging und die PHPDoc-Erstellung.

PHP development and deployment just got way easier. Today, we’re pleased to announce the 1.0 availability of the Aptana PHP development environment. It’s got all the things you’d expect from a PHP IDE, plus all the Ajax tooling and other power tools from Aptana Studio. Combine that with the integrated PHP app hosting, staging and management features in Aptana Cloud and you’ve got an end-to-end PHP development and deployment environment with unprecedented ease of use.

Meldung auf der Aptana Website

YUI 3.0 Preview Release 1 was made available on Wednesday, and with it we provided a look at how the next major iteration of YUI is taking shape. Among the elements we shipped with the preview is a new example from Dav Glass, the Draggable Portal, which exercises a broad cross section of the preview’s contents.

The Draggable Portal is a common design pattern in which content modules on the page can be repositioned, minimized, removed, and re-added to the page. The state of the modules persists in the background, so a reload of the page or a return to the page calls up the modules in their most recently positioned state. You see variations of this design pattern on many personlizable portals like My Yahoo, NetVibes, and iGoogle.

In this article, we’ll take a look under the hood of this example to get a richer sense of YUI’s 3.x codeline and the idioms and patterns it establishes. We’re just pulling out some specific code snippets to examine here, but you can review the full code source for this example — and for 66 others — on the YUI 3 website.

(more…)

(Via Yahoo! User Interface Blog.)

The YUI team is pleased to announce the public availability of YUI 3.0 Preview Release 1, an early look at what we’re working on for the next generation of the YUI Library. Documentation for YUI 3.0 is on the YUI website; the download is available on the YUI project area on SourceForge; you can find us with questions or comments on the YUI 3.x discussion forum. Keep in mind that this is an early preview, not a production-quality (or even a beta) release. This release is not suitable for production use, but it will give you an idea of what we’re working on, and it should provide a good framework for conversation about the future of the library.

Five Goals for YUI 3:

We’ve talked to thousands of YUI users over the past 30 months, and based on that feedback we’ve set five design goals for the next generation of the library. What you’ve told us is that YUI 3.0 should be:

• lighter (less K-weight on the wire and on the page for most uses)
• faster (fewer http requests, less code to write and compile, more efficient code)
• more consistent (common naming, event signatures, and widget APIs throughout the library)
• more powerful (do more with less implementation code)
• more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)

With this early release, we’ve made progress toward most of these objectives — and we believe we have the right architecture in place to meet all five as we move to GA over the next few quarters.

What’s New in YUI 3.0?

When you start to write code using YUI 3.0, you’ll notice some changes in structure and style. Here’s a taste:

YUI().use('node', function(Y) {
    Y.get('#demo').addClass('enabled');
});

YUI().use('dd-drag', function(Y) {
        var dd = new Y.DD.Drag({
        node: '#demo'
    });
});

Y.all('.demo').addClass('enabled');

Y.all('.demo').set('title', 'Ready!').removeClass('disabled');

Y.get('#demo').plug(Y.Plugin.Drag, {
    handles: 'h2'
});

Y.on('click', function(e) {
    e.preventDefault();
    e.target.query('em').set('innerHTML', 'clicked');
}, '#demo a');

What’s different here?

• Sandboxing: Each YUI instance on the page can be self-contained, protected and limited (YUI().use()). This segregates it from other YUI instances, tailors the functionality to your specific needs, and lets different versions of YUI play nicely together.
• Modularity: YUI 3 is architected to use smaller modular pieces, giving you fine-grained control over what functionality you put on the page. If you simply want to make something draggable, you can include the dd-drag submodule, which is a small subset of the Drag & Drop Utility.
• Self-completing: As long as the basic YUI seed file is in place, you can make use of any functionality in the library. Tell YUI what modules you want to use, tie that to your implementation code, and YUI will bring in all necessary dependencies in a single HTTP request before executing your code.
• Selectors: Elements are targeted using intuitive CSS selector idioms, making it easy to grab an element or a group of elements whenever you’re performing an operation.
• Custom Events++: Custom Events are even more powerful in YUI 3.0, with support for bubbling, stopping propagation, assigning/preventing default behaviors, and more. In fact, the Custom Event engine provides a common interface for DOM and API events in YUI 3.0, creating a consistent idiom for all kinds of event-driven work.
• Nodes and NodeLists: Element references in YUI 3.0 are mediated by Node and NodeList facades. Not only does this make implementation code more expressive (Y.Node.get('#main ul li').addClass('foo');), it makes it easier to normalize differences in browser behavior (Y.Node.get('#promo').setStyle('opacity', .5);).
• Chaining: We’ve paid attention throughout the new architecture to the return values of methods and constructors, allowing for a more compressed chaining syntax in implementation code.

And that’s just the beginning. Dive into the examples to learn more and to see the preview release in action, including some hidden gems like full A-Grade cross-domain requests. Our resident metahacker Dav Glass created a nice multi-component example, the draggable portal, that will give you some sense of what’s included in today’s preview.

Is YUI 3.0 Backward Compatible with YUI 2.x?

No. YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.

We know that ease-of-migration will be a critical factor for all YUI users. We’re taking two important steps to facilitate the transition as it arrives:

• Limited compatibility layer: YUI 3.0 will ship with a limited compatibility layer for the current YUI Core (Yahoo Global Object, Dom Collection, and Event Utility). This will allow you to run many of your YUI 2.x-based implementations on top of YUI 3.0. We’re not shipping the compatibility layer with today’s preview, but you’ll see it appear in a future preview or beta release prior to GA.
• Full parallel compatibility: YUI 3.0 can be run in parallel to YUI 2.x with no side effects for either version. If you choose to make the transition in stages, you can run the full 2.x stack and 3.x stack together as needed.

Even with these provisions in place, we know that an API change (along with new concepts and idioms) has a real cost for everyone involved. We’re convinced that this change is both necessary and worth the effort, and obviously we’re going to work hard to make the value proposition compelling.

What’s Next?

YUI 3.0 is a work in progress. The common widget framework for 3.0 is not included in this preview and we’re continuing to work on refinements to the core — including optimizations to the package structure to minimize base K-weight. We anticipate the next two releases coming up as follows:

• October 2008 — PR2: Widget Framework, sample widgets, additional utilities.
• December 2008 — Beta 1: Final mix of module structures, API completion, full complement of utilities.

We have some great stuff to share as we move further along in this process. We’ve never been more excited about YUI and its future — and we think YUI 3.0 will have a big role to play in that future.

(Via Yahoo! User Interface Blog.)

External JavaScript files block downloads and hurt your page performance, but there is an easy way to work around this problem: use dynamic scripts tags and load scripts in parallel, improving the page loading speed and the user experience.

The problem: scripts block downloads

Let’s first take a look at what the problem is with the script downloads. The thing is that before fully downloading and parsing a script, the browser can’t tell what’s in it. It may contain document.write() calls which modify the DOM tree or it may even contain location.href and send the user to a whole new page. If that happens, any components downloaded from the previous page may never be needed. In order to avoid potentially useless downloads, browsers first download, parse and execute each script before moving on with the queue of other components waiting to be downloaded. As a result, any script on your page blocks the download process and that has a negative impact on your page loading speed.

Here’s how the timeline looks like when downloading a slow JavaScript file (exaggerated to take 1 second). The script download (the third row in the image) blocks the two-by-two parallel downloads of the images that follow after the script:

Here’s the example to test yourself.

Problem 2: number of downloads per hostname

Another thing to note in the timeline above is how the images following the script are downloaded two-by-two. This is because of the restriction of how many components can be downloaded in parallel. In IE <= 7 and Firefox 2, it’s two components at a time (following the HTTP 1.1 specs), but both IE8 and FF3 increase the default to 6.

You can work around this limitation by using multiple domains to host your components, because the restriction is two components per hostname. For more information of this topic check the article ‘Maximizing Parallel Downloads in the Carpool Lane’ by Tenni Theurer.

The important thing to note is that JavaScripts block downloads across all hostnames. In fact, in the example timeline above, the script is hosted on a different domain than the images, but it still blocks them.

Scripts at the bottom to improve user experience

As Yahoo!’s Performance rules advise, you should put the scripts at the bottom of the page, towards the closing </body> tag. This doesn’t really make the page load faster (the script still has to load), but helps with the progressive rendering of the page. The user perception is that the page is faster when they can see a visual feedback that there is progress.

Non-blocking scripts

It turns out that there is an easy solution to the download blocking problem: include scripts dynamically via DOM methods. How do you do that? Simply create a new <script> element and append it to the <head>:

var js = document.createElement('script');
js.src = 'myscript.js';
var head = document.getElementsByTagName('head')[0];
head.appendChild(js);

Here’s the same test from above, modified to use the script node technique. Note that the third row in the image takes just as long to download, but the other resources on the page are loading simultaneously:

Test example

As you can see the script file no longer blocks the downloads and the browser starts fetching the other components in parallel. And the overall response time is cut in half.

Dependencies

A problem with including scripts dynamically would be satisfying the dependencies. Imagine you’re downloading 3 scripts and three.js requires a function from one.js. How do you make sure this works?

Well, the simplest thing is to have only one file, this way not only avoiding the problem, but also improving performance by minimizing the number of HTTP requests (performance rule #1).

If you do need several files though, you can attach a listener to the script’s onload event (this will work in Firefox) and the onreadystatechange event (this will work in IE). Here’s a blog post that shows you how to do this. To be fully cross-browser compliant, you can do something else instead: just include a variable at the bottom of every script, as to signal ‘I’m ready’. This variable may very well be an array with elements for every script already included.

Using YUI Get utility

The YUI Get Utility makes it easy for you to use script includes. For example if you want to load 3 files, one.js, two.js and three.js, you can simply do:

var urls = ['one.js', 'two.js', 'three.js'];
YAHOO.util.Get.script(urls);

YUI Get also helps you with satisfying dependencies, by loading the scripts in order and also by letting you pass an onSuccess callback function which is executed when the last script is done loading. Similarly, you can pass an onFailure function to handle cases where scripts fail to load.

var myHandler = {
    onSuccess: function(){
        alert(':))');
    },
    onFailure: function(){
        alert(':((');
    }
};

var urls = ['1.js', '2.js', '3.js'];
YAHOO.util.Get.script(urls, myHandler);

Again, note that YUI Get will request the scripts in sequence, one after the other. This way you don’t download all the scripts in parallel, but still, the good part is that the scripts are not blocking the rest of the images and the other components on the page. Here’s a good example and tutorial on using YUI Get to load scripts.

YUI Get can also include stylesheets dynamically through the method
YAHOO.util.Get.css() [example].

Which brings us to the next question:

And what about stylesheets?

Stylesheets don’t block downloads in IE, but they do in Firefox. Applying the same technique of dynamic inserts solves the problem. You can create dynamic link tags like this:

var h = document.getElementsByTagName('head')[0];
var link = document.createElement('link');
link.href = 'mycss.css';
link.type = 'text/css';
link.rel = 'stylesheet';
h.appendChild(link);

This will improve the loading time in Firefox significantly, while not affecting the loading time in IE.

Another positive side effect of the dynamic stylesheets (in FF) is that it helps with the progressive rendering. Usually both browsers will wait and show blank screen until the very last piece of stylesheet information is downloaded, and only then they’ll start rendering. This behavior saves them the potential work of re-rendering when new stylesheet rules come down the wire. With dynamic <link>s this is not happening in Firefox, it will render without waiting for all the styles and then re-render once they arrive. IE will behave as usual and wait.

But before you go ahead and implement dynamic <link> tags, consider the violation of the rule of separation of concerns: your page formatting (CSS) will be dependent on behavior (JS). In addition, this problem is going to be addressed in future Firefox versions.

Other ways?

There are other ways to achieve the non-blocking scripts behavior, but they all have their drawbacks.

Future

Safari and IE8 are already changing the way scripts are getting loaded. Their idea is to download the scripts in parallel, but execute them in the sequence they’re found on the page. It’s likely that one day this blocking problem will become negligible, because only a few users will be using IE7 or lower and FF3 or lower. Until then, a dynamic script tag is an easy way around the problem.

Summary

• Scripts block downloads in FF and IE browsers and this makes your pages load slower.
• An easy solution is to use dynamic <script> tags and prevent blocking.
• YUI Get Utility makes it easier to do script and style includes and manage dependencies.
• You can use dynamic <link> tags too, but consider the separation of concerns first.

(Via Yahoo! User Interface Blog.)

The YUI development team released version 2.5.2 today; you can download the new release from SourceForge or configure your implementation using the YUI Configurator. This is a focused release that addresses several key bugs while providing support for Firefox 3 and Opera 9.5, both of which are expected to reach GA this summer. Key points for YUI 2.5.2:

• Anticipating Opera and Firefox updates: When Firefox 3 and Opera 9.5 go GA this summer, they will be A-Grade browsers, and we wanted to make sure that we anticipated those debuts with a release that was validated against the latest betas available. YUI 2.5.2 was tested against Opera 9.5b2 and Firefox 3.0RC1. In both cases, the new browsers look terrific, and this YUI release incorporates several changes that will help users make the upgrade seamlessly.
• Major bug fixes: DataTable, Menu, Rich Text Editor and Button are the key beneficiaries of bug fixes in 2.5.2, but dozens of fixes are provided throughout the library. Check out George Puckett’s release rollup in the YUI Community Forum for a complete rundown of what has changed in this release.
• Charts Control: The experimental Charts Control is upgraded for 2.5.2 with support for integral legends and for three new series styles.
• ActionScript Source: The ActionScript source for components that use Flash (Charts and Uploader) is now available as part of the download for developers who want to dig more deeply into these components.

After you’ve downloaded YUI 2.5.2 (or changed your pathnames using Yahoo!’s free edge-hosting service), head over to the YUI Community Forum and let us know how it’s working for you.

(Via Golem.de.)

The YUI Team just released version 2.5.0 of the library. We’ve added six new components — Layout Manager, Uploader (multi-file upload engine combining Flash and JavaScript), Resize Utility, ImageCropper, Cookie Utility and a ProfilerViewer Control that works in tandem with the YUI Profiler. This release also contains major improvements to the DataTable Control and new Dual-Thumb Slider functionality in the Slider Control. Here are the highlights:

• DataTable Control: Jenny Han Donnelly has been joined by Luke Smith for this development cycle, and we’re all thrilled with what they’ve produced. DataTable in 2.5.0 gets a more robust markup structure that allows greater control over all aspects of the table. This release also includes major performance enhancements, improvements to the fixed-header implementation for vertical scrolling, built-in support for horizontal scrollling, an all-new Paginator class, support for drag-and-drop column reordering, and a new set of column APIs with hooks for showing, hiding, adding and removing columns.
  
  DataTable has been one of YUI’s most popular and important components since its debut, and this is its strongest release yet. If you have existing DataTable implementations that you want to upgrade, take a look at the new User’s Guide, as it has some detailed notes about API changes. The DataTable examples roster is another nice place to check out the new code in action.
• Layout Manager: Dav Glass has a lot for you to enjoy in 2.5.0, but top billing goes to his new Layout Manager. Layout Manager eases development of multipane UIs that take up either the full viewport or the full canvas of any block-level element. Layout Units within a layout are resizeable, collapsible, removable and swappable; transitions between expanded and collapsed states have built-in animation support. Whether you’re creating a full-screen application like Yahoo! Mail or a rich multi-pane pop-up, Layout Manager is a great place to start.
• Uploader: If you’ve ever built a UI for uploading files via a browser, you know what the big pain points are: One file at a time, no easy way to track upload progress, no programmatic access to file metadata, etc. The new YUI Uploader addresses these issues and others, allowing for the creation of more powerful, intuitive, and responsive file upload experiences. Allen Rabinovich of the ASTRA Library team did the legwork on this one, and it’s the same code that underlies the Flickr Uploader. Uploader is our second JavaScript/Flash hybrid control (following on the heels of the Charts Control in 2.4.0).
  
• Resize Utility: Layout Manager is built upon a new YUI utility, Resize. Dav’s Resize Utility formalizes the support that YUI Drag & Drop has long provided in example form and makes it easier for you to make any block-level element resizeable. Resizing can be implemented directly (the resized element resizes in real time during the interaction) or by proxy (a proxy element visualizes the interaction until its conclusion, at which time the resized element snaps to its new size).
• ImageCropper Control: The Resize Utility makes a lot of things easier — and one of those is the implementation of an ImageCropper interface, which Dav built out on top of Resize for 2.5.0. Take a look at the examples and be sure to check out the support Dav provided for modifier keys in this very desktop-like UI control.
• Cookie Utility: When he’s not busy writing books or working on My Yahoo!, Nicholas C. Zakas is cranking out new code for YUI. In 2.5.0, he contributes the Cookie Utility, a simple but powerful component that helps you get maximum mileage out of your limited cookie space. Because browsers limit the number of cookies you can set per domain (and because that limitation can sneak up on you if you manage a large site with many subdomains), the Cookie Utility supports ‘sub-cookies.’ Sub-cookies pack multiple name-value pairs under the umbrella of a single cookie, expanding the number of data points that you can store in cookie space.
• ProfilerViewer Control: 2.4.0 saw the release of Nicholas’s Profiler, a headless, cross-browser kit for profiling JavaScript functions. To make it easier to access and interpret the data that Profiler collects, we’ve added a ProfilerViewer Control in 2.5.0 that sits on top of Profiler and visulizes its accrued data. ProfilerViewer leverages the Charts Control and the DataTable Control. Taken together, Profiler and ProfilerViewer provide another arrow in the development quiver that includes tools like Firebug’s integrated profiling interface.

  

• Slider Control with Dual Thumb Support: Supporting dual-thumb interactions in our Slider Control has been on our list for awhile, and Luke took the opportunity to get this out to you in 2.5.0. Sliders are ‘finite range controls’; dual-thumb sliders allow you specify a sub-range within the control’s larger range. The classic use case for dual-thumb sliders is on shopping sites, where such controls can allow users to filter results based on price range. Check out the User’s Guide, example, and the new Slider Cheatsheet (which has a second page dedicated to dual-thumb implementations).
• We’re using this release to promote the following components from beta to GA status: ColorPicker Control, Get Utility (for cross-domain, dynamic loading of script and CSS files), JSON Utility, ImageLoader Utility, and YUI Test Utility. These promotions reflect the maturity of those components and their very low bug traffic. As always, we’re releasing all new-for-2.5.0 components under the beta moniker, and we’re looking forward to your feedback on those once you get a chance to try them out.
• Full details on the release, including a rollup of the changelog for all components and a bug/feature manifest, are available in Georgiann Puckett’s update to the YUI developer forum this morning.

One More Thing…

YUI now ships with more than 270 examples, many of which are accompanied by full tutorials to help you get started using YUI. And while individual examples are good, we’ve gotten a number of requests to create an über example, one that pulls in and makes use of a wide range of YUI components in a single sample application — while still being YUI-centric and not littered with noisy implementation logic.

The incomparably prolific Dav Glass rose to the challenge for 2.5.0 with a complex, multi-component example that uses Layout Manager as its basis and Yahoo Mail as its inspiration.

Let’s Celebrate!

We’re excited to get 2.5.0 out the door and, as luck would have it, we’ve got a fantastic excuse to celebrate. YUI’s (and the Yahoo Pattern Library’s) second anniversary party is coming up next week (February 26, 5 p.m., Sunnyvale), and we’d love to have you join us. Sign up on Upcoming to let us know you’ll be stopping by at Yahoo! HQ for some beer and general revelry. We look forward to showing off some of the stuff you all have been doing with YUI in the past two years and we’ll talk a bit about where Patterns and YUI are headed from here.

(Via Yahoo! User Interface Blog.)

We’re pleased to announce today the release of YUI version 2.3.0. This release features six new additions to the library as well as a new skinning architecture and a new visual treatment for most of our UI controls. All of this, plus 250 enhancements and bug fixes, is available for download immediately.

Here’s what’s new to YUI in version 2.3.0:

1. Rich Text Editor (beta): YUI developer Dav Glass brings you the new YUI RTE, featuring rich-text editing with robust A-Grade browser support. Cross-browser support has always been a major challenge for RTEs, and we think you’ll be impressed with how well this editor works across the various environments. You can instantiate it with just a few lines of code for simple implementations, and when you need to go beyond the ordinary it’s easy to extend the RTE’s Toolbar with your own custom buttons.
   
2. Base CSS: Nate Koechley continues to extend and refine the YUI CSS foundation, which now includes four members — Reset CSS neutralizes browser CSS treatments; the new Base CSS applies some consistent and common style treatments that many developers use as a foundation; Fonts CSS provides a foundation for typography; and Grids CSS delivers CSS-driven wireframes for thousands of potential page designs.
3. YUILoader Utility (beta): YUI’s most prolific author Adam Moore has contributed the new YUILoader Utility, a mechanism for loading YUI components (and/or your own custom components) on the page via client-side script. YUILoader knows all about YUI’s dependency tree and introduces into the page only those files that are needed to support your desired components. It can load files from Yahoo! servers or from your own hosted location.
4. ImageLoader Utility (experimental): Yahoo! Travel engineer Matt Mlinac authored the new YUI ImageLoader Utility, which allows you to defer the loading of some images to speed initial rendering time on your pages. If you suspect that you’re serving a lot of images that are never actually seen by your users, you’ll want to check out Matt’s work on this clever utility.
5. Color Picker Control (beta): Adam Moore built the new YUI Color Picker Control on top of his own Slider Control. The Color Picker provides a powerful UI widget for color selection, featuring HSV, RGB, and Hex input/output and a web-safe color-selection swatch.
6. YUI Test Utility (beta): Nicholas C. Zakas, who works on My Yahoo! when he’s not writing books or blogging on YUIBlog, authored our new YUI Test Utility. YUI Test introduces a flexible unit-testing framework for the YUI ecosystem and serves as the foundation for our own unit-test battery.

YUI Shows Some Skin

YUI components have always been receptive to implementation-specific styling, but with 2.3.0 we’ve moved to a more formal skinning approach that helps to separate core CSS definitions from purely presentational ones. YUI’s support for skinning makes it easier for you to implement your own design on top of, say, the TabView Control — and it makes it easier to share that skin with others in the community.

In concert with that effort, Yahoo! designer Sam Lind pitched in over the past several months to help us create an attractive, consistent visual treatment for the many UI controls in YUI that ship with a default look-and-feel. This baseline skin is much more stylish than what we’ve shipped in the past; many thanks to Sam for his hard work. In his honor, we’re calling this debut visual treatment the ‘Sam Skin’. Hopefully this will be just the first of many YUI skins that evolve within the developer community as time goes on.

More To Come

The YUI Team will have more to say over the coming weeks about what’s new in 2.3.0, including in-depth looks at the Rich Text Editor, the skinning approach, other new components, and Jenny Han’s significantly upgraded DataTable Control. In the meantime, George Puckett from the YUI team has posted a detailed release manifest to our forums and there are release notes accompanying every component (available on the website and as part of the download).

We’ve been working hard on YUI since the last release and we’re excited to share this work with everyone today. Please check out the new version and let us know what you think.

”

(Via Yahoo! User Interface Blog.)

About a year ago I made a Rich Text Editor (RTE) prototype to show that it was possible to build one on top of YUI. Of all my YUI examples, it quickly became one of the most requested, and the project indirectly resulted in me joining the YUI team in a formal capacity.

Once I started on the YUI team, building a full-featured YUI Rich Text Editor became my top priority. Even though there are many DHTML-based RTEs available in the open-source world, including Moxiecode’s excellent TinyMCE, there were four key reasons I took on the challenge of building a new one for YUI.

• A-Grade browser support – Most available RTEs fail to support the full spectrum of A-Grade web browsers. Most support IE and Firefox well, but few support Opera and I’m not aware of any that fully support Safari. For example, many existing RTEs don’t offer list editing in Safari. I thought we could do better. Because YUI is committed to A-Grade browser support (and because I’m a fanatic Mac user) fully supporting Safari was a top priority for me. Wrestling Safari into submission was no small task, and I’ll look at some of the specific challenges below.
• Extensibility – I wanted to build an editor that would allow fellow developers to add their own unique functionality. The YUI Rich Text Editor’s Toolbar is designed from the ground up to be extensible; the Flickr example is meant to illustrate this, as is the example of the Calendar Control implementation.
• Accessibility – What happens when users employing assistive technologies are presented with a rich-text-editing interface? What should happen? I spent time working with Yahoo! accessibility specialist Victor Tsaran to answer those questions. I believe that I have engineered some of the answers into the YUI Rich Text Editor. This is an area of ongoing development, and I’ll share more details as the RTE progresses out of Beta status.
• Footprint and Performance – I wanted to build an RTE that was small and fast. It’s already lighter-weight than some, but let’s be clear: It is not there yet. You can count on the fact that I’ll be putting a lot of effort into shrinking its footprint and improving its performance, while maintaining (and improving) consistency across the A-Grade browsers.

Current and Future Status

Before I get into the fundamentals of the YUI RTE, let me give you an update on the state of the project. First, this editor is currently a Beta control, and as such there is still much work to be done. Second, it’s neither a site editor nor a development environment. It’s designed for simple things like web mail systems, blog posts and comments, online reviews, and so forth. However, I did try to expose as many hooks and events as possible so that others could build upon the basic A-grade browser foundation that the RTE provides.

The Development Path

My development approach was to bend Safari first. I built it to work in Safari 2 before retrofitting it back to Opera, then Firefox and lastly Internet Explorer. I figured that if I could make Safari do what I wanted, the other three would fall into place nicely. And they did. By choosing to make Safari work first I was able to make the others do things in a standard way as well. I hope that Safari will eventually catch up to its A-grade peers and add support for the things that I have ‘emulated’, so I took that into consideration too.

Hacking Around Safari

Safari 2 is a really good browser, but it was also the most challenging browser to support with the RTE project. It lacks some serious and critical features when it comes to editing HTML content from JavaScript. I will try to explain the main hurdles that Safari presents:

Iframe Focus – One of the biggest issues was actually quite simple to solve. Safari (and Internet Explorer) has an issue with selecting text inside of an embedded iframe. If you select text within the editor’s iframe then click/focus the parent document, the selection within the iframe is lost. Clearly, this makes it rather difficult for a button click to take action on the selection (because the selection is lost when you click the button!). It also makes it difficult to use, say, a YUI Menu Control for a drop down. As I investigated this problem, I determined that if you stop the mousedown event on the button/href the selection doesn’t get lost. However, if something else (say a href in a dropdown menu) gets focus, the selection will still get lost. This leads me to the next Safari trick.

Selection Object – The selection object in Safari is very limited (to say the least). To work around its limitations, the YUI RTE caches a copy of the current selection in the _getSelection method. Then, the next time _getSelection is called I check to see if a cache existed. If the cache is there, I ‘rebuild’ the selection and destroy the cached copy. This little trick is what lets Safari use a YUI Overlay as a menu instead of the more classic approach of a select element. It’s roundabout, but it works.

execCommand limitations – This is the mother of all hacks for Safari (and the others). My biggest problem with the native execCommand method (in all browsers) is that the browser doesn’t tell you what it applied the command to. So there is no real way to get an element reference back after running a command on a selection. The world of JavaScript editors would be so much more civilized if this would happen (hint, hint, nudge, nudge). So what I had to do was implement this feature myself. My current approach may not be the best way to do it (I have some other ideas that I am working through), but it does the job for now. The method is named _createCurrentElement and basically it runs execCommand('fontname', false, 'yui-tmp'); on the given selection (since fontname is supported on all A-Grade browsers). It will then search the document for an element with the font-family/name set to yui-tmp and replace that with a span that has other information in it (attributes about the element that we wanted to create), then it will add the new span to the this.currentElement array, so we now have element references to the elements that were just modified. At this point we can use standard DOM manipulation to change them as we see fit. In short, I’m using the iframe’s DOM to store metadata during editing as a way to enrich the communication that’s possible between the editor and the iframe.

Making it Your Way

Over the past few years I’ve implemented many of the available RTEs. Because of this I brought a ‘taste of your own medicine’ mentality to the table. I wanted to build an editor that was easy to extend and change. The YUI RTE has Custom Events for everything that I could think of! I made all of the event handlers standalone functions that can be overloaded on the instance or on the prototype. I also tried to make as many things configurable as possible.

Just to give you an idea, let me show you a quick way to change one of the editor’s default behaviors.

The Create Link Dialog – Say you want to use a different input utility for link creation (a pre-defined links list maybe?) instead of the default link editor. Well, here’s some sample code to turn it into a JavaScript prompt:

var oEditor = new YAHOO.widget.Editor('demo');
oEditor._handleCreateLinkClick = function() {
    oEditor.on('afterExecCommand', function() {
        var str = prompt('URL: ', 'link');
        var el = this.currentElement[0].setAttribute('href', str);
    }, oEditor, this);
};

Using this technique, you could easily write your own property editor. By the way, the ‘insert image’ dialog can be overridden in exactly the same way (for example to make it a photo picker), just override the _handleInsertImageClick method. You could either override it as above, or you could override all editor instances (so every editor on the page would behave the same) like this:

YAHOO.widget.Editor.prototype._handleCreateLinkClick = function() {
};

The Look and Feel

If you don’t like the visual design of the RTE, simply change the CSS. As with YUI’s entire family of controls, the visual presentation of the control is written in CSS and can be reskinned to suit your implementation. See the RTE’s skinning example for more information on how CSS controls the presentation of the RTE specifically. We’ve even provided the Photoshop source file for the icons to make it easier for you to create a design that’s customized for your site. Maybe you like the colors, but you don’t want to see the labels above the ‘groups’? Well, add these few lines of CSS:

.yui-skin-sam .yui-toolbar-container .yui-toolbar-group h3 {
	display: none;
}
.yui-skin-sam .yui-toolbar-container .yui-toolbar-group {
	margin-top: .75em;
}

Once you dig in, I think you will find that the YUI RTE is pretty flexible and easy to extend.

In the End

Safari was tough, but I’m stubborn. When Safari properly supports execCommand, things will be even better. YUI’s RTE is exceptionally extensible and customizable; from very low-level functionality all the way up through the visual layer. It’s also semi-lightweight, and will be even lighter before I’m done with it.

I hope you enjoy my first YUI control. Please keep the feedback coming.

”

(Via Yahoo! User Interface Blog.)