Web Applications Markup Language 1.0

Abstract

...

This document currently has no official standing within the W3C at all. It is the result of loose collaboration between interested parties over dinner, in various mailing lists, on IRC, and in private e-mail. To become involved in the development of this document, please send comments to the address given above. Your input will be taken into consideration.

This is a working draft and may therefore be updated, replaced or rendered obsolete by other documents at any time. It is inappropriate to use Working Drafts as reference material or to cite them as other than "work in progress".

This draft may contain namespaces that use the data: URI scheme. These are temporary and will be changed before this specification is ready to be implemented.

To find the latest version of this working draft, please follow the "Latest version" link above.

Table of contents

Introduction

The World Wide Web's markup language has always been HTML. HTML is a language designed primarily for semantically describing scientific documents, although its general design and adaptations over the years has enabled it to be used to describe a number of other types of documents. XHTML2 [XHTML2] updates HTML with better features for hyperlinks, multimedia content, annotating document edits, and introduces elements for better describing the semantics of human literary works such as poems.

Unfortunately, it lacks elements to express the semantics of many of the non-document types of content most often seen on the Web. For instance, the very popular forum sites, auction sites, search engines, online shops, and the like, do not fit the document metaphor well.

This specification aims to extend HTML so that it is more suitable in these contexts.

Requirements and ideas

• Tree controls
• User authentication state handling
• Window-based state management (so that new windows don't interfere)
• <byline> <footer>: <section>
• Equivalent of <switch>, so that e.g. selecting radio buttons changes the view
• Advanced textarea functions, Like storing caret position
• A per-domain, per-window "file system". This would allow you to be running multiple instances of the same application (from the same site) without the instances writing over each other's cookies. Anyone who has tried to compare prices of multiple Travelocity tickets knows what I mean by that. (I once nearly bought the wrong plane ticket because of this, so I feel quite strongly that there is a problem to solve here!)
• Native popup menus and context menus. As fun as it is to have to guess how the menus on every site work, I'm thinking it's about time we got consistent UI on this feature.
• For people who want it, command updating. This is where you have several access points for the same feature, for instance a menu item and a toolbar button, and you want them to all share the same "disabled" state, so you don't have to disable every one in turn when the option becomes unavailable.
• Sortable tree views and list views with rich formatting. Do a search on eBay, and you'll find you have to hit the server whenever you want to change the sort order. That shouldn't be necessary.
• Exclusive sections: At the moment, an implicit semantic of HTML documents is that all the content is always visible, you need but scroll to it. But in some applications this makes no sense: you may not want the login screen to be on the screen at the same time as the query page, for instance. At the moment you can work around this using CSS and display:none, but that's not semantically correct, and it breaks when you disable stylesheets, which it shouldn't. Having markup that actually means "hide this until it is activated" would solve this.
• Content-area popup windows. They're currently possible using positioned divs, but that breaks down when the stylesheet is disabled, and is semantically dubious at best. (Any time a div is the answer, there's a hole in HTML.) The idea would be to introduce the idea of a native "subwindow" element which would work as a movable window within the content area, which can be dragged, resized, etc, as required.
• Remote eventing. I was recently reminded that HTTP is a client-pull protocol, but that in many cases there is a need for server-push. Now, you can fake this using an iframe to a document that the server doesn't close and into which it keeps dripping script blocks, but that's a hack to say the least. What would be nice is a way of letting a remote server trigger DOM events that standard DOM3 Event technologies could hook into.

Should the basic unit of a web application be something other than a document? XAML, for instance, lets you use a manifest as the base file (as I understand it).

Annotations? (Probably not: it failed with HTML1, why should it work now?)

Relationship to HTML 4.01 and XHTML 1.1

This specification adds a number of features to HTML. For XML-based documents, these are added to the XHTML 1.x namespace. This ensures backwards compatibility with, and a simple migration path from, existing HTML and XHTML content.

Relationship to XHTML2

XHTML2 and this specification address the needs of two different authoring scenarios, and are expected to be used side by side. XHTML2 is optimised for documents — for example help files, essays, articles — whereas this specification is optimised for applications.

Relationship to Web Forms 2.0

This specification is designed to complement Web Forms 2.0. [WF2] Where Web Forms concentrates on input controls, data validation, and form submission, this specification concentrates on client-side user interface features needed to create modern applications.

Relationship to CSS3 UI

The CSS3 UI specification [CSS3UI] introduces a number of properties suitable for Web-based application development. This specification expands on those properties and specifies their interaction with scripting-based environments and the DOM.

Conformance requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Diagrams, examples, and notes are non-normative. All other content in this specification is intended to be normative.

Documents that use the new features described in this specification using HTML over HTTP must be served as text/html. Documents that use the new features described in this specification using XHTML or other XML languages over HTTP must be served using an XML MIME type such as application/xml or application/xhtml+xml. [RFC3023]

