Kit-shipped defaults. Merged with the consumer's chromeVisibility map
at resolve time; consumer entries take precedence per id.
Written as literal Rule trees rather than fluent chains so the inputs
each rule depends on are immediately visible. The fluent atoms compile
to the same trees; either form is valid in a VisibilityRules entry.
Gating is written in terms of capabilities, not mode ids. A
capability rule keeps holding when a new mode is added that permits the
same thing; a mode rule has to be found and edited every time. There is
no mode: rule left in this table — the path-edit.* chrome used to be
the exception, on the theory that it's the visual signature of one mode;
see the comment on those rules below for why that was wrong in both
directions and what replaced it.
Chrome that gates on the absence of a capability (the selection
outline, suppressed while an anchor-editing overlay owns the visuals)
uses capability: { not: … } for the same reason.
Kit-shipped defaults. Merged with the consumer's
chromeVisibilitymap at resolve time; consumer entries take precedence per id.Written as literal Rule trees rather than fluent chains so the inputs each rule depends on are immediately visible. The fluent atoms compile to the same trees; either form is valid in a VisibilityRules entry.
Gating is written in terms of capabilities, not mode ids. A capability rule keeps holding when a new mode is added that permits the same thing; a mode rule has to be found and edited every time. There is no
mode:rule left in this table — thepath-edit.*chrome used to be the exception, on the theory that it's the visual signature of one mode; see the comment on those rules below for why that was wrong in both directions and what replaced it.Chrome that gates on the absence of a capability (the selection outline, suppressed while an anchor-editing overlay owns the visuals) uses
capability: { not: … }for the same reason.