1.1
Overview

This chapter describes the optional DOM Level 3 Views and
Formatting feature. A DOM application can use the
hasFeature method of the DOMImplementation
interface to determine whether this feature is supported or not. The
feature string for generic interfaces is "ViewsAndFormatting". The
feature string for visual properties and interfaces is
"VisualViewsAndFormatting". The additional feature strings will be
used to identify support specific to other media,

DOM implementations frequently create views of the document content
available through DOM APIs. Such views present content in different
ways using various processing, styling, and presentation systems.
While a strong separation is typically maintained between content and
the view, DOM applications may need to correlate characteristics such
as position within a visual view with specific content presented within
the view in order to augment and interact with the presentation.

This API allows a DOM application access to a view's computed layout and
presentation. This feature functions independently from any specific
styling system that may have been applied. An implementation of this
API must be able to maintain a correspondence between specific content
and its presentation within the view, however the presentation was
computed. Presentation state such as selection or scrolling may be
manipulatable though this interface, but state which is computed or
supplied from the content must be manipulated through the content.

Two versions of the API have been supplied, which are redundant in
their functionality. The DOM WG has not decided which of the two is
better, or if both are needed. The generic API, described first, is
more robust because the specifics are contained in identifying strings
passed to general mechanisms. The medium-specific APIs, described
last, directly expose the attributes of the medium on the interface,
which provides a flatter, simpler model for the user, but one which
is less able to adapt to new or extended media types or different uses.

1.1.1
Issues

We need to comprehensively look at typical presentations and decide
the initial segments, properties, orders, and lookup criteria we want to
support, at least in the visual case. We also need to see if we
think that Visual needs to be further subclassed. We are clearly
lacking things, but how many segment types and properties do we
need to reasonably meet requirements for level 3?

How should we represent types such as colors, fonts, and so on.
How much time we can spend defining reporting value types
or supporting arbitrary display value types. CSS style properties
have done significant work in these areas, but it is not clear that
their work is applicable for this view model, due to differences
between stylistic intent and computed results.

What types of events should we support: keyboard, mouse, selection,
repaint, layout, properties, etc. Is it reasonable to support these
at the view level, without exposing the lower layers of the
presentation? Can we wait for a future version of the spec? We need
compelling use cases for the first release.

Is it reasonable to expose computed content? Should this be done
by creating appropriate DocumentFragments? How does this figure
into the ordering of the segments, since segments which present
computed content instead of other content have less natural order.
We need compelling use cases for the first release.

What about case insensitivity when comparing string values? Should
it be an option, the rule, or automatic?

1.1.2
Segments

A Segment is a distinct part of a view. Each Segment
is privately owned and maintained by the containing view, which may
destroy or reconstruct it at any time. Each Segment has a type
related to the presentation medium and the function of that part of
the presentation. Additional properties specific to the segment type
contain information about that part of the view and identify the
corresponding content, if any. Segments may also contain embedded
segments where appropriate to the structure of the presentation.

A Segment is not expected to have any particular structure
beyond its properties, any contained segments, and dependency on the
content it presents. Containment of one segment within another does not
change the fact that properties such as offsets are relative to the
entire view so that they may be matched, applied, and compared from
anywhere within the view.

The actual segments or parts of the view are not directly
available to the DOM application, but this API provides generic
Segment objects which can more-generally find and
return items of the actual parts of the view.

1.1.3
View

A View is the root of a presentation, owned and
maintained by a Document. A view formats the contents
of a document into a particular type of presentation. A view may
contain general properties of the view, resource segments, and
segments representing the content of a document, prepared for
presentation.

A Segment object specifies the actual criteria of
segments to match, and captures items of each matched segment.

1.1.4
Generic and Medium-Specific APIs

The generic API provides access to variety of view and segment types
by way of a medium-specific table of strings used to identify
properties of medium-specific segment types:

1.2
Formal Interface Definition for a Generic View

This is the verbose, general-purpose mechanism that can handle all
properties of all media types. This relies on a separate table of
segment types and the associated properties and property types,
because it is a single API.

The criteriaMatch of a
Segment, specified during creation, controls which
Segments will match.
After setting this attribute, the results of any related call
to getNext are unpredictable until the segment has
been requested again by calling matchFirstSegment.

The order string of a Segment, specified
during creation, controls the order in which matching segments
will be returned. If this attribute is not specified, the order
defaults to an implementation-specific order.
After setting this attribute, the results of any related call
to getNext are unpredictable until the segment has
been requested again by calling matchFirstSegment.

Returns a specific Item, of the list specified
during the creation of the Segment, which is to be
fetched during Segment execution, or returns null if
the specified index does not correspond to a Item.

The exists boolean of a Segment, initially
set to false during creation, is set after an attempt to fetch the
values of a Item to indicate whether or not the
required data was present. A true value indicates that it was.

The offset value returned by the Segment, which is undefined if
exists is false.

1.3
Formal Interface Definition for a Visual View

This is the flatter mechanism that handles only one specific medium,
in this case, visual. This does not rely on a table of property names, because
all supported criteria and properties are attributes of the interfaces.

Creates a visual character run to match and return information
on a run of similar ajdacent visual characters of the view.
This will match the largest character run that meets the
specified criteria, is not contiguously displayed on
the view and has homogeneous display properties.

Visual segments contain match criteria attributes and result
attributes common to visual views of a document. When this
structure is created, all booleans are set to false, all integral
values are set to 0, and all strings and object references are set
to null. Match criteria are then set. After setting match
criteria, matchSegment is called passing this
segment or another segment that references this segment, which
finds a matching segment and sets result attributes.

Whenever a segment is matched, this is set to the integral
value of the background color of that segment, or transparent
if there is no background color. The 32 bits of this value
are divided into the following 8-bit sub-fields, from most
significant to least significant: alpha, red, green, blue.
The color fields range from 0 for no intensity to 255
to indicate the contribution of each color. The alpha
field ranges from 0 for transparent to 255 for completely
opaque. For a transparent alpha value of 0, the color fields
are be normalized to 0 as well.

Whenever a segment is matched, this is set to the integral
value of the foreground color of that segment, or transparent
if there is no foreground color. The 32 bits of this value
are divided into the following 8-bit sub-fields, from most
significant to least significant: alpha, red, green, blue.
The color fields range from 0 for no intensity to 255
to indicate the contribution of each color. The alpha
field ranges from 0 for transparent to 255 for completely
opaque. For complete transparency, the color fields will
be normalized to 0 as well.

The node, or first node in a range to use to match segments
which present specified content.
If matching content is enabled, but this is set to null, then
only segments that are not associated with content will be
matched.

The second node in a range to use to match segments
which present specified content.
If matching a content range is enabled, but this is set to null,
then only segments that are not associated with content will be
matched.

May be set to cause the corresponding segment to only be matched
if the content it presents is within the range of content between
Node matchNode offset matchOffset and
Node matchNodeR offset matchOffsetR.

May be set to contain embedded visual segments
inside the frame. If this value is set, the embedded segment
serves as a conditional for the frame while receiving
the results of the embedded segment that was matched.