(In other words, for the purposes of [RFC2854], documents conforming to this specification using its HTML formulation should be considered HTML documents, but documents using the XML formulation should not be considered HTML-compatible.)

Terminology

...

...

...

The 'appearance' property

CSS3 UI [CSS3UI]

The exact appearance used will vary based on other properties and out of band data. In particular, the metadata and dynamic states described in the section on the ElementUI DOM interface directly affect how widgets are rendered. For example, a checkbox will look different based on whether the STATE_GROUP_CHECKED state is set to STATE_CHECKED_UNCHECKED, STATE_CHECKED_CHECKED, or STATE_CHECKED_INDETERMINATE. Progress bars, scroll bars and sliders (track bars) use the STATE_GROUP_VALUE metadata state to determine their position. The value 0 represents the lowest progress/scroll position/slider position, and the value 2¹⁶-1 (65535) represents the highest progress/scroll position/slider position.

Pseudo-classes

The following dynamic pseudo-classes are defined in terms of state information that can be manipulated through the DOM.

:active

This pseudo-class matches the element that has its DYNAMIC_ACTIVE state set, if any.

:hover

This pseudo-class matches the element that has its DYNAMIC_HOVER state set, if any, as well as any ancestors of that element.

:focus

This pseudo-class matches the element which has focus, if any, as well as all its ancestors. See the focus() and focusByMethod() methods.

:open

This element matches all elements which have their DYNAMIC_OPEN state set.

:closed

This element matches all elements which have their DYNAMIC_OPEN state unset.

:enabled

This pseudo-class matches all elements that their STATE_GROUP_ENABLED state set to STATE_ENABLED_ENABLED, and whose ancestors (including those that are not focusable) all have their STATE_GROUP_ENABLED state set to STATE_ENABLED_ENABLED.

:disabled

This pseudo-class matches all elements that have either their STATE_GROUP_ENABLED state set to STATE_ENABLED_DISABLED or which have an ancestor whose STATE_GROUP_ENABLED state set to STATE_ENABLED_DISABLED (including ancestors that cannot be focused).

:checked

This element matches all elements which have their STATE_GROUP_CHECKED state set to STATE_CHECKED_CHECKED.

:unchecked

This element matches all elements which have their STATE_GROUP_CHECKED state set to STATE_CHECKED_UNCHECKED.

:indeterminate

This element matches all elements which have their STATE_GROUP_CHECKED state set to STATE_CHECKED_INDETERMINATE.

:selected

This element matches all elements which have their STATE_GROUP_SELECTED state set to STATE_CHECKED_SELECTED. This pseudo-class is unrelated to the similarly named ::selection pseudo-element, which applies to the text selection.

:unselected

This element matches all elements which have their STATE_GROUP_SELECTED state set to STATE_CHECKED_UNSELECTED.

:default

This pseudo-class matches elements that have their STATE_GROUP_DEFAULT state set to STATE_DEFAULT_DEFAULT.

:valid

This element matches all elements which have their STATE_GROUP_VALID state set to STATE_VALID_VALID.

:invalid

This element matches all elements which have their STATE_GROUP_VALID state set to STATE_VALID_INVALID.

:required

This element matches all elements which have their STATE_GROUP_REQUIRED state set to STATE_REQUIRED_REQUIRED.

:optional

This element matches all elements which have their STATE_GROUP_REQUIRED state set to STATE_REQUIRED_OPTONAL.

:read-only

This element matches all elements which have their STATE_GROUP_DATA state set to exactly STATE_DATA_READABLE. Note that this is independent of the actual editable state of the control as presented to the user. The actual state of the control is governed by the computed value of the 'user-modify' property on a per-view basis, while the :read-only pseudo-class relates to the intended state of the control as set by the data model or other script.

:read-write

This element matches all elements which have their STATE_GROUP_DATA state set to exactly STATE_DATA_EDITABLE. Note that this is independent of the actual editable state of the control as presented to the user. The actual state of the control is governed by the computed value of the 'user-modify' property on a per-view basis, while the :read-write pseudo-class relates to the intended state of the control as set by the data model or other script.

:write-only

This element matches all elements which have their STATE_GROUP_DATA state set to exactly STATE_DATA_WRITABLE. Note that this is independent of the actual editable state of the control as presented to the user. The actual state of the control is governed by the computed value of the 'user-modify' property on a per-view basis, while the :write-only pseudo-class relates to the intended state of the control as set by the data model or other script.

See the ElementUI section for details explaining how to toggle these pseudo-classes.

When the UI module is in CR, this draft will need to be updated to take into account the other pseudo-classes from that module.

Focus

In UAs that implement this module, the 'nav-index' property doesn't do anything directly. It is used by methods on the DocumentUI interface to determine the order used for sequential focus changing (what is commonly referred to as "tab order").

The value none means that the element is not part of the normal tab order, regardless of the value of 'user-can-focus'.

