Subchapter 1.37
references/editor-react-component/BROWSER-SUPPORT.mdMarkdown3 KBView on GitHub
Which CSS features and DOM APIs an Editor React Component may use. This is about support in the visitor’s browser, a separate question from whether an API exists during server rendering.
Use only features at Baseline “Widely Available”, or ones that fall back to it — supported for 30+ months in every browser Wix supports: Chrome (desktop + Android), Edge, Firefox (desktop + Android), Safari (macOS + iOS/iPadOS).
A fallback must genuinely degrade rather than break: the unsupported path still has to render a usable component.
These rules resolve nearly everything. Stop at the first step that answers:
@property in your
instructions authorizes it, a general endorsement of modern CSS authorizes
nothing. A feature named only in the user’s request is not pre-authorized;
run the steps below, then the insist protocol.Search only when it earns the cost — the user asks about support directly, or the feature is central enough that deny-and-offer would waste a real round trip. Prefer fetching an MDN or caniuse page over driving a browser.
Standing exception: @property is always fine for design tokens, generated or
hand-written — rewriting a token registration, or warning about one, breaks the
component.
Feels new, is not — run the arithmetic, not the reputation: :has(),
@container size queries, subgrid, color-mix(), inert,
Array.prototype.toSorted.
@supports for CSS, CSS.supports() or a
capability check for JS.