4. The Top Requested Features

Among all the feature requests, 2D Drawing/Vector Graphics is clearly the most desired feature by the community. It received most votes (110 people voted for it), and highest total score (842, over 10% higher than the 2^nd feature request). The 2^nd top feature request is enhanced security for cross-site scripts. The third one is HTML DOM performance.

The following table shows the top 10 features:

Here are some general themes that emerge from the runtime initiative:

• Graphics – The top vote getter was 2D Drawing/Vector Graphics. Ajax developers today are achieving astoundingly rich graphics effects through clever techniques leveraging JavaScript, CSS, images, and whatever vector graphics features they can find (usually, SVG, VML and Canvas), but browser differences are a major pain point among Ajax developers. Mozilla, WebKit and Opera support both Canvas and SVG with good interoperability (although Mozilla does not yet support SVG animations). IE is the holdout. The call-to-action is for all browsers, particularly IE, to support both of the industry standards for 2D vector graphics, SVG (the DOM-based standard) and Canvas (the procedural-based standard).
  
  
• Security – Web security is an important topic for leading Ajax developers. The second top vote getter was Better Security for Cross-Site Scripts (XSS), but other security requests also receiving high votes, such as Strong Cross-Site Request Forgery Protection (which it turns out was the 11^th top voter-getter). The perception of the moderators is that it’s not just XSS, but that the community cares about all aspects of ensuring that the Web is secure, and in fact more secure than it is today. Recently, Mozilla has authored a proposal that might help make the Web more secure: http://people.mozilla.com/~bsterne/site-security-policy/. Note that Native JSON Parsing can be considered a security feature because without it Web developers are more inclined to use JavaScript eval() to process JSON data, which might allow for XSS attacks.
  
  
• Better low-level CSS and DOM support for layout – Two of the top vote-getters were Better APIs for positioning and styling  and Better UI Layout Support. These requests come from the widget developers within Ajax toolkit projects who design Ajax-based UI controls by taking advantage of what the browser gives them, such as DOM, CSS, images, and table layout. They often run into walls, and their jobs could be much easier (and performance much faster) if the browser included a small number of additional (relatively small) features, such as stretchable layout (e.g., flexbox in XUL) and the ability to determine the location and size of objects (and containers) within the page.
  
  
• Performance – The top vote-getter in the performance area was HTML DOM Performance in General. In discussions over the past year with leading Ajax developers, the moderators believe that the Ajax community wants performance improvements in all aspects of the browser runtime, including DOM, JavaScript, and rendering, but DOM performance was singled out by the community because Ajax toolkit developers have found that DOM access is the top performance barrier today. The key high-level message is keep making the browsers faster, but even blazingly fast JavaScript isn’t going to help if making DOM calls is too slow.
  
  
• Rich text editing – Various people in the Ajax community want to move desktop-like document editing into the browser. However, the contributors to this feature request did not outline a detailed strategy for how to accomplish this in future browser. The takeaway is that the Ajax community wants Better Support for Rich Text Editing , and hopefully one of the browser teams will push the envelope in this direction and send standards proposals so that the other browsers can also provide this functionality.
  
  
• Comet (server push) – Two of the top vote-getters were The Two HTTP Connection Limit Issue and Persistent Connections Issue. The underlying requirement is that many Ajax applications, such as dashboards, require an efficient and robust mechanism for having the server send data to the client on an event-driven basis. Today, server push in Ajax is often accomplished using “Comet” techniques such as long-lived HTTP connections, but the Ajax community would prefer if server push was a native browser feature.
  
  
• Video and Audio – Video and Audio also receiving strong support, coming in as the 10^th-most requested feature.

5. New Features (too late for voting)

Participants identified the following 6 new features, which were added to the wiki too late for the voting process, which means that we were not able to poll the community to determine relative importance versus other features:

• ECMA4 JavaScript2
• Field to input multiple files
• Allow JavaScript access to file upload statistics
• Allow user finer control over rich content than Javascript On/Off
• Memory Footprint
• Enforce Semantic Tagging of Data transmitted from browser

6. Next Steps

The next step is to communicate with browser vendors.  We have had calls with some of the browser vendors such as Microsoft IE team during Phase I.   OpenAjax Alliance will try to get in touch (or continue) the dialog with browser vendors to convey what the community is looking for.

7. Conclusion

Ajax is becoming at core for developing web applications. The stake associated with Ajax runtime environments is higher than ever.

The open community process works. Despite various challenges, the community demonstrated strong interest for a better ecosystem for Ajax going forward.

The list of feature requests makes a lot of sense from the web development community point of view. They range from security, performance, Comet, CSS, etc. Some of them do overlap with features that are being specified by other initiatives such as HTML 5 and SVG.   They will empower web developers to deliver much better applications over the web, and significantly enhance the power of the web.

Although we have identified the top 10 feature requests, the browser teams should study the entire list because all features might represent critical requirements or are just great ideas for advancing the Web. It is possible that some of the features that received fewer votes are critical to a particular but important niche or that only a subset of participants are close enough to the bleeding edge to see an impending but critical requirement.

It is worth pointing out that “vector graphics” is voted as the top request. It is time for all browser vendors to support standard vector graphics. Vector graphics support is highly scattered today. Open standards such as SVG and Canvas are supported by some browsers but not the others. The community is clearly demanding this feature, putting it even above security and performance.

8. Acknowledgements

The following is a partial list of people whose contributions made significant difference for this initiative.

Alex Russell (Dojo Foundation), Jack Slocum (Ext JS), Joe Walker (DWR), Douglas Crockford (Yahoo), Dylan Schiemann (Dojo and Sitepen), Bertrand Le Roy (Microsoft), Kris Zyp (Sitepen), Andrew Dupont (Prototype), Sam Lie (jQuery), Yehuda Katz (jQuery),  Krishna Sankar (Cisco), Brad Neuberg(Google), Greg Wilkins (Webtide).

OpenAjax Runtime Task Force members are:  Coach Wei (Chair, Nexaweb), Bertrand Le Roy (Microsoft), Jon Ferraiolo (IBM), Adam Peller (IBM), Haik Sahakian (Fidelity), Ted Goddard (IceSoft), Simone Fabiano (LightStreamer), and Krishna Sankar (Cisco).

Special thanks to Jon Ferraiolo (IBM) for coordinating and implementing the site infrastructure that made this initiative possible.

• OpenAjax Alliance Call-to-Action to AJAX Developers for Browser Wishlist
• White Paper: "OpenAjax Alliance on Mobile AJAX and Recent Browser Advances"
• OpenAjax Alliance: Browser Engine Access To Mobile Device APIs
• Introducing ZK 5: Future of RIA