The value 'auto' means that the UA may decide where in the tab order the element goes.

The directional navigational properties ('nav-up' and so forth) similarly work in terms of the directional focus methods.

Key handling

The 'key-equivalent' property doesn't do anything directly. It is used by in XBL as a filter for key events. The idea is that if the window receives a key event that matches an element's key-equivalent, that element will be sent a separate event.

A further draft will explain this in more detail.

Properties for selection, focus, and editing

Unlike the UI module properties, which apply to non-scriptable environments as well as dynamic, scriptable UAs, these properties control features that are directly related to the DOM.

Text Selection

A property to decide if the UA should allow inline selection. Note that this is a distinct concept from element selection -- an element can be flagged as selected independently of its contents being selected.

never

The contents of the element cannot be selected.

always

The contents of the element can be selected using the default UA-defined mechanism.

only-with-modifier

The contents of the element may only be selected using an alternate UA-defined selection mechanism.

For example, if by default a UA uses mouse dragging as a selection mechanism, then with 'user-can-select' is set to 'only-with-modifier' the same UA could change to mouse dragging with the shift key held down. The name 'only-with-modifier' is not meant to restrict the alternate mechanism, only to indicate that the UA should not enable the default selection mechanism.

When an elements' contents are selected (in part, in whole, or as part of a greater selection), that element contains a ::selection pseudo-element which applies to that selection.

User agents may treat the never value as only-with-modifier in untrusted documents, which typically would cover any document on the web, although the exact definition of 'trusted' is UA-defined and may be dependent on user preferences.

Focus

These properties decide if the UA should allow an element to gain focus.

takes-focus

If an attempt is made to focus the element, the active focus is moved to the element.

leaves-focus

If an attempt is made to focus the element, and none of the element's ancestors have their 'user-can-focus' property set to 'takes-focus', then nothing changes, otherwise focus is transferred to the nearest ancestor element with 'takes-focus' set.

resets-focus

If an attempt is made to focus the element, and none of the element's ancestors have their 'user-can-focus' property set to 'takes-focus', then focus is reset to the window, otherwise focus is transferred to the nearest ancestor element with 'takes-focus' set.

In this definition, the window is a user-agent-defined construct, typically related to the viewport. When the window has focus, the user is typically able to scroll the document using arrow keys on a keyboard.

Note that this property has no direct effect on the :focus pseudo-class. This property merely determines whether an element can gain focus in a particular view, not whether it can retain focus.

These properties explain what part of the contents of the element should be selected when focussing the element.

all

If the element is focused, all its contents should be selected.

reset

If the element is focused, then the selection is reset.

ignore

Nothing happens to the selection is the element is focused.

The property 'user-focus-select-key' applies when the focus change was requested via a keyboard event, the property 'user-focus-select-pointer' applies when the focus change was requested via a pointer event, and the property 'user-focus-select-unknown' applies in other cases. The property 'user-focus-select' can be used as a shorthand for setting the other two properties.

Editing

This property establishes whether the UA should allow editing of the node and its children.

read-only

The element should not be editable by the user (unless overriden by the UA, e.g. if the user invokes an "edit" mode on the document).

all

Any child node may be edited and the element itself may be deleted. This is equivalent to specifying all the other flags together.

children

Equivalent to add-text edit-text add-elements move-elements

add-text

New text nodes may be added to the element and edited.

edit-text

Any existing child text and CDATA nodes of the element may be edited.

add-elements

Child elements may be inserted.

move-elements

Child elements may be moved.

attributes

The attributes of the element may be added, changed, and removed.

deletable

The element itself may be deleted.

This property is inherited, but only applies to editing the element itself and its immediate children. The following makes an element foo and its children all completely editable:

foo, foo * { user-modify: all; }

That would also allow the element itself to be deleted, however. In order to disallow that, the following rules would be used:

foo { user-modify: children; }
foo * { user-modify: all; }

The exact mechanisms used to enable editing is up to the UA.

Changes to text-transform

The 'text-transform' property is modified to allow a string value to be used. When a string value is specified, all characters in the string are replaced with this string. For example:

input[type=password] { text-transform: '*'; }

This would replace each character in an input field with an asterisk, as seen in many existing web browsers.

Changes to position

The value popup is added to the 'position' property. When this value is applied to an element, the following changes apply:

1. The element is taken out of flow and not shown (same as display:none).
2. If the element's 'overflow' property has a specified value of visible then the computed value becomes hidden. Other values stay unaffected.

The ElementUI interface can then be used to actually trigger the popup.

DOM Interfaces

The DocumentUI Interface

The DocumentUI interface contains methods for moving focus around the document.

IDL Definition

interface DocumentUI {
  void moveFocusForward()
  void moveFocusBackward()
  void moveFocusUp()
  void moveFocusRight()
  void moveFocusDown()
  void moveFocusLeft()
};

