Structured Object Model Windows, containers, and individual interface elements along with their runtime attributes and styles are exposed to procedural code as a scriptable and manageable hierarchy of objects. Each DOM element has an assumed layout parent, and can have one or more child elements. This object model will hereby be referred to as a scene.

Element Reparenting Elements are detachable from a parent node and able to be reparented to another element in the same scene/document, or to another element in a different scene.

Element Cloning One or more elements, inclusive of their object hierarchy are cloneable.

Element Class and Identity Elements can be located as unique objects in a scene by an id. Classes of elements can be enumerated and located by type.

Anonymous Content Elements and sub-hierarchies of elements can be deemed as anonymous (private) such as within component parts - as such these elements are not locatable publically within the structured object model.

DOM Virtualization Some portions of the DOM are considered transient and/or virtual (such as in the case of data bound item containers, list controls, etc.). These portions of the DOM may or may not be anonymous. DOM virtualization is a powerful tool that can improve runtime performance and memory consumption for complex documents.

Deferred Instantiation Deferred instantiation of complex DOM hierarchies that are initially or by default collapsed can improve scene load times and memory consumption.

DOM Templates and Repeaters Element templates can be defined and reused for purposes of "stamping" element hierarchies multiple times (via repeaters within a scene definition), or as prototypes for components, and data binding.

Box Model Element Attributes Element dimensions: width, height, and position expressed as top, left, bottom, right properties. Element dimensions are either explicit, or implicit. Intrisic size is implicit for image elements for example. Also supported are element margins and padding (outer and inner spacing) - top, bottom, left, and right margins and padding can be specified independently.

Sibling Spacing A uniform horizontal or vertical spacing per child can be specified for a given element (space between children of a container) so as to reduce dependency on element margins.

Size Constraints Optional minimum and maximum widths and heights.

Alignment Alignment relative to start, center, and end of a container (and relative to an axis), as relevant to the active layout algorithm.

Orientation If relevant to active layout algorithm orientation (vertical vs. horizontal for example) can be specified.

Offsets and Bulge Top, left, bottom, and right offsets can be specified to offset an element relative to where it was layed out by active layout. Width and height offsets can be applied to bulge or shrink an element beyond its default layout.

Modular Layout Algorithms Plug-n-play layout algorithms – either stock algorithms or custom layout algorithms (provided as custom authored procedural code):

Absolute Placement Stock layout option providing means of fixed positioning elements via left, top, bottom, and right properties. Elements are arranged relative to parent element. Percentage placement relative to parent is also supported (e.g. left of 50% would imply left edge is centered relative to parent).

Adaptive Layout Thresholds can be specified so that alternate layout models can be applied based on size triggers. Allows an element to adapt to a more appropriate layout model as available presentation real estate is reduced or increased.

Layers and zIndex Elements can be layered (and composited) relative to sibling elements, or relative to other layers in the global scene. Elements can also be placed in a layer below the root scene, to facilitate things like "drawers" where elements can slide out from under or behind the root scene.

DOM Visiblity Elements and their children can be collapsed or hidden. Collapsed elements take no logic space within the visual tree. Hidden elements are rendered at 0% opacity but are layed out along with siblings.

Overflow If an element is constrained to a given size, but its children exceed the bounds of the parent element, overflow occurs. Overflow behaviors can be specified on a per axis basis, and the following can occur (in most stock layout algorithms): elements can be clipped, elements can be allowed to exceed the bounds of the parent element, the parent element displays a scrollbar. Some layout algorithms support additonal overflow behaviors such as wrapping the overflowed elements (flow), or cropping the remaining elements (text label using ellipses).

Resolution Independence All element positions and dimensions can be expressed in resolution independent terms.

2D Transformations Stacked affine transformations at the element level (rotation, scale, skew, flip) are supported as attributes. As elements are scaled, a generic means of swapping scale appropriate textures (fills) is also provided to enable level of detail.

3D Transformations For 3D elements, equivalent 3D transformations are supported. LOD textures and meshes also supported.

Image Fills Elements can be styled with raster images if desired. 9-slice fill coordinates can be specified to create a procedural texture that will not skew corners and borders. Alternatively images can be tiled to support patterns or stretched along either axis.

Color Transforms Color transforms can be applied to elements, each color channel (RGBA) can be adjusted independently, or color overlays can be applied.

Filtering Additional raster filters (blurs,etc.) can be applied via element properites as well. Procedural drop shadows (alpha keyed), glows, and bevels are supported via built-in element styles. Custom raster filters can be applied and registered as well.

