Abstract
...
Status of this document
This is a work in progress! This document is changing
on a daily if not hourly basis in response to comments and as a general
part of its development process. Comments are very welcome, please send
them to webapps@damowmow.com
and cc www-archive@w3.org. Thank you.
It is very wrong to cite this as anything other than a work in
progress. Do not implement this in a production product. It is not ready
yet! At all!
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
1. 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.
1.1. 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
div
s, 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?)
1.2. 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.
1.3. 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.
1.4. 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.
1.5. 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.
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.)
1.7. Terminology
...
2. ...
...
2.1. 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 216-1 (65535)
represents the highest progress/scroll position/slider position.
2.2. 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.
2.3. 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.
2.4. 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.
3. 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.
3.1. Text Selection
'user-can-select'
Value:
| never | always | only-with-modifier
|
Initial:
| always
|
Applies To:
| all elements and generated content
|
Inherited:
| yes
|
Percentages:
| n/a
|
Media:
| visual
|
Computed Value:
| specified value
|
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.
3.2. Focus
'user-can-focus'
Value:
| takes-focus | leaves-focus | resets-focus
|
Initial:
| leaves-focus
|
Applies To:
| all elements (but not pseudo-elements)
|
Inherited:
| no
|
Percentages:
| n/a
|
Media:
| visual
|
Computed Value:
| specified value
|
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.
'user-focus-select-pointer'
Value:
| all | reset | ignore
|
Initial:
| ignore
|
Applies To:
| all elements with user-can-focus:
takes-focus and user-can-select: always
|
Inherited:
| no
|
Percentages:
| n/a
|
Media:
| visual
|
Computed Value:
| specified value
|
'user-focus-select-key'
Value:
| all | reset | ignore
|
Initial:
| ignore
|
Applies To:
| all elements with user-can-focus:
takes-focus and user-can-select: always
|
Inherited:
| no
|
Percentages:
| n/a
|
Media:
| visual
|
Computed Value:
| specified value
|
'user-focus-select-unknown'
Value:
| all | reset | ignore
|
Initial:
| ignore
|
Applies To:
| all elements with user-can-focus:
takes-focus and user-can-select: always
|
Inherited:
| no
|
Percentages:
| n/a
|
Media:
| visual
|
Computed Value:
| specified value
|
'user-focus-select'
Value:
| all | reset | ignore
|
Initial:
| not defined for shorthand properties
|
Applies To:
| see prose
|
Inherited:
| no
|
Percentages:
| n/a
|
Media:
| visual
|
Computed Value:
| specified value
|
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.
3.3. Editing
'user-modify'
Value:
| read-only | all | [ add-text || edit-text || add-elements ||
move-elements || attributes || deletable ]
|
Initial:
| read-only
|
Applies To:
| all elements that can obtain focus
|
Inherited:
| yes
|
Percentages:
| n/a
|
Media:
| interactive
|
Computed Value:
| specified value
|
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.
3.4. 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.
3.5. Changes to position
The value popup is added to the 'position' property. When this value is applied to
an element, the following changes apply:
- The element is taken out of flow and not shown (same as display:none).
- 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.
4. DOM Interfaces
4.1. 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.
4.2. 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.
- 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).
- 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.
- 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.
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
4.4. 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.
4.5. 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.