Properties

Future drafts of this specification will provide properties for the current default element and the current focused element.

Methods

moveFocusForward

This uses 'nav-index' and 'user-can-focus' properties to find the next focussable element and focusses it.

moveFocusBackward

This uses 'nav-index' and 'user-can-focus' properties to find the previous focussable element and focusses it.

moveFocusUp

This uses 'nav-up' and 'user-can-focus' properties to find the next focussable element and focusses it.

moveFocusLeft

This uses 'nav-left' and 'user-can-focus' properties to find the next focussable element and focusses it.

moveFocusDown

This uses 'nav-down' and 'user-can-focus' properties to find the next focussable element and focusses it.

moveFocusRight

This uses 'nav-right' and 'user-can-focus' properties to find the next focussable element and focusses it.

The ElementUI Interface

The ElementUI interface contains methods for displaying popups and toggling the state of dynamic pseudo-classes.

IDL Definition

interface ElementUI {

  /* POPUPS */
  const unsigned short      BEFORE_START                   = 0;
  const unsigned short      BEFORE_END                     = 1;
  const unsigned short      AFTER_START                    = 2;
  const unsigned short      AFTER_END                      = 3;
  const unsigned short      START_BEFORE                   = 4;
  const unsigned short      START_AFTER                    = 5;
  const unsigned short      END_BEFORE                     = 6;
  const unsigned short      END_AFTER                      = 7;
  const unsigned short      OVERLAP                        = 8;
  const unsigned short      AFTER_POINTER                  = 9;

  void showPopup(in unsigned short alignment,
                 in Element target, in Element anchor);

  void hidePopup();



  /* METADATA STATE */  
  /* Metadata states are the same in all views */
  const unsigned short      STATE_GROUP_ENABLED            = 0; // allowed values are STATE_ENABLED_*
  const unsigned short      STATE_GROUP_DEFAULT            = 1; // allowed values are STATE_DEFAULT_*
  const unsigned short      STATE_GROUP_CHECKED            = 2; // allowed values are STATE_CHECKED_*
  const unsigned short      STATE_GROUP_SELECTED           = 3; // allowed values are STATE_SELECTED_*
  const unsigned short      STATE_GROUP_VALID              = 4; // allowed values are STATE_VALID_*
  const unsigned short      STATE_GROUP_REQUIRED           = 5; // allowed values are STATE_REQUIRED_*
  const unsigned short      STATE_GROUP_DATA               = 6; // allowed values are STATE_DATA_*
  const unsigned short      STATE_GROUP_VALUE              = 10; // allowed values are any integer
  
  const unsigned short      STATE_ENABLED_DISABLED         = 0; // false
  const unsigned short      STATE_ENABLED_ENABLED          = 1; // true
  
  const unsigned short      STATE_DEFAULT_NORMAL           = 0; // false
  const unsigned short      STATE_DEFAULT_DEFAULT          = 1; // true

  const unsigned short      STATE_CHECKED_UNCHECKED        = 0; // false
  const unsigned short      STATE_CHECKED_CHECKED          = 1; // true
  const unsigned short      STATE_CHECKED_INDETERMINATE    = 2;

  const unsigned short      STATE_SELECTED_UNSELECTED      = 0; // false
  const unsigned short      STATE_SELECTED_SELECTED        = 1; // true

  const unsigned short      STATE_VALID_INVALID            = 0; // false
  const unsigned short      STATE_VALID_VALID              = 1; // true

  const unsigned short      STATE_REQUIRED_OPTIONAL        = 0; // false
  const unsigned short      STATE_REQUIRED_REQUIRED        = 1; // true

  const unsigned short      STATE_DATA_INACCESSIBLE        = 0; // none
  const unsigned short      STATE_DATA_READABLE            = 1; // 0x01
  const unsigned short      STATE_DATA_WRITABLE            = 2; // 0x02
  const unsigned short      STATE_DATA_EDITABLE            = 3; // 0x01 || 0x02

  void setMetadataState(in unsigned short state, in long value);
  long getMetadataState(in unsigned short state);


  /* DYNAMIC STATE */
  /* Dynamic states are defined on a per-view basis */
  const unsigned short      DYNAMIC_ACTIVE                 = 0;
  const unsigned short      DYNAMIC_HOVER                  = 1;
  const unsigned short      DYNAMIC_OPEN                   = 2;

  void setDynamicState(in unsighed short state, in bool value);
  bool getDynamicState(in unsigned short state);


  /* FOCUS */
  const unsigned short      FOCUSED_BY_UNKNOWN            = 0;
  const unsigned short      FOCUSED_BY_KEYBOARD           = 1;
  const unsigned short      FOCUSED_BY_POINTER            = 2;

  void focus();

  void focusByMethod(in unsigned short method);
};

Methods

showPopup