Opacity Per-pixel alpha channel is support on all elements. Global element opacity (inclusive of the top level scene or window) is also supported assuming OS capabilities are present.

Gradients Linear and Radial gradients are supported as reuseable resources. These resources in the form of brushes, can be applied as a fill, or mask. These resources are scriptable and allow variable color stops settable at runtime.

Opacity Masks Masks are supported and can be sourced from an image resource's alpha channel, or from a gradient resource.

Thumbnailing and Snapshots Thumbnails can be generated from any element at the original aspect ratio or affine scaled. These snapshots can be part of the visual tree (to use as temporary facades for example). Thumbnails and snapshots can be persisted and encoded or can be dynamically added as library resource at runtime.

Clipping Clipping rectangles or regions can be specified for an element, including the top level window.

Strokes All elements support a procedural stroke. Color, thickness, corner radius can be specified on a per edge basis. Stroke patterns can also be specified.

Video Fills In addition to raster based fills, video fills are also supported.

Canvas The visual of an element can be procedurally modified at runtime via a built-in drawing api.

Drawing API A drawing api is provided to allow custom rendering. This drawing api supports 2D primitives, text, paths, image fills, gradient fills.

Raster FX API A filtering api is provided to allow per-pixel scripting of an element's visual.

Custom Elements Component building is fully modular in that new components are composited from existing elements, given a class name, and reused. The resulting hierarchy of elements is referred to as the "parts" of the component. Parts can be individually styled via the built-in styling language.

Primitives A component can adopt a stock layout algorithm for its children, fashion it's component parts from existing elements, or primitive types (selectable element, button, etc). A component can also adopt one of many built-in behaviors. The toolkit provides stock base behaviors and layout algorithms.

Component Inheritance A new component can inherit its behavior, object model, code-behind (if any), or style from existing elements.

Attribute Bonds A component can map it's own public properties and attributes to those of its parts.

Content Areas One or more content areas can be specified within the component part hierarchy. This denotes where DOM children exist relative to component parts in the element's hierarchy. Content areas are a core feature of DOM templates, and the parts definition of a component makes use of the built in templating functionality. Similar to XUL overlays and XUL templates.

Scene Embedding / Modular Content A component can be embedded in one or more scenes via unique class name. One or more scenes can be embedded in a component or other scenes via unique scene or document url.

The toolkit provides a stock library of pre-built components, styles, and behaviors (all elements additionally support embedding any other element via composition). The usual fare:

Font Attributes Modifiable font and text attributes include type face, size, weight (boldness), italics, color, leading, tracking, smoothing, and kerning hints.

Embeddable Outlines In addition to support those fonts installed as part of the host OS, the toolkit supports embedding outlines for custom fonts, with no dependencies on host OS.

Bitmap Fonts Aliased text and embeddable bitmap fonts are supported (and encouraged for ultra-small text).

Embeddable Outlines In addition to support those fonts installed as part of the host OS, the toolkit supports embedding outlines for custom fonts, with no dependencies on host OS.

Auto Highlighting Text highlighting is natively supported. A filter string can be specified at the level of a parent element, and any time that substring appears within a descendant element, it can be optionally highlighted (with a custom highlight style).

Art Fonts Embeddable raster or vector alphabets and fonts can be declared and used as dynamic text (non-editable):

Style Resources Bundles of styles can be defined and reused as style resources. Bundles can contain other, conditional bundles, that are applied only when certain triggers are satisfied (property/value triggers, or event triggers) Bundles can also contain sub-bundles that target specific component parts. Style bundles can derive from other style bundles as well. Styles are instantiated and applied as a group of properties on elements based on "selectors".

Styling Inheritence All styles support inheritence from pre-existing style definitions.

Style Selectors Styles can be applied in a push fashion (by using class selectors, instance selectors, or component part selection), as well as in a pull-fashion by defining a style class that can be used on a per element basis. Styles can also be applied en masse via ancestor and descendent selectors.

Triggers A compound style definition utilizes triggers to determine when to apply a particular sub-bundle. Property triggers (when element hovered property is true, apply style X) are supported as well as event triggers (when element is created apply style X).

Auto Highlighting Style bundles as resources can be referenced in other ways such as specifiying a highlight style to be used for auto-highlighting and filtering

Theming Though styles are simply resources within a resource library, they can be organized in the form of style sheets, and replaced or extended at runtime to facilitate interface themeing.

