CSS and component styling

Use CSS for presentation that is not covered by a component’s Styles controls. This page retains every selector and the tooltip example from the v8 CSS guide, with v9 source selection and Shadow DOM guidance.

Choose the right CSS source

1. Select the component in the App tree.
2. Open Code and choose the relevant entry under CSS.
3. For content from a template, choose that template’s CSS source.
4. For App-wide custom CSS, select App → Code → CSS → styles.

CSS sources require the Code editor module and applicable editing access. They are retained in the current draft, independently of the source picker’s selected document. Autosave does not publish them.

Template CSS is associated with the selected template for editing, but it is not automatically rewritten into selectors limited to that template. The runtime combines template CSS into a stylesheet. Give custom content distinct classes when a rule should apply only to it.

Built-in CSS classes

The following seven classes were documented in v8 and remain useful in v9. Their effect depends on where the element and the stylesheet are mounted.

Tooltip: .mapsvg-tooltip

Targets a Tooltip container:

.mapsvg-tooltip {
  color: red;
}

This is the original v8 example: make tooltip text red. Place it in the applicable MapSVG CSS source rather than assuming a WordPress theme stylesheet can reach every Tooltip root.

Popover: .mapsvg-popover

.mapsvg-popover {
  border-radius: 8px;
}

Details View: .mapsvg-details-container

.mapsvg-details-container {
  background-color: #ffffff;
}

The selector describes the rendered container. It does not change which Details instance a click action opens; the current Details interaction limitation remains separate.

Directory item: .mapsvg-directory-item

.mapsvg-directory-item {
  padding: 12px;
}

The Directory template must retain the appropriate row class if you replace its markup.

Filters: .mapsvg-filters-wrap

.mapsvg-filters-wrap {
  background-color: #f5f5f5;
}

Filter behavior and form fields are configured separately through Filters settings.

Region label: .mapsvg-region-label

.mapsvg-region-label {
  font-size: 12px;
}

Marker label: .mapsvg-marker-label

.mapsvg-marker-label {
  padding: 3px 5px;
}

Label CSS styles an existing label; it does not enable labels or supply their template content by itself.

Style your own template markup

Add a unique class in the HTML source:

<div class="office-summary">
  <h3>{{title}}</h3>
  <p>{{description}}</p>
</div>

Then put this in the associated CSS source:

.office-summary h3 {
  margin: 0 0 0.5rem;
  color: #1274b7;
}

.office-summary img {
  max-width: 100%;
  height: auto;
}

This avoids changing every heading or image in the App. A class selector also works when the same template renders several instances.

Shadow DOM, iframes, and selector scope

Some MapSVG views use their own Shadow Roots. A theme’s document-level selector cannot directly select elements inside a Shadow Root, and a selector in one Shadow Root cannot cross into another. Inherited values can still affect content; use the component’s styling controls and its applicable MapSVG Code source for direct rules.

Similarly, the editor preview is an iframe, and shortcode/post helpers can create additional iframes. A stylesheet in the outer WordPress page does not automatically style a separate iframe document. Inspect the element’s actual root when a correct-looking selector has no effect.

MapSVG supports %id% substitution in custom CSS. A rule such as #mapsvg-map-%id% .mapsvg-region-label is converted to the App’s map ID. Use that pattern only where that ancestor is actually in the same DOM root as the label. Substitution does not make a selector cross a Shadow Root boundary. A map ID also does not distinguish two embeds of the same App; do not rely on it as a unique per-embed selector.

Prefer a unique template class when you do not need a map-host ancestor. Use built-in Styles controls for supported fill, border, size, spacing, and mobile options before layering broad overrides on top.

Test the actual rendered result

Check hover/selected states, missing optional content, long text, images, and Desktop/Tablet/Mobile layouts. If a style does not apply, inspect the DOM root, selector match, inherited rules, and specificity before adding !important.

Use Preview and a real WordPress page to check the frontend result. Publish the draft to release the configuration; changing a stylesheet in an unsynchronized draft does not update public visitors.