Shows the element as a popup. If the element doesn't have the 'position' property set to popup, this will raise a NOT_A_POPUP_ERR. Calling this method will cause the following events: First, a popupShowing event is triggered (it is cancellable, cancelling that event will prevent the popup from showing), second, the popup is aligned (potentially triggering a popupPositioning event), and finally a popupShown event is triggered.

Parameters

alignment of type unsigned short

One of the alignment constants. See the descriptions below.

target of type Element

The element that the popup will be positioned relative to (it may itself be part of a popup, for example this is the case for cascading menus). If the target is null, then the point representing the (last known) position of the pointing device is used instead. If the target element is not visible, or if there is it is null but there is no pointing device, then the viewport is used instead. If the viewport is not visible, then the whole screen is used. This ensures that the popup will appear, regardless of how it was triggered.

anchor of type Element

The element to position relative to the target. This must be either the popup itself, or one of the popup's descendants (excluding anonymous nodes that are not in the default view). If null is used, then that implies the element. If the anchor has no defined position (which can happen if is hidden using CSS for example) then its closest ancestor which will have a position when the popup is shown is used instead.

No Return Value

Exceptions

UIException NOT_A_POPUP_ERR

Raised if the element doesn't have the 'position' property set to popup.

UIException HIERARCHY_ERR

Raised if the anchor is not a descendant of the element or if it is an annoymous descendant that is not in the default view.

hidePopup

Hides the popup associated with the element, if any.

No Parameters

No Return Value

No Exceptions

setMetadataState

Sets various flags relating to the logical state of the element. The different flags have different semantics. See the list of constants below.

Parameters

state of type unsigned short

This parameter is a flag indicating which metadata state should be changed.

value of type long

What value to give the state in question.

No Return Value

No Exceptions

getMetadataState

Retrieves various flags relating to the logical state of the element. The different flags have different semantics. See the list of constants below.

Parameters

state of type unsigned short

This parameter is a flag indicating which metadata state should be retrieved.

Return Value

long

The current value for the specified state.

No Exceptions

setDynamicState

Sets various flags relating to the dynamic state of the element (in the default view). The different flags have different semantics. See the list of constants below.

Parameters

state of type unsigned short

This parameter is a flag indicating which dynamic state should be changed.

value of type boolean

What value to give the state in question.

No Return Value

No Exceptions

getDynamicState

Retrieves various flags relating to the dynamic state of the element in the current view. The different flags have different semantics. See the list of constants below.

Parameters

state of type unsigned short

This parameter is a flag indicating which dynamic state should be retrieved.

Return Value

long

The current value for the specified state.

No Exceptions

focus

Same as calling focusByMethod(FOCUS_BY_UNKNOWN).

No Parameters

No Return Value

No Exceptions

focusByMethod

Focusses the element, using the properties appropriate for the method specified to select the content of the element.

Parameters

method of type unsigned short

This parameter is a flag indicating which method was used to focus the element.

No Return Value

No Exceptions

Defined Constants For Popups

The first eight of these constants use a consistent naming scheme based on the writing-mode independent "BASE" system (Before After Start End, which map, in a left-to-right top-to-bottom writing mode such as English, to the Top Bottom Left and Right sides respectively). The first word represents the side of the target which should be adjacent to the opposite side of the anchor, and the second word represents the sides of the target and anchor which should be aligned so as to be parallel to each other.

BEFORE_START

The "before" side of the target is made adjacent to the "after" side of the anchor, and the "start" sides of the target and anchor are aligned.

BEFORE_END

The "before" side of the target is made adjacent to the "after" side of the anchor, and the "end" sides of the target and anchor are aligned.

AFTER_START

The "after" side of the target is made adjacent to the "before" side of the anchor, and the "start" sides of the target and anchor are aligned.

AFTER_END

The "after" side of the target is made adjacent to the "before" side of the anchor, and the "end" sides of the target and anchor are aligned.

START_BEFORE

The "start" side of the target is made adjacent to the "end" side of the anchor, and the "before" sides of the target and anchor are aligned.

START_AFTER

The "start" side of the target is made adjacent to the "end" side of the anchor, and the "after" sides of the target and anchor are aligned.

END_BEFORE

The "end" side of the target is made adjacent to the "start" side of the anchor, and the "before" sides of the target and anchor are aligned.

END_AFTER

The "end" side of the target is made adjacent to the "start" side of the anchor, and the "after" sides of the target and anchor are aligned.

OVERLAP

The before/start corners of the target and anchor elements are overlapped so that (if they have the same size) they appear over each other.

AFTER_POINTER

The "after" side of the target is made adjacent to the "before" side of the anchor, and the "start" side of the anchor is aligned with the last known position of the pointing device, if any, or with the "start" side of the target, if there is no pointing device.

Special Cases

If the target is null and there is a pointing device, then the last known position of the pointer is used as the target in the cases above. So for example, if alignment is set to BEFORE_START or END_AFTER, then the before/start corner of the popup is positioned at the pointer.