OS Styles Built in constants can be used within style definitions to apply a particular system color, system control style, text metric, or other system metric.

One hugely important aspect of the killer interface toolkit is tight integration with host OS:

Screen, Monitor, and Workspace Awareness As explained later in the windowing section.

Taskbar Integration Support for integration, interaction with and automation of any persistent OS desktop component such as the dock, taskbar, system tray, or sidebar.

Clipboard Support for consuming all native clipboard formats (both inherently as part of edit controls, as well as procedurally) e.g. paste. Support for fabricating data for the native clipboard (copy).

Drag and Drop Support for consuming native drag and drop data and for exposing data as native drag source.

Native Look and Feel See equivalent styling comments. Must be able to support styles that adopt native look and feel and colors automatically. Also need to support sytem metrics and system behaviors as stock resources.

Hotkeys Support for registering system wide hot keys.

Printing Support for exposing elements as printable entity (supporting pagination, and all common print options).

Attributes Settable and stylable properties of a window include (but are not limited to) size,position, visibility, presence of native chrome,process icon, task icon, caption, presence of native system menu, minimize button, maximize button, restore button, resizabilty, chrome resizer, is fullscreen, is ocked, native frame border type, translucency or clip mask.

States Windows support the following event states - maximized, active, inactive, minimized, docked, topmost, bottom most, z index.

Screen Relative Size and Position The toolkit is cognescent of the display, display size, workspace size, and multi-monitor configuration. All workspace properties are queryable from procedural code as well.

Modality Modality and in what context the modality exists, can be specified during scene creation.

System Dialogs Access to and creation of all stock system dialogs is provided.

Popups A variety of popup types, presentation triggers, alignment (cursor aligned or element aligned), and dismissal triggers can be specified. Popup chains and popup ownership (top level or parent scene) can be specified.

MDI Multiple windowing models are inherently supported, inclusive of classic MDI.

Magnetic Windows A robust magenetic window api is provided to allow for a window to snap to or stick to another window of its class (polarity). Master/slave window relationships can be specified.

Snapping Windows can be configured to snap to specific workspace points, edges, and grids.

ZIndex Window z-order and relation to other windows can be specified at runtime.

Embeddable Panes Scenes can be embedded into os relevant locations (other windows via embedding api, web browsers, side bars, etc.)

Docking Top most windows can dock to desktop or workspace edges using native OS mechanism.

Tooltips Tooltips (hover triggered), auto-tooltips (overfowed static text), instant-tooltips (no timer), or custom tooltips (owner specified content), are supported.

Persistence A windows full geometry and desktop location can be persisted and restored. One or more windows can be persisted as a set.

Anchored Windows Windows can be anchored to other windows (irregardless to z-order).

Cascades Windows can be layed out on demand as either cascades, tiles, magnet groups, or anchor groups.

Bubble Help Generic bubble help windows are provided as stock.

Wizards Various dom templates are provide for use as wizards, navigation shells, etc.

History Management Any element that can dynamically host a dom template or a scene, has built-in, scriptable history management.

Mouse Input Your most common mouse events (click, button up, button down, drag, hover, enter, leave, etc.) are supported. Mouse events propogate up to ancestor elements. Other mouse related interaction include cursor modication on mouse over, event triggers on timed hover, context event on right-click, etc. All mouse events can be handled at the element level or scene level.

Focus Mouse and keyboard focus state is managed by the toolkit. Elements can be configured to accept, reject, or deflect focus to ancestors, children, or component parts.

