I want to propose a clearer definition of View in the editor.

A View is not the same thing as formatting, and it is not the same thing as style. To make the distinction clearer, I think we should separate these concepts explicitly:

Formatting refers to direct, local markup choices such as bold, italic, underline, strikethrough, link, code, text color, and highlight. Formatting answers the question: How is this content marked up?

Style refers to higher-level presentation semantics or presets such as paragraph, heading, quote, list type, size scale, font family, or grid/column structure. Style answers the question: What kind of block or presentation preset is this?

View options are the adjustable parameters of a View. They control how content is revealed, scoped, filtered, or navigated without changing the underlying content itself. This is the right category for things like collapse/expand, zooming, filtering, clipping, leveling, and outlining.

A View is the composed and potentially shareable presentation layer through which content is seen and interacted with. A View can apply to multiple scopes: to a single block, a group of blocks, or an entire document. It is the overall representation of the content in a given context. This allows us to talk meaningfully about things like Card View, Doc View, or other named views as real representations of the same underlying content.

So the distinction we should use is:

Formatting = how content is marked up

Style = what kind of block or presentation preset it is

View options = the adjustable parameters that modify how a View behaves

View = the overall representation of the content

Card View makes sense in this model because a View can apply at different scopes: to a single block, a group of blocks, or a whole document. A Card View defines one particular way of presenting content in card form.

I think this gives us a much stronger conceptual model for the editor. Instead of treating things like “card,” “doc,” “expanded,” “collapsed,” “outline,” or “filtered” as ad hoc display states, we can organize them more clearly. That should help us reason more effectively about embeds, block actions, document presentation, and any future features where users may want to switch, save, or share how content is being viewed.

Extensibility: community-defined Views

This model should scale beyond built-in representations like Card View and Doc View. If the community starts building things like Graph Views or Dashboard Views, those should still fit naturally into the same system. They would be understood as Views: named, shareable representations of the same underlying content, applied at the scope of a block, a group of blocks, or an entire document.

Under this model, the distinction remains the same:

Formatting defines local markup

Style defines local or structural presentation presets

View defines the overall representation

View options adjust how that representation behaves

So a Graph View might present content through nodes, edges, and relationships, while a Dashboard View might present it through panels, widgets, and metrics. Each of these Views could also have their own View options. For example, a Graph View might expose options like layout, depth, clustering, filtering, or edge visibility, while a Dashboard View might expose options like grouping, sorting, widget selection, density, or time range. In the same way, a Document View can have options such as expanded/collapsed, clipping, filtering, levelling, or outline.

This is important because it means our concept of View is not tied to a fixed set of built-in representations. It gives us a general model that can support both core product features and community-defined representations. In that sense, a View is not just a visual mode; it is a structured and shareable way of presenting content, and View options are the parameters that shape how that presentation is experienced.