When the target is a point and not a region, the following constants become equivalent:

• BEFORE_START and END_AFTER
• BEFORE_END and START_AFTER
• AFTER_START, END_BEFORE, OVERLAP and AFTER_POINTER
• AFTER_END and START_BEFORE

If the popup is smaller than the screen, then the popup must appear completely on the screen. If, after aligning the popup as specified by the arguments to the showPopup method, the popup would overflow the screen, then the following algorithm should be used. The algorithm should be followed step by step until the popup fits on the screen.

1. If the popup is wider (taller) than the screen, then its outer margin width (height) should be set to the width (height) of the screen (the 'overflow' property applies).
2. If the alignment is OVERLAP and the anchor is not the popup element itself, then position the anchor as required, then shift the popup such that it touches the sides of the screen where the anchor overflows the screen (if that is in only one direction, the other axis therefore remains unaffected), and apply the 'overflow' property at that scroll position.
3. Otherwise, some as-yet-undecided algorithm is used to try each alignment value in turn, and if no possibility is found, then the popup menu is positioned on the side that had the most room, and then the dimensions of the popup are changed so that (from drop downs) it touches the relevant side of the screen or (for side opening popups) it is moved so that it touches one of the sides.

Defined Constants For Metadata State

STATE_GROUP_ENABLED

STATE_ENABLED_DISABLED

STATE_ENABLED_ENABLED

These constants are used to enable and disable user interface elements. Every element is either STATE_ENABLED_ENABLED or STATE_ENABLED_DISABLED. See the :enabled and :disabled pseudo-classes. Elements all initially start with their STATE_GROUP_ENABLED state set to STATE_ENABLED_ENABLED.

STATE_GROUP_DEFAULT

STATE_DEFAULT_NORMAL

STATE_DEFAULT_DEFAULT

These constants are used to toggle the default element of a document. Only one element per document may be the default at any one time. Setting an element to STATE_DEFAULT_DEFAULT automatically resets any other element to the STATE_DEFAULT_NORMAL state. See the :default pseudo-class. Elements all initially start with their STATE_GROUP_DEFAULT state set to STATE_DEFAULT_NORMAL.

STATE_GROUP_CHECKED

STATE_CHECKED_UNCHECKED

STATE_CHECKED_CHECKED

STATE_CHECKED_INDETERMINATE

These constants are used to toggle the value of check box and radio button interface elements. Every element has one of these values. See the :checked, :unchecked and :indeterminate pseudo-classes. Elements all initially start with their STATE_GROUP_CHECKED state set to STATE_CHECKED_UNCHECKED.

STATE_GROUP_SELECTED

STATE_SELECTED_UNSELECTED

STATE_SELECTED_SELECTED

These constants are used to determine the selection state of entire elements. (Note: This is distinct from text selection and focus.) Every element is either STATE_SELECTED_SELECTED or STATE_SELECTED_UNSELECTED. See the :selected and :unselected pseudo-classes. Elements all initially start with their STATE_GROUP_SELECTED state set to STATE_SELECTED_UNSELECTED.

STATE_GROUP_VALID

STATE_VALID_INVALID

STATE_VALID_VALID

These constants are used to determine the validity state of entire elements. For example, the XForms data model can place constraints on the possible values of controls in a form. Every element is either STATE_VALID_VALID or STATE_VALID_INVALID. See the :valid and :invalid pseudo-classes. Elements all initially start with their STATE_GROUP_VALID state set to STATE_VALID_VALID.

STATE_GROUP_REQUIRED

STATE_REQUIRED_OPTIONAL

STATE_REQUIRED_REQUIRED

These constants are used to determine whether entire elements are considered optional or required. For example, the XForms data model can require that fields be filled before allowing a form to be submitted. Every element is either STATE_REQUIRED_REQUIRED or STATE_REQUIRED_OPTIONAL. See the :required and :optional pseudo-classes. Elements all initially start with their STATE_GROUP_REQUIRED state set to STATE_REQUIRED_OPTIONAL.

STATE_GROUP_DATA

STATE_DATA_INACCESSIBLE

STATE_DATA_READABLE

STATE_DATA_WRITABLE

STATE_DATA_EDITABLE

These constants are used to determine the intended state of elements with respect to their content being edited. Note, however, that this state causes absolutely nothing to change with respect to elements' actual editing state! Typically, this state will be set by the data model being used, and selectors will then be used to change the value of the 'user-modify' property of a pseudo-element. Every element is in a logical bitwise addition of zero, one, or both of STATE_DATA_READABLE and STATE_DATA_WRITABLE. Two additional constants are provided for convenience: STATE_DATA_EDITABLE (both values set) and STATE_DATA_INACCESSIBLE (neither value set). See the :read-only, :write-only and :read-write pseudo-classes. Elements all initially start with their STATE_GROUP_DATA state set to STATE_DATA_READABLE.

