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
- 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
- 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
Answers to Questions on Web Applications
- What functionality is needed for Web applications? What should
a hosting environment provide?
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
- 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
- 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
- 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
- Drag and drop APIs.
- Text selection manipulation APIs.
- Clipboard APIs (if the security and privacy concerns can be
- 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>,
- 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
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
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
- 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,
- 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
Answers to Questions on Compound Documents
The Mozilla Foundation
Opera Software, ASA
- 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
- 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
- no scoping is used, and the rules are matched against all
elements in the document,
- the rules in the scoped stylesheet are matched normally
against all elements in the scope, or
- 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?
- 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
- 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
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.)