Summary Report

Introduction

What does the Ajax community want from
future browsers? How are these different requests prioritized? Web developers
have done amazing things with Ajax for both Web 1.0 and Web 2.0 applications,
but what barriers need to be removed to enable the next generation of
browser-based innovations? The future of Ajax runtime environments matters more
than ever today.

In late 2007, OpenAjax Alliance formed
Runtime Task Force (http://www.openajax.org/member/wiki/Runtime)
to address this community concern. The goal is to collect, articulate, and
prioritize key issues from the Ajax community, and communicate them to browser
vendors. This will help educate the community in large, help browser vendors
better plan for their product roadmap, and help developers better use Ajax.

There are other great rich Web UI technology
initiatives such as W3C’s HTML5, CSS3 and SVG. The OpenAjax browser wish list
is not intended to compete with these initiatives, but instead complements them
by capturing and communicating the views of the web development community (the
folks who are “users” of Ajax techniques).

In Phase I,
OpenAjax Alliance collected an initial list of feature requests. This is
largely done by researching blogs, meetings with OpenAjax members and Ajax
experts, and interviewing leading Ajax toolkits.

The initial
wish list was announced in April 2008 for community review and feedback. A
group of industry experts were being actively approached for feedback (see <a
href="http://www.openajax.org/runtime/wiki/Phase_I_Voting"
title="Phase I Voting Phase I Voting wiki page]).

Phase II
started in May. The Alliance re-organized the feature lists based on Phase I
results. Phase II wish list was put into voting in June. Voting was open to
the general community. For each feature request, a voter can vote from 0 to 10
to indicate how strongly the voter feels the need for this request (10 being
the most important).

The voting
ended on July 13th 2008.

Feature List Summary

A total of
55 features were written up by various people in community. These writeups
typically cover areas such as what the feature is, background, why the feature
is important, possible solutions/recommended approaches for this feature,
references, etc.

As a result
of community feedback, some features are classified into “InActive”. For Phase
II voting, there is a list of 37 active features. The current feature request
list is:

Community Voting Results

By
July 13, when the voting closed, this initiative
has turned out to be a bigger success than
expected. Given the amount of effort
required to read and understand the vast
web technology landscape, and the
relatively limited time and resources
available to the OpenAjax Alliance Runtime
participants, we were hoping for 50 or so
people to vote, which would be meaningful
to establish a rough idea of what's most
important to the community.

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 second
feature request). The second
top feature request is enhanced
security for cross-site scripts. The
third and fourth were better APIs for scripting and styling and HTML DOM performance.

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 11th 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 10th-most requested feature.

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:

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.

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 worthy of 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.

Acknowledgement

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