STATE_GROUP_VALUE

This constant is used to access the generic integer value of user interface elements. Every element has such a value, although it is only typically used by scroll bars, track bars and progress bars. Elements all initially start with their STATE_GROUP_VALUE state set to zero.

Defined Constants For Dynamic State

DYNAMIC_ACTIVE

This constant is used to toggle the active state of elements. Only one element per view may be active at any one time. Setting an element to active automatically resets any other active element to its non-active state. See the :active pseudo-class.

DYNAMIC_HOVER

This constant is used to toggle the hover state of elements. Only one element per view may be in the hover state at any one time. Setting an element's hover state to true automatically resets any other element's hover state. See the :hover pseudo-class. User agents may, in addition to changes triggered using the setDynamicState() method, automatically set this state on elements in response to user events (such as moving the mouse).

DYNAMIC_OPEN

This constant is used to toggle the open/closed state of elements. Every element has an open/closed state for each view. Toggling the open/closed state does not affect other elements or other views. (Note: At the moment there is no way to change the open/closed state of elements in any view other than the default view.) See the :open and :closed pseudo-classes.

Defined Constants For Focus

FOCUSED_BY_UNKNOWN

An unspecified method was used to focus the element.

FOCUSED_BY_KEYBOARD

The element was focused by some keyboard action.

FOCUSED_BY_MOUSE

The element was focused by the pointing device.

Popup Display Events

Four new events are introduced, all related to popups. These use the base DOM Event interface to pass contextual information. The different types of such events that can occur are:

popupShowing

The popupShowing event occurs when the popupShow method is called. This event is only valid for elements whose 'position' property has the value popup. If the event is cancelled, then the popup will not be shown.

• Bubbles: No
• Cancelable: Yes
• Context Info: None

popupShown

The popupShown event occurs after a popup has been displayed. This event is only valid for elements whose 'position' property has the value popup.

• Bubbles: No
• Cancelable: No
• Context Info: None

popupHiding

The popupHiding event occurs when the popupHide method is called. This event is only valid for elements whose 'position' property has the value popup and which are currently displayed. If the event is cancelled, then the popup will remain visible.

• Bubbles: No
• Cancelable: Yes
• Context Info: None

popupHidden

The popupHidden event occurs after a popup has been hidden (also referred to as cancelling the popup). This event is only valid for elements whose 'position' property has the value popup.

• Bubbles: No
• Cancelable: No
• Context Info: None

UI Exceptions

This section defines some error codes used by the ElementUI interface.

IDL Definition

exception UIException {
  // UIExceptionCode
  const unsigned short      NOT_A_POPUP_ERR                = 1;
  const unsigned short      HIERARCHY_ERR                  = 2;

  unsigned short   code;
};

Defined Constants

NOT_A_POPUP_ERR

If the element does not have the 'position' property set to popup.

HIERARCHY_ERR

If the element specified is not a child of the popup element.

The Window Interface

This section will define some aspects of the DOM Level 0 "window" interface. In particular, window.open (with all its flags), resizing, possibly window.location and other features.

A great emphasis should be placed here on backwards compatibility. Only the parts that are needed for UI should be defined here.

The Window interface only applies to the default view. There is currently no defined way of obtaining the window interface for another view.

References

[CGI]

The CGI Specification. NCSA HTTPd Development Team, November 1995. The CGI Specification is available at http://hoohoo.ncsa.uiuc.edu/cgi/interface.html

[CSJSR]

Client-Side JavaScript Reference (1.3). Netscape Communications Corporation, May 1999. The Client-Side JavaScript Reference (1.3) is available at http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/index.html

[CHARMOD]

Character Model for the World Wide Web 1.0, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, T. Texin. W3C, August 2003. The latest version of the Character Model specification is available at http://www.w3.org/TR/charmod/

[CSS21]

CSS 2.1 Specification, B. Bos, T. Çelik, I. Hickson, H. Lie. W3C, September 2003. The latest version of the CSS 2.1 specification is available at http://www.w3.org/TR/CSS21

[CSS3UI]

CSS3 Basic User Interface Module, T. Çelik. W3C, July 2003. The latest version of the CSS3 UI module is available at http://www.w3.org/TR/css3-ui

[CSS3CONTENT]

CSS3 Generated and Replaced Content Module, I. Hickson. W3C, May 2003. The latest version of the CSS3 Generated and Replaced Content module is available at http://www.w3.org/TR/css3-content

[DOM3CORE]

Document Object Model (DOM) Level 3 Core Specification, A. Le Hors, P. Le Hégaret, L. Wood, G. Nicol, J. Robie, M. Champion, S. Byrne. W3C, November 2003. The latest version of the DOM Level 3 Core specification is available at http://www.w3.org/TR/DOM-Level-3-Core/

[DOM3EVENTS]