Keyboard Input Your most common key related events (key down, key up, key press, accelerator keys, system key combinations, shortcut keys, command actions (space/enter), are supported.

Custom Tab Order A tab index property is provided to allow modification of default tab order.

DOM Events DOM events supporting element lifetime management (created, destroyed, presented, etc.), are provided.

Selection and Currency For those elements supporting child selection, selection and currency (cursor items) are managed by the toolkit.

Context Events Element contextual events such as context menus, popups, tooltips, and help, are provided.

Drag Behaviors Drag related events are provided to allow content authors to key off of drag allowed, drag start, drag over, and drag end.

Disabling Elements All elements can be disabled and rendered immune for interactions.

Event Fabrication The toolkit supports procedural fabrication of input and dom events, as well as custom events.

Drag and Drop All events necessary for OS drag and drop, drag data inspection, and rejection, are provided.

Ornamental Elements Elements can be tagged as ornamental, and as such will support "click-through" to lower elements in dom.

Device Extensions The toolkit supports plugins to extend the event space for new devices (five button mice, pen, etc.)

Mouse Tracking An api for tracking mouse events beyond the range of elements is provided.

Reuse of Behaviors Behaviors (a collection of event, and action pairs) can be reused by one or more elements or classes of elements.

Element Mutation Listeners can be registered on element property mutation events (attribute change)

Hit Testing An api is provided to support procedural hit testing of DOM elements.

Popups and Popup Chains Popup open triggers(on click or on hover), and close triggers(popup deactivate, mouse exit, timer event, blur, command) can be specified.

Scrolling Overflowed elements can be procedurally scrolled (Smooth Scroll, Quick Scroll via device context, Eased, or Carousel Scrolled (wrapped to start)). Scrolling

Element Selection All elements support a caret selected style and can participate in OS clipboard (copy) operations.

Audio Triggers Audio resources can be triggered from any event, as multichannel, streaming, sound bytes.

Help System All elements can provide a help id that is displayed as contextual bubble help, indexed into a callback (for triggering user guide for example) or visual help overlay which is displayed relative to the element when help overlays are enabled). Help related events are dispatched by the system when appropriate OS help key(s) are fired.

Element To Element Any element can bind one or more of its properties to those of one or more other elements. This binding relationship can be configured as one way, two way, or on demand.

Element To Code Any element can bind one or more of its properties to those of one or more procedural objects (data models implemented in code and registered as a data source). This binding relationship can be configured as one way, two way, or on demand.

Element To Collection Any element can bind to a procedural object conforming to a well-known collection interface. The element can bind it's own properties to this collection, or can fabricate a virtual DOM based on items in this collection (by making use of DOM templates and stamping).

DOM Stamping For collection bound elements, a set of templates and matching rules can be configured such that for each item in the collection, a UI element is created and managed at the view level.

XML Binding Support for binding to various standard formats from the "semantic web" is supported (generic XML, RDF, etc.).

Data Transformation For data bound elements transformers can be specified that transform data as it flows to and/or from source and target. Custom transformers can be registered and used.

Data Validation For data bound elements transformers can be specified that validates data as it flows to and/or from source and target. If validation fails, data does not flow to completion. Custom validators can be registered and used.

Data Aggregators For data coming from many different sources, data can be aggregated into single bindable data object (data container).

DOM Scripting All DOM element properties and their relation to their siblings, parents, and ancestors is fully scriptable from the bound procedural language (code-behind) for the scene.

Language The interface toolkit is language agnostic, and can support multiple languages at once at a scene and component level. Implementation of the interface kit should not necessarily make assumptions about the underlying runtime. The toolkit specification should not warrant a need for example of "managed vs. unmanaged code".

Timer Code-behind can be triggered at individual ticks of the global timeline or upon element level keyframes.

Behaviors All events can be handles either by stock actions or via custom code. Any event can be handled at the global scene level, or individual component level.

Custom Layout Custom layout algorithms can be registered and implemented in code-behind.

Custom Render The visual aspects of an element can be fully procedural via registered code-behind and the built-in drawing apis.

3D Lighting, cameras, depth, texturing, and shaders can all be automated from code-behind for 3D primitives and 3D elements.

The following are resource types that can appear in a reuseable resource library. All resources are identified by library url and id.

Fonts Font bundles (inclusive of all font properties, glyphs or paths) can be defined and reused.

Bitmaps Images (denoted by url) and image brushes (defining all fill properties) can be defined and reused. Bitmap resource formats supported include all relevant formats of the day (bmp, jpg, jpg2000, gif, etc.), including those supporting per-pixel alpha (png).

Animated Media Animated image and media formats are also supported, including SWF, GIF, MNG/APNG.

Video OS relevant video formats are support for reuse as fills.

Sound OS relevant sound formats are supported for use with event triggers.

Colors Color resources (ARGB format) can be defined and reused within other resource specications (gradients, fills, inline styles, style bundles)

Styles Style bundles and their rules are defined as resources and reused via instancing or inheritance.

Brushes Solid brushes, image brushes, gradient brushes, mask brushes, filter brushes can all be defined as reuseable resources.

Vector Objects Vector paths (supporting either SVG or a simpler native format) can be defined and resused as fills or as paths.

Animations Animations and animation groups can be specified as a resource and reused.

Templates DOM templates, markup overlays, and data templates can be defined and reused as resources.

