Wednesday, August 1st, 2007

YUI 2.3 Released: Rich Text Editor, Components, and Themes

Category: JavaScript, Toolkit, Yahoo!

YUI 2.3 has been released with six new components, as well as a skinning architecture and a new look for the components.


  • Rich Text Editor: 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
  • Base CSS: Nate Koechley continues to extend and refine the YUI CSS foundation. Base CSS itself applies consistent and common style treatments for the foundation
  • YUILoader: A mechanism for loading YUI components (and/or your own custom components) on the page via client-side script.
  • ImageLoader: Allows you to defer the loading of some images to speed initial rendering time on your pages.
  • ColorPicker: 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.
  • 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.
  • Skins

Posted by Dion Almaer at 11:18 am

3.8 rating from 52 votes


Comments feed TrackBack URI

I still find somewhat ironic the relation between how YUI architecture is built and their encouragement of the YSlow tool… Even the most basic things in YUI require you to initiate various HTTP requests.

I’m still waiting for the day when a YUI update includes a builder like the one in Mootools where you integrate all your components in just one compact file (not only ending with less HTTP requests, but also letting gzip do its work better).

Comment by gonchuki — August 1, 2007

maybe they made YUI as a unit test for YSlow?

across yahoo properties, id rather have it cache the components im already using than download a custom pack for each app – well if i was paying their bandwidth bill..

Comment by cdr — August 1, 2007


YUI’s fresh 2.3.0 release includes a new utility called YUI Loader (beta). It has a range of functionality, but you’ll be happy to note that:

3. Automatic use of rolled-up files. YUILoader knows about all of the built-in rollup files that ship with YUI — like the yahoo-dom-event.js file that contains the Yahoo Global Object, the Dom Collection, and the Event Utility, three components that are commonly used together. (There are others, including a rollup of all the utilities. –ED) By automatically using rolled-up files when it makes sense to do so, the YUILoader helps you reduce HTTP requests and thereby keep your page as efficient as possible. (YSlow rule #1 –ED.)

And as a reminder for those that care about performance, Yahoo! hosts YUI for free on an optimized edge network. By using this free service your YSlow score will immediately rise because these servers comply with Yslow rules #2, #3, #4, #8, #10, and #13.

We’ll continue to strive for “faster,” including reducing HTTP requests even further, but the addition of YUI Loader to YUI’s free hosting is a step in the right direction.

And yes, YSlow rocks.


Comment by Nate Koechley — August 1, 2007

Oh boy. That text editor interface is not pretty.

1) Since when do toolbars have their own caption?
2) And why wait just a noticeable moment to enable or disable button when you select/deselect text? Is just enough to make it feel sluggish.
3) Also, why is the bold/italic etc buttons not disabled if you don’t have text selected? If you’re going to disable buttons based on your selection, be consistent.
4) Even worse, when you have an insertion point and click the bold button, you’ve lost your insertion point!
5) It seems that the button gets ‘focus’ when clicked, and if you then type a normal letter, what happens is that you ‘click’ the button. Wha?
6) What does the ‘hidden’ elements button do? Bonus points if you can explain.
7) Try inserting an image, I dare you. It would seem like a good idea to use a place holder, but if the actual image will be smaller (like an inline icon) the user is confronted with a seriously f-ed up layout before he/she can actually insert the image. That makes no sense.
8) Also, try to right align the image. What the …? That’s just showing off, see how the little balloontip moves right or left? Yes, very impressive, but that’s just over the top.

Conclusion based on 10 minutes of play? Please someone at YUI buy the book About Face and also try using some actual text editors to understand some of the idioms at play. This is a joke.

/end rant

Comment by Mike — August 1, 2007

9) Where’s Clippy!

Comment by Mike — August 1, 2007

It’s good when Gzipping makes your server, if server is not yours and you can’t ajust it, you can use jscsscomp (for php), it makes compound of necessary scripts automaticly. It makes Minify + GZip + combines it all in a one request + You can easly improve it with adding E-Type and Expires headers.
I dont want to discuss which framework is better…it’s matter of choise.
But I think YUI has the best documentation and the most understandable code, if I want to understand what some function exaclty does it is fast to understand just looking at it’s code and in 99% cases Dom+Event+Connect+DragDrop is enough for everything.

About RTE absolutely agree, disabling font-combobox on nothing selected is not the best design solution and not user-friendly :).
But color picker? isn’t it like normal windows color picker? RGB, HSB, i can tip my color and it will calculate a web color for it and show it on the color map! cool!

Thanks Yahoo for such a good, free and good documeted framework!

Comment by Monin D. — August 1, 2007

The ‘hidden elements’ button makes hidden elements visible by adding a dotted border. Just try adding an anchor to your text and then click ‘show hidden elements’ (or whatever it says): your anchor will be surround by a dotted, gray border so you can see that it’s not just ‘blue underlined’ text.