Document Object Model (DOM) Level 3 Events Specification, P. Le Hégaret, T. Pixley. W3C, November 2003. The latest version of the DOM Level 3 Events specification is available at http://www.w3.org/TR/DOM-Level-3-Events/

[DOM2HTML]

Document Object Model (DOM) Level 2 HTML Specification, J. Stenback, P. Le Hégaret, A. Le Hors. W3C, January 2003. The latest version of the DOM Level 2 HTML specification is available at http://www.w3.org/TR/DOM-Level-2-HTML/

[DOM3LS]

Document Object Model (DOM) Level 3 Load and Save Specification, J. Stenback, A. Heninger. W3C, November 2003. The latest version of the DOM Level 3 Load and Save specification is available at http://www.w3.org/TR/DOM-Level-3-LS/

[ECMA262]

ECMAScript Language Specification, Third Edition. ECMA, December 1999. This version of the ECMAScript Language is available at http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM

[HTC]

HTML Components, Chris Wilson. Microsoft, September 1998. The HTML Components submission is available at http://www.w3.org/TR/1998/NOTE-HTMLComponents-19981023

[HTML4]

HTML 4.01 Specification, D. Raggett, A. Le Hors, I. Jacobs. W3C, December 1999. The latest version of the HTML4 specification is available at http://www.w3.org/TR/html4

[ISO8601]

ISO8601:2000 Data elements and interchange formats -- Information interchange -- Representation of dates and times. ISO, December 2000. ISO8601 is available for purchase at http://www.iso.ch/

[RFC959]

File Transfer Protocol (FTP), J. Postel, J. Reynolds. IETF, October 1985. RFC959 is available at http://www.ietf.org/rfc/rfc959

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. RFC2119 is available at http://www.ietf.org/rfc/rfc2119

[RFC1738]

Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter, M. McCahill. IETF, Decembed 1998. RFC1738 is available at http://www.ietf.org/rfc/rfc1738

[RFC2368]

The mailto URL scheme, P. Hoffman, L. Masinter, J. Zawinski. IETF, July 1998. RFC2368 is available at http://www.ietf.org/rfc/rfc2368

[RFC2387]

The "data" URL scheme, L. Masinter. IETF, August 1998. RFC2387 is available at http://www.ietf.org/rfc/rfc2387

[RFC2396]

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. IETF, August 1998. RFC2396 is available at http://www.ietf.org/rfc/rfc2396

[RFC2616]

Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. IETF, June 1999. RFC2616 is available at http://www.ietf.org/rfc/rfc2616

[RFC2806]

URLs for Telephone Calls, A. Vaha-Sipila. IETF, April 2000. RFC2806 is available at http://www.ietf.org/rfc/rfc2806

[RFC2822]

Internet Message Format, P. Resnick. IETF, April 2001. RFC2822 is available at http://www.ietf.org/rfc/rfc2822

[RFC2854]

The 'text/html' Media Type, D. Connolly, L. Masinter. IETF, June 2000. RFC2854 is available at http://www.ietf.org/rfc/rfc2854

[RFC3023]

XML Media Types, M. Murata, S. St.Laurent, D. Kohn. IETF, January 2001. RFC 3023 is available at http://www.ietf.org/rfc/rfc3023

[RFC3106]

ECML v1.1: Field Specifications for E-Commerce, D. Eastlake, T Goldstein. IETF, April 2001. RFC 3106 is available at http://www.ietf.org/rfc/rfc3106

[WF2]

Web Forms 2.0, I. Hickson. Opera Software, February 2004. The latest version of the Web Forms 2.0 proposed specification is available at http://www.hixie.ch/specs/html/forms/web-forms

[XBL]

XML Binding Language, David Hyatt. Mozilla, February 2001. The XBL submission is available at http://www.w3.org/TR/2001/NOTE-xbl-20010223/

[XML]

Extensible Markup Language (XML) 1.0 (Second Edition), T Bray, J Paoli, C. M. Sperberg-McQueen, E. Maler. W3C, October 2000. The latest version of the XML specification is available at http://www.w3.org/TR/REC-xml/

[XHTML1]

XHTML™ 1.1 - Module-based XHTML, M. Altheim, S. McCarron. W3C, May 2001. The latest version of the XHTML 1.1 specification is available at http://www.w3.org/TR/xhtml11

[XHTML2]

XXX

[XForms]

XForms 1.0, M. Dubinko, L. Klotz, R. Merrick, T. Raman. W3C, October 2003. The latest version of the XForms specification is available at http://www.w3.org/TR/xforms

Acknowledgements

Thanks to Håkon Wium Lie, David Hyatt and Brendan Eich for their important support. Thanks to Matthew Mastracci and Steven Garrity for their useful and substantial comments.

Thanks also to the Microsoft blogging community for some ideas, and to the #mozilla crew, the #opera crew, and the #mrt crew for their ideas and support.