Resource Streaming All resources can either come from a local library or be reference remotely (network) via URL.

Declarative Animation Any property of any element can be animated over time from one value to another. Animations can be cascaded and setup to trigger other animations. Animations can be started based on property triggers, style triggers, or event triggers (hovered, pressed, dragged over, etc.). Animation parameters can be set and configured at runtime dynamically (duration, start value, end value, etc.).

Raster Transitions A stock library of raster transitions is provided for transitioning between two DOM snapshots. Examples include cross-fade, morph transitions, push, flip, etc. All stock adobe after effects transitions are candidates for inclusion as stock UI transitions.

Dynamics All property animations or binary transitions can make use of an optional dynamics property that allows the animation to conform to an interpolated curve over time rather than a linear change. For example, various types of easing, spring dynamics, gravity, or acceleration and deceleration curves can be applied as stock for all animations or custom dynamics can be applied.

Motion Paths Motion paths can be specified as a vector resource. Elements can animate their fixed position along a motion path between n "stops".

Master Timeline and Keyframes Elements support pre-scripted animations of their visual state in the form of keyframes. Keyframe animations are fully scriptable and can execute based on event or property triggers. An active keyframe animation can be stopped, rewound, forwarded, paused, or reversed. All keyframes are bound to a master application timeline and framerate, but can specify their own framerate at or below that of the master timeline.

DOM Transitions DOM transitions are supported allowing animation elements to and from their new locations after layout parameters are changed. Useful for list sorting dynamics, or for morphing the configuration and orientation of screen elements based on user interaction.

Hardware Acceleration Hardware accleration will be used by the rasterization layer as available and appropriate to boost performance.

Memory and Footprint Memory usage (for example) must meet or exceed that of a native application. This implies a creative use of DOM Virtualization, deferred instantiation, and a compact and efficient runtime. The interface runtime must be sufficiently performant as to be embeddable (devices and the such).

Compiled Content In addition to supporting a dynamic parser and interpretor for dynamic content, content can be cached in a pre-compiled binary format to speed future instantiation of the same content.

Interactivity and Responsiveness The responsiveness of the interface toolkit must meet or exceed that of a native application.

Scaleable Dynamics A mechanism for throttling and/or disabling dynamics, animations, and transitions for low resource situations.

Incremental Layout All stock layout algorithms utilize layout hints to ensure only only what needs to layout during a global resize is actually affected.

Screen Reader Support An accessibility api is provided to allow custom component authors to author accessible content (via direct synchronization of UI state and purpose to native os screen reader api).

High Contrast A high contrast filter can be applied automatically by the toolkit for all raster images. Styling constants can be used to adopt the native OS color schemes which allows content to conform to any high-contrast theme active.

Large Fonts A global scaler can be applied to all textual elements at once, all other elements are reflowed accordingly assuming use of stock layout algorithms. The styling engine can be keyed directly to OS large fonts settings (face, point size).

Keyboard Navigation The toolkit provides the means of ensuring all elements are keyboard accessible via modular behaviors. A default tab order allows all focuseable elements to be navigated in a locale appropriate manner. custom tab order (via tab indecies) and custom keyboard event mutations are also provided.

IME Support While not inherently accessibility related, all dynamic, editable text elements support system IME automation.

Localization All content, string tables, and resource libraries are packaged in such a way as to provide per-locale presentation of interface.

Binary Resource Format A compressed binary container format is offered (jars) to speed up load times and instantiation for client side persistent content.

Component Caches All newly acquired or imported components are cached in binary form to speed later reuse.

Focused Element Callout A debugging tool to highlight the current element with keyboard focus is provided. This allows the content author to finalize tab order, or to debug focus issues with compound components.

Dirty Rectangle Callout A debugging tool to visualize all dirty rectangles (paint rectangles) as items are painted is provided. This allows the content author to find and detect inefficient animations or misbehaving components.

Layout Hotspot Callout A debugging tool to visualize all elements as they are layed out is provided. This helps in finding and fixing possible busy or complex hierarchies that may be causing performance issues.

DOM Inspector A tool to visualize and modify element hierarchy, element properties, and element styles.

Event Inspector A tool to visualize all scene events, their payload, and their lifetime. Filtering on event type or id is an option.

Animation Inspector A designers tool to inspect and debug scene animations, monitor keyframes, and adjust timeline resolution (slow down).

Tracking System A built-in system to log UI coverage (unique clicks across elements, etc.).