Wiederholt hat die Open-Source-Hosting-Plattform SourceForge ein Redesign vorgenommen. Diesmal aber die komplette Website. Das alte, sehr dunkle und unübersichtliche wurde gegen ein frisches – aber auch beliebigeres – Design ersetzt. Insgesamt hat das ganze gewonnen, Kategorien, populäre Projekte und Detailseiten sind übersichtlicher einfacher zu erreichen.
YUI 3.0 Preview Release 1
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:
| Snippet: | What it does: |
YUI().use('node', function(Y) {
Y.get('#demo').addClass('enabled');
});
|
Creates a YUI instance with the node module (and any dependencies) and adds the class ‚enabled‘ to the element with the id of ‚demo‘. |
YUI().use('dd-drag', function(Y) {
var dd = new Y.DD.Drag({
node: '#demo'
});
});
|
Creates an instance of YUI with basic drag functionality (a subset of the dd module), and makes the element with the id of ‚demo‘ draggable. |
Y.all('.demo').addClass('enabled');
|
Adds the class ‚enabled‘ to the all elements with the className ‚demo‘. |
Y.all('.demo').set('title', 'Ready!').removeClass('disabled');
|
Sets the title attribute of all elements with the className ‚demo‘ and removes the class ‚disabled‘ from each. |
Y.get('#demo').plug(Y.Plugin.Drag, {
handles: 'h2'
});
|
Adds the Drag plugin to the element with the id ‚demo‘, and enables all of its h2 children drag as handles. |
Y.on('click', function(e) {
e.preventDefault();
e.target.query('em').set('innerHTML', 'clicked');
}, '#demo a');
|
Attaches a DOM event listener to all anchor elements that are children of the element with the id ‚demo‘. The event handler prevents the anchor from navigating and then sets a value for the innerHTML of the first em element of the clicked anchor. |
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-dragsubmodule, 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.)
Non-blocking JavaScript Downloads
Non-blocking JavaScript Downloads:
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:
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.
| Method | Drawback |
|---|---|
Using defer attribute of the script tag |
IE-only, unreliable even there |
Using document.write() to write a script tag |
|
XMLHttpRequest to get the source then execute with eval(). |
|
| XHR request to get the source, create a new script tag and set its content |
|
| Load script in an iframe |
|
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.)
YUI! Graded Browser Support Update
Graded Browser Support Update: „
This post announces an update to Graded Browser Support. The GBS page on the YUI site always has the most current information. This post includes a list of primary changes, the updated chart of browsers that receive A-grade support, the GBS forecast, and notes specific to the YUI Library.
Primary Changes
These changes are included in this update.
- A-grade support for Firefox 3 begins.
- A-grade support for Firefox 2 is reduced to Win XP and Mac 10.5.
- A-grade support for Opera 9.5 begins on Win XP and Mac 10.5.
- A-grade support for Win 98 is discontinued, as previously forecast.
| Win 2000 | Win XP | Win Vista | Mac 10.4 | Mac 10.5 | |
|---|---|---|---|---|---|
| Firefox 3. | A-grade | A-grade | A-grade | A-grade | A-grade |
| Firefox 2. | A-grade | A-grade | |||
| IE 7.0 | A-grade | A-grade | |||
| IE 6.0 | A-grade | A-grade | |||
| Opera 9.5 | A-grade | A-grade | |||
| Safari 3.0 | A-grade | A-grade |
The dagger symbol (as in ‘Firefox 3.’) indicates that the most-current non-beta version at that branch level receives support. Put another way, means ‘the most recent’ instead of ‘all.’
GBS Forecast
In addition to the effective-immediately changes, we’re keeping our eyes on pending developments.
-
Internet Explorer 8
GBS does not extend A-grade support to beta versions of browsers. (They receive X-grade support by definition.) However, it’s important to be aware of forthcoming releases, especially from established brands that enjoy rapid adoption once generally available (GA). We are currently watching the development progress of Internet Explorer 8.
We made an exception to our ‘no-betas’ stance during IE7’s beta phase in recognition of IE’s market share and ability to promote rapid adoption. The exception — committing development and QA resources to provide A-Grade prior to a GA release — gives us an opportunity to learn the new browser’s quirks and provide feedback while it is still being developed. And it means our sites are prepared when it goes GA. We will likely extend the same accommodation to IE8. Stay tuned.
Notes Specific to the YUI Library
-
YUI version 2.5.2
YUI 2.5.2, released May 28, 2008, includes full support for Firefox 3.0 and Opera 9.5, even though those two browsers were just added to GBS in this update.
(Via Yahoo! User Interface Blog.)
Implementation Focus: MiaCMS
Introduction: 
Chad Auld is one of the principal developers of MiaCMS. MiaCMS is a relatively new open source project, but it’s starting out with a solid base from its roots in Mambo CMS. Chad spent about three years on the Mambo team in various roles including Lead Core Developer and Director on the Mambo Foundation Board; he was a member of the Mambo Steering Committee prior to retiring in February of 2008. Recently, Chad joined with other core Mambo developers to create MiaCMS which is now on its second release. Chad’s role on the MiaCMS team for the first two releases has been to help with the rebranding efforts, build the default WYSIWYG editors, implement the YUI Library, build a REST API for content access, and develop enhanced charting for general CMS statistics and poll results.
How does MiaCMS differentiate itself from other CMS projects out there? Why would someone choose MiaCMS over Drupal or Joomla or other well-known apps in this space?
Yes, there are quite a few content management systems to compete with. Luckily we aren’t really new to the game. Our team contributed toward making Mambo the CMS it is today. We will continue building on that same award-winning base with MiaCMS. (As a side note, it’s worth pointing out that Joomla was also initially based on Mambo about three years ago.)
Some of our current features are:
- Simple Installation
- WYSIWYG Content Editors
- RSS Content Syndication
- Powerful/Extensible 3rd Party Extension System
- Flexible Site Theming Capabilities
- Site Search
- Sitemap Generation
- REST Enabled Content & Statistics
- User Management
- Multilingual Core
MiaCMS will differentiate itself by making standard content management operations even easier and more flexible than they have been in the past. We will cleanup much of the old legacy code and enhance the extensions interface to simplify custom 3rd party extension development. With the 4.7 release the team will drop support for PHP4 to take advantage of the object-oriented capabilities of PHP5. The team plans to continue building close ties to the community and listening to their feedback. The next few releases will focus on building out many of the wishlist items we have already received from the community.
At some point, you and the development team made the decision to build YUI into MiaCMS. What were the factors that guided your decision?
We based our decision on a number of important factors; maturity, browser support, documentation, support community, functionality, and flexibility. YUI has a large selection of time-tested components and continues to make valuable additions with each release. For us it is important that the selected framework continue maturing and growing right along side of us. We didn’t want to add yet another library to the system and so it was important to be able to replace existing parts of the CMS with canned components and/or have the flexibility to hook into the framework and use it as a building block for custom components. The YUI documentation is first-class. In fact, it represents some of the best documentation I’ve come across for an open source project. Between the user guides, cheatsheets, api browser, examples, and developer videos, you have just about everything you could ask for. Of course, sometimes documents just aren’t enough. Luckily, we’ve found the YUI support group to be a good place to find additional answers. Last but not least is the topic of browser support. While we’d love to support every browser in existence, it simply isn’t possible. But we do our best to test and code for as many as we can. We think Yahoo! has taken the right approach with its Graded Browser Support model.
What components of YUI are used in Mia?
We are currently utilizing the Reset–Fonts–Grids CSS, Dom Collection, Event Utility, Tabview Control, Button Control, Color Picker Control, Rich Text Editor, Animation Utility, Element Utility, Container Family, and Menu Control. Our production releases also make use of the YUI Compressor which we have integrated with our ANT packager to compress all the CSS and JavaScript in the system. The entire YUI library is included in the system so we are hoping our 3rd party developer community will make use of the library as well. Each custom component comes with its own set of unique requirements and we are confident that YUI can meet their needs, help improve their extensions, and reduce the number of 3rd party libraries the system must carry. In the last release we also build a dynamic loader into the system which allows MiaCMS users to decide between serving files from the local YUI library and serving them from the Yahoo hosting service for the advantages its CDN can bring.
Where do you see opportunities for deeper YUI integration with MiaCMS in the months ahead?
We’ve still got a lot more planned for YUI. Mia is carrying a fair amount of legacy JavaScript code in the system since its Mambo base was started about 7 years ago. We’ll be rewriting a good chunk of the JavaScript in Mia over the next few releases and utilizing YUI where possible. Users can expect a drastic reduction in inline JavaScript. We also plan to move away from older styles of event handling like coding individual onclick/onmouseover events and instead rely on the YUI Event Utility to subscribe to DOM events and help us create custom events with the application. Future releases will make heavy use of the YUI Dom Collection as well as the Event and Selector utilities.
In addition to the custom JavaScript found in the CMS there are also a number of external JavaScript libraries included to handle specific functions like tooltips, menus, calendaring, etc. A goal for the project will be to reduce the number of external dependencies and rely on YUI where possible. Two such replacements have already been almost fully implemented within the CMS core and we have started to encourage our 3rd party developers to make the switch as well with their custom extensions. In past releases the menu system relied on JSCookMenu and all tabs within the system relied on WebFX Tab Pane. JSCookMenu has now been fully replaced with the YUI Menu Control and the WebFX Tab Pane conversion to YUI TabView is about 98% complete. We are currently in the process of replacing overLib tooltips with the YUI Tooltip Control. We will also soon replace ‘The DHTML Calendar’ with the YUI Calendar Control. It would also be pretty safe to say you’ll eventually find ContextMenus, TreeView, DataSource, DataTable, Connection Manager, and JSON being used within MiaCMS. We recently selected Open Flash Charts, but as the YUI Charts Control matures and evolves out of an experimental state that may also find it’s way into Mia.
Having developed a complex application implementing YUI, what are your thoughts on the state of YUI as a toolkit? What’s working super well at this point? What weaknesses are you hoping the YUI team will address?
YUI is a feature-rich, well designed, state of the art toolkit. The available components cover a wide variety of the common tasks needed for web application development. We have had great success integrating YUI deeply into the MiaCMS core which we will continue to do with each passing release. The community feedback on the YUI-related changes has been very positive so far. Support for the major browsers is top-notch, the components degrade nicely, and performance is solid. Tools like the YUI Compressor and YSlow are also key in helping us take performance to the next level.
Nothing much to complain about. Overall we have been very happy with our selection of the YUI Library. One of the things I really like about jQuery is the powerful CSS style selectors. I am really looking forward to the YUI Selector Utility coming out of beta. We’ll probably start making heavy use of it even before then, but obviously the more stable it is the better. I also see a lot of potential for the experimental Charts component so I’d like to see it polished up with its functionality being continually expanded as well.
What are the next big frontiers for the MiaCMS project as a whole?
Below is the list of roadmap items in no particular order. Some are already being worked on, some are almost complete, and others are in the planning stages.
- Improved ACL’s (User/Group Permissions)
- Database Portability
- LDAP Support
- OpenID
- Dublin Core Metadata
- OAuth
- N-Level Content Organization (remove the two tier section/category limitation)
- Content Versioning
- Multilingual Content Management
- Writeable REST Interface
- Multi-Site Management
- Improved File & Image Management
(Via Yahoo! User Interface Blog.)
YUI 2.5.0 Released — Big upgrades to DataTable, new Layout Manager, Flickr-style multi-file Uploader, and more
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.)
OpenID 2.0 ist fertig
OpenID 2.0 ist fertig: „OpenID erlaubt es Nutzern, sich mit einer URL bei verschiedenen Websites zu authentifizieren statt jeweils einen eigenen Login-Namen und Passwort festzulegen. Dabei handelt es sich bei OpenID um einen offenen Standard, der dezentral umgesetzt wird, so dass z.B. auch das eigene Blog oder der vorhandene Account bei einem Internet-Provider zur Authentifizierung genutzt werden können. Die Version 2.0 der Spezifikation unterstützt unter anderem Directed Identity. Statt ihrer OpenID müssen Nutzer damit zur Authentifizierung auf einer Website nur noch ihren OpenID-Provider angeben, was die Nutzung vereinfachen und Sicherheit verbessern soll. (OpenID)“
(Via Golem.de.)
Online-Lexikon für Website-Elemente
Online-Lexikon für Website-Elemente: „Die Pattern-Library des holländischen Web-Designers Martijn van Welie eignet sich wunderbar zur Weiterbildung wie auch zur Mediation. Wenn also ein Auftraggeber behauptet, der Designer habe ihm statt eines Navigation Trees ein Accordion geliefert … die Patter-Library erklärt den Unterschied in Wort und Bild und verweist auf interaktive Quellen. Das Nachschlagwerk bietet die Kapitel: Navigation, Suche, Shopping, Personalisierung, Feedback, Seitenarten und vieles mehr. (Via Swissmiss)“
(Via Fontblog.)
YUI 2.3.0: Six New Components and a Prettier Face
YUI 2.3.0: Six New Components and a Prettier Face: „
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.)
Some Notes on the YUI Rich Text Editor
Some Notes on the YUI Rich Text Editor: „
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.)