Position Paper for the W3C Workshop on Web Applications and Compound Documents

This document represents the consensus opinion of the Mozilla Foundation and Opera Software in the context of standards for Web Applications and Compound Documents.

We consider Web Applications to be an important area that has not been adequately served by existing technologies.

There is a rising threat of single-vendor solutions addressing this problem before jointly-developed specifications. To compete with other players in this field, user agents with initial implementations of jointly-developed specifications should ideally be shipping before the end of the year 2004.

Work has been started by Mozilla and Opera on aspects of this work and one working draft is already underway and publicly available.

Design Principles for Web Application Technologies

The following seven principles represent what we believe to be the most critical requirements for this work.

Backwards compatibility, clear migration path

Web application technologies should be based on technologies authors are familiar with, including HTML, CSS, DOM, and JavaScript.

Basic Web application features should be implementable using behaviors, scripting, and style sheets in IE6 today so that authors have a clear migration path. Any solution that cannot be used with the current high-market-share user agent without the need for binary plug-ins is highly unlikely to be successful.

Well-defined error handling

Error handling in Web applications must be defined to a level of detail where User Agents do not have to invent their own error handling mechanisms or reverse engineer other User Agents'.

Users should not be exposed to authoring errors

Specifications must specify exact error recovery behaviour for each possible error scenario. Error handling should for the most part be defined in terms of graceful error recovery (as in CSS), rather than obvious and catastrophic failure (as in XML).

Practical use

Every feature that goes into the Web Applications specifications must be justified by a practical use case. The reverse is not necessarily true: every use case does not necessarily warrant a new feature.

Use cases should preferably be based on real sites where the authors previously used a poor solution to work around the limitation.

Scripting is here to stay

But should be avoided where more convenient declarative markup can be used.

Scripting should be device and presentation neutral unless scoped in a device-specific way (e.g. unless included in XBL).

Device-specific profiling should be avoided

Authors should be able to depend on the same features being implemented in desktop and mobile versions of the same UA.

Open process

The Web has benefited from being developed in an open environment. Web Applications will be core to the web, and its development should also take place in the open. Mailing lists, archives and draft specifications should continuously be visible to the public.

Answers to Questions on Web Applications

What functionality is needed for Web applications? What should a hosting environment provide?

More of the same. HTML, CSS, DOM, and JavaScript provide enough power that Web developers have managed to base entire businesses on them. What is required are extensions to these technologies to provide much-needed features such as:

• Native pop-up menus and context menus.
• Inline markup for pop-up windows, for example for dialog boxes or tool palettes, so that dialogs need not be defined in separate files.
• Command updating: applications that have several access points for the same feature, for instance a menu item and a tool-bar button, would benefit from having to disable such commands only once, instead of having to keep each access point synchronized with the feature's availability at all times. Similarly menu items or tool-bar buttons that represent a toggle state could automatically stay synchronized whenever toggled.
• Server-sent events: triggering DOM3 Events from the server-side, for example for tickers or status updates.
• Client-server communications methods that do not require page loads, enabling on-demand data retrieval (where the UA automatically fetches data from the server as required), remote procedure calls (where script can invoke code on the server side and get an XML fragment in return), etc.
• More device-independent DOM events: The DOM event set needs device-independent events, such as events that fire when a button or link is activated, whether via the mouse or the keyboard. DOMActivate is a start, but it lacks equivalent HTML attributes, and additional events may be needed.
• Richer widget set: the existing HTML controls are quite limited, some controls for commonly used types such as date controls and range controls would be useful.
• Sortable and multicolumn tree views and list views with rich formatting.
• Ability to define custom widgets cleanly, for example using XBL and APIs to query and control focus state, widget state, the position and state of input devices, etc.
• Rich text editing: an underlying architecture upon which domain-specific editors can be created.
• A predefined HTML editor based on the rich text editing architecture.
• Drag and drop APIs.
• Text selection manipulation APIs.
• Clipboard APIs (if the security and privacy concerns can be addressed).
• Flexible box model: The existing box model in CSS is designed largely for documents rather than user interface. We need a new box model designed for user interface which would relieve author complaints about other aspects of CSS and also reduce the need for tables for layout.

Some less important features would be good to have as well:

