All graphical elements in Protovis are called marks. The pv.Mark class itself does not provide any specific rendering functionality, and is rarely used directly (unless you're defining a new mark type), but together with panels establishes the core framework.
See also: pv.Mark API reference
All marks have at least the following properties:
Concrete mark types include familiar visual elements such as bars, lines and labels. Although a bar mark may be used to construct a bar chart, marks know nothing about charts; it is only through their specification and composition that charts are produced. These building blocks permit many combinatorial possibilities.
Marks are associated with data: a mark is rendered once per associated datum, mapping the datum to visual properties such as position and color. Thus, a single mark specification represents a set of visual elements that share the same data and visual encoding. In the case of a bar, each datum corresponds to a solid rectangle, while with an area, each datum corresponds to a vertical or horizontal span.
Unlike other visualization systems, Protovis does not place any constraints on the input data, other than each mark has some associated array of data objects. In the simplest case, the data is just an array of numbers; but by defining suitable property functions, any the elements can be structured objects or even nested arrays.
The type of mark defines the names of properties and their meaning. A property may be static, ignoring the associated datum and returning a constant (e.g., 20); or, it may be dynamic, derived from the associated datum or index (e.g., d * 80). Such dynamic encodings can be specified succinctly using anonymous functions. Special properties called event handlers can be registered to add interactivity.
Some mark types, such as lines and areas, may generate a single visual element rather than a distinct visual element per datum. With these marks, some properties may be fixed. Fixed properties can vary per mark, but not per datum. These properties are evaluated solely for the first (0-index) datum. The handful of properties that have this constraint are clearly flagged as such (and in fact, usually there's a workaround to make them dynamic again).
Marks may also inherit properties from type-specific defaults. For example, bars and wedges define default fill colors.