Will I get your promised bonus points? :)

Comment by Stephan — August 1, 2007


Thanks for the detailed feedback. While we do the best we can to listen for feedback from all corners of the web, we really prefer that its added to our sourceforge trackers so that it’s transparent and trackable. You can put it wherever on the Web you like, but if your goal is to contribute to the betterment of the library that’s the best process.

I’ve tried my best to address your issues in turn.

First off, can you share you environment — browser/version/os — as well as which specific example you’re looking at?

Now item-by-item:

1) Do you mean the tooltip? A quick poke around the software on my box shows that all editors do this, including Thunderbird, Word… If you meant the always-visible text, or “group labels,” that’s a configuration option:

2) We’ll be digging into the code in a forthcoming blog post on the YUI Blog. Turns out RTE’s are a bit tricky thanks to some, eh, *interesting* choices the various browser vendors made. It takse some heavy lifting to provide feature parity across all A-grade browsers. Many other RTEs don’t share that goal and hide certain features from certain browsers.

3) The interaction model, like all editors I’m aware of, is this: Place your cursor. Click bold. Type, and the text is bold. That it doesn’t work is a bug. (See #4, next.) This is logged and being tracked and fixed.

4) This is caused by the same bug. In fact it *is* the root bug — the reclamation of focus subsequent to pressing a button doesn’t happen accurately. In the above case (#3) this means that the manual refocus “clears” the previously requested “start bolding what I type” command.

5) Same bug. In this case, if you don’t manually refocus in the text the focus remains on the button as you described.

6) Bonus for me! If the rich text contains invisible HTML elements such as divs, ps, and spans, this button will show those elements by giving them a border (much like Firebug). Which receive this treatment is, of course, configurable:

(I see your point though. Perhaps we need a better icon.)

7) What makes sense to you?

Currently the placeholder resizes to actual size once the user chooses their asset. Whether this exists, what size it should be, and what file is used as the placeholder are all configurable:

8) Preliminary user research in the lab indicates that this assists users’ task focus and wayfinding. There’s more user research to be done though (as always), and I do suspect it various by task and context. That’s why we made it a configuration option:

I don’t quite understand your conclusion, but I do thank you for testing it out and sharing your rant. I hope you’re able to come back and offer the idioms you think are important, especially in #7.


Nate Koechley
YUI Team, Yahoo!

Comment by Nate Koechley — August 1, 2007

Dojo seems to be losing territory whenever these other JavaScript frameworks improve. For instance, see the YUILoader in the YUI library and how it might relate with Dojo’s dynamic loading of files. Also, if you make the same thing on the server, you might just be able to avoid loading JavaScript files dynamically which might speed things up slightly.

A couple of days ago I created my own “assets manager” to be used from the server so dependencies are managed automatically and files are loaded when they are necessary and in the right order. It was the first time I used a “topological-like” sorter, luckily Ruby has a library for that kind of thing which is included in the standard libraries:

I guess Dojo needs to grow up beyond its walled garden fast or else in the soon future it might lose any momentum it might had.

Comment by Joao — August 1, 2007

@Mike: Just playing Devil’s Advocate (any item not mentioned is agreed with):
1) Probably since thousands of dollars worth of user testing has perhaps shown that this is easier for users to understand. See: MS Office 2007.
3) Well technically, it should be that way because the bold/italic/etc buttons also determine the style of the text you are about to type, not just the text you currently have selected. This is expected behaviour and has been as long as I can remember. Having said that, I’ve just tested the editor, and click in those buttons takes the cursor out of the editing area and doesn’t actually set the style, so agreed, this needs to be fixed.
6) See Stephan’s post above.
8) I’m all for showing off, but when the animation runs at 2 frames-per-second, I agree – too far.
My conclusion. I think I’ll stick with TinyMCE.

Comment by Michael McCorry — August 1, 2007

I have to agree that the Editor is too buggy and waaay too sluggish for now. Losing focus on button press is a deal breaker (try adding a list -> list point appears, fiel looses focus, list is removed as it is empty).

I can’t click below the entered text to position the caret at the end of the text.

Select two lines and an empty third line and press the list button -> lines are converted to a list and then the list vanishes from the editor.

Well, it is beta software in the original sense of the word, therefore I refrain from final judgment. I hope Nate and gang can turn it into a good 1.0 product.

Comment by Martin — August 1, 2007

@Nate Koechley:
thanks for the pointer, seems i missed that one when reviewing the new version, I just thought it was simply a more refined version of Mootools assets.js but seems that not only is more refined, you are also starting to distribute more compact versions of your core components.

Comment by gonchuki — August 1, 2007