• Window-based state management (so that new windows don't interfere with existing sessions), for example implemented as a per-domain, per-window "file system". This would allow multiple instances of the same application (from the same site) to run without the instances overwriting each other's cookies.
• Elements for semantics commonly found in applications, such as <byline>, <footer>, <section>, <navigation>, etc.
• Markup to denote mutually exclusive sections (as in the commonly seen wizard interfaces).
• An improved CSS object model, for example with better APIs for animation, simpler ways to navigate the rendered content, a way to find the position of an element, methods to list the elements under a coordinate, etc.

Several of the features in these two lists have been supported in non-standard ways by some user agents for some time.

How much of a Web application should be declarative? How much in script?

The initial state should be declarative. Very common relationships between elements should be declarative. The majority of the "application" side should be scripted.

How are they related to Web documents, which are normally static?

Web documents are not normally static anymore, and nor are Web applications really distinct from Web documents. The two are merely opposite ends of a wide spectrum.

Is there a need for a standard set of user interface controls?

Yes. HTML4 has the start of such a set.

Should these controls use the native platform look and feel?

That would be optimal. However, authors often request the ability to style form controls.

How should a Web application and its related resources (e.g. images, sounds) be packaged?

In the same way as documents. At a minimum, it must be possible to deploy applications over HTTP with no additional packaging.

What security issues need to be addressed?

The same issues as those faced by existing scripting environments in Web browsers.

To what extent can application behavior be usefully abstracted from platform specific details of UI controls?

All platform-specific details should be confined to stylesheets.

How can the application integrate different modality interfaces (e.g. voice, pen, keystrokes)?

Via XBL that has been bound from a device-specific stylesheet, and via device-independent form controls (for example, <input type="file" accept="application/inkml+xml">).

How to address richer models of interaction management that go beyond simple event handlers?

On a case-by-case basis.

Design Principles for Compound Document Technologies

There are two design principles that we think are critical for the successful deployment of compound documents:

Don't overuse namespaces

Extensive use of XML namespaces throughout a document can make markup difficult to understand. The core features of an XML vocabulary should require the use of elements from only one namespace. If elements in one standard are required as a core feature in another, the semantics of the first should be applied to element names in the namespace of the second. Namespaces on attributes should be used extremely rarely, and only for features that make sense across elements, independent of vocabulary, but are not required for any vocabulary (e.g., a namespaced attribute like HTML's style attribute).

Migration path

It is very important that authors be able to move from an HTML environment to a clean compound document environment (typically first simply by moving to XHTML) in a gradual fashion. For example, it must be possible for stylesheets and scripts used with namespaced compound documents to work unchanged with legacy HTML content.

Answers to Questions on Compound Documents

Should there be a set of predefined compound document profiles (e.g. XHTML Basic + SMIL Basic + SVG Tiny)?

No. Such documents are rarely useful as UAs do not generally limit themselves to particular profiles. If a specification is so large that it requires profiling and/or cannot be implemented on small devices, then it is a failing of the specification that should be solved by editing the complete spec, possibly simplifying or obsoleting some parts.

What features are needed from authoring tools designed to generate mixed content?

Compliance. Too many authoring tools currently generate non-compliant markup.

What happens with event processing and style cascading across the boundaries of mixed content?

Event flow needs no special considerations, since events should just flow normally.

There has been demand expressed for stylesheets scoped to a subtree or to elements in a given namespace by a number of working groups or other parties. Stylesheet scoping could be extremely useful for authors of compound documents.

However, different scoping mechanisms have been described. We believe the best way to progress is for the CSS working group to write a document formally describing stylesheet scoping. Specifications describing stylesheet linking mechanisms could refer to this document. The different scoping mechanisms are as follows:

1. no scoping is used, and the rules are matched against all elements in the document,
2. the rules in the scoped stylesheet are matched normally against all elements in the scope, or
3. the rules in the scoped stylesheet are matched according to the rule that each sequence of simple selectors (in CSS3 terminology) must match an element in the scope.

The scope could be defined by either namespaces or subtrees. (When the scope is defined by namespaces, method 2 may be undesirable, but it is in some cases more desirable when the scope is defined by subtrees.)

Under no circumstances, however, should stylesheet scoping affect the rules of inheritance. It should only affect which rules match which elements.

What MIME type should a compound document use?

Assuming it is a compound XML document, application/xml or the RFC3023-compliant MIME type of its root element.

What is needed from schema languages?

Nothing.

How can application semantics from different markup languages be mixed in an interoperable way (e.g. using XBL)?

By having specifications fully define how to handle foreign elements.

Is there a need for a generic extension architecture? What is needed to allow extensions, such as plug-ins, to handle content that is not supported directly by the browser/host environment?

XBL can serve as a generic extension architecture for many needs.

Binary plug-ins, by their nature, lack interoperability since they only work on a limited set of devices. (For example, a Win32 plug-in wouldn't work on a Symbian device.)