I think this RTE is a good start
I agree that some controls of it should be available when you don’t have text selected such as font, font color and so on.
The focus problem is a bit annoying, i think this should be the first bug to solve. The image insert popup is good enough in my point of view. You don’t need a very sophisticated popup to add picture to a text you are typing.

Now i want to congratulate YUI team for this first release of RTE wich is promising. People can say this is not good but then they can create their own RTE widget :p (devil mode off).

This is still in beta stage, this means there will be an undefined number of updates for it untill it’s okay, and even it’s not beta, YUI team will always try to solve bugs on final utilities/widgets, i’ve experienced it about a menu bug and they solved it :) (even gave me a nice workaround while the bug was being corrected).

Good job for this release YUI team, now waiting to fix the IE6 bug about the datatable header when scrolling and then sorting :))

Comment by jerome — August 2, 2007

@mike : clippy i use ctrl-c ctrl-v works fine :)

Comment by jerome — August 2, 2007

Instead of buttons like: bold, italic, underline … they should put one: setClass…

From my observations only one editor can handle it (not ideal.. but..) it is TinyMCE.

And for the contentEditable developers .. .please please please give me one command: setClass (I don’t realy need bold, italic etc.)

Comment by Boczek — August 2, 2007

another incredible bad designed RTE. just look at the screenshots (esp. the one with “image options”). and why should the user choose “font” and “font size”? well, I don´t wanna see the markup which is generated by that …

Comment by patrickk — August 2, 2007

I think the wysiwyg is nice looking and fresh. TinyMCE is not without bugs. I’d say that the YUI editor is about on par with most of the oss editor widgets and could become one of the best once it gets a little more use.

Good job Y! team.

One thing I like about the dojo editor (although I’ve never deployed it, so I’ve used it only a little) is that it is very minimalistic. If a site has a well defined style guide, users should only need minimal formatting options (bold, italic, link, lists, header/para/pre, image). Too many formatting options *guarantees* an ugly site. You know what I mean… give them 1,000 color options and someone will create a page that uses all 1000 colors. :-)

Comment by Matthew Nuzum — August 2, 2007

The Rich Text Editor was very slow to load, and then very unresponsive (FF2.0.0.6 Intel Mac). Pity, because I like the look of it, and like the in-place dialogues for things like image insertion.

I like what YUI can do, but seems incredibly bloated.

Comment by johno — August 2, 2007

Re: Nate

Thanks for the response. It was indeed a rant, I didn’t know it was a beta, I thought this was final! Most points still stand, and my view on the insertion of images is that it’s not wysiwyg, because it might not look like the placeholder at all. It might be discomforting.

As for the balloon thing: I would always try to stick with what I feel most users are familiar with. In this case I feel that animation while doing text editing serves no purpose but to distract. If you tested it, did you also ask users if they understood/followed what happened and if they were distracted from their main task by the animation?

Anyway, good luck with it!

Comment by Mike — August 2, 2007


Thanks, these things are always a work in progress (and yes, beta in this case) and we appreciate input from people like yourself.


Comment by Nate Koechley — August 2, 2007

@ Boczek

setclass button would be useless for end-users i think :)

About the font and font size i think it’s good, just brows some webby wher you can do that and you would understand why some people decide to do this (example :ebay where u can type an ad and style it good)

For the html markup generated, just look at it and you will know, and then you can share the experience with us :)))

Comment by jerome — August 3, 2007

Although I do agree that the YUI RTE is quite immature in its functionality , stability and response time, I’m still very glad to see the debut of the YUI RTE which I can easily embed it in my web application. I’m currently using FCKEditor with my own plugins. I love its functionality and stability but hate its weight, long loading time. It would be great if YUI RTE can achieve the following list:

1. VERY FAST response time (note: VERY FAST!!!)
2. short loading time
3. extendable with plugins
4. configurable with toolbars (with or without text in the image)
5. very stable (at least with core functionality)

I know I’m asking for a lot. 3 – 5 might be not be too difficult to achieve. But 1 and 2 would really make a RTE stand out high in comparison with others. I hope YUI people can take the challenge.

Comment by Stewart — August 14, 2007

Amazing yahoo YUI library. Sure, Rich Text Editor still have a lot of problems since it is beta. however, nothing can beat free stuff especially with the support from big corporation. So far, I am very happy with it. Plug into my rails app without any problems

Comment by Brad — September 3, 2007

I think overall this could be a nice editor. It’s a slight deviation from the norm, but not too much. However – the problems with caret focus, response time and load time really do need to be an urgent priority (probably in this order too). At the moment I’m still debating with my self whether to keep it in this app for a client of mine, or move to something like TinyMCE as it does’t seem to suffer from these or as badly.

I think with more work though, once those issues are fixed – I’d happily use it in future.

Comment by Suraj — September 3, 2007

Leave a comment

You must be logged in to post a comment.