Why Does Ignition Perspective Embedded View Show Scrollbars?

Overflow Ownership: View Root vs Embedded View Wrapper

The term overflow here means the CSS overflow property that decides what a browser does with content extending past an element's box: visible draws it, hidden clips it, auto clips it and adds scrollbars on demand. Perspective applies this property at two independent levels, and the confusion in the reported case (Ignition 8.1.11, a symbol view dropped into a coordinate container) comes from treating them as one.

Level one is the view itself. Setting overflow: visible on the view's root container governs the root container element of that view when it is rendered as a page or popup. Level two is the Embedded View component. When a view is placed inside another view, Perspective renders a wrapper element (DOM class view-parent) around the instanced view, and that wrapper carries the component's own style. The wrapper does not read, copy, or inherit anything from the view it instances. Every Perspective component defaults to overflow: auto, so the wrapper clips at the Embedded View's bounds and the browser adds scrollbars the moment any child crosses those bounds. A label deliberately positioned outside the view dimensions (a tag name floating above a valve symbol, for example) is exactly such a child.

This is designed behavior, not a rendering bug. Changing the component default would alter the appearance of every existing project that relies on auto scrollbars, so it is treated as a backwards-breaking change and has not been scheduled for 8.2.0 or 8.3.0.

Check 1: open the browser developer tools on the running session and inspect the scrollbar. Expect the scrolling element to be the view-parent wrapper of the Embedded View, not the root container of the instanced view. If it is the root container, the problem is inside the view and the fixes below do not apply.

Symptom-to-Cause Mapping

Check 2: for the rounding case, select the Embedded View in the designer and compare the view's declared width and height against the component's rendered size in the browser inspector. Expect a difference of less than one pixel; that fraction is enough to trigger the overflow state under auto.

Per-Instance Correction on the Embedded View Component

The fastest fix, and the right one when only a handful of symbols are affected, is to set overflow on the component rather than the view.

1. Select the Embedded View component in the parent view (the coordinate container in the reported case).
2. In the Property Editor, expand the component's style object.
3. Add the property overflow with value visible.
4. Save the project and reload the session.

This is the behavior confirmed in the reported setup: the same view that showed scrollbars renders its out-of-bounds label correctly as soon as the key exists on the instance. The cost is repetition. Every new symbol dropped from the tag browser arrives without the key, which defeats the purpose of drop configuration on a mimic with dozens of instances.

Check 3: reload the session and confirm the label outside the view bounds is drawn and no scrollbar is present on that instance. Then drop a second instance of the same UDT and confirm the scrollbar returns on the new one; this proves the setting is instance-scoped and motivates the container-level fix.

Container-Scoped Correction with a Style Class

The scoped approach targets the view-parent wrapper only inside a chosen container, so symbols dropped anywhere within it get visible overflow automatically while the rest of the project keeps the default. Perspective prefixes style-class names with psc- in the rendered DOM, which is what makes the descendant selector work.

1. Under Perspective Styles, create a style class named childEmbeddedOverflow. Leave its normal properties empty; it exists only as a selector hook.
2. Write the rule that scopes the override to descendants of that class:

.psc-childEmbeddedOverflow .view-parent {
  overflow: visible !important;
}

3. Place the rule using one of the two delivery methods in the next section.
4. Apply the style class childEmbeddedOverflow to the container that holds the embedded symbols (the coordinate container acting as the mimic canvas), not to the individual Embedded Views.
5. Drop a UDT instance into that container and let drop configuration create the Embedded View with no manual edits.

The !important flag is required because the component writes its own inline overflow: auto, and an inline declaration outranks any stylesheet rule that lacks it.

Check 4: inspect a freshly dropped Embedded View inside the classed container. Expect the computed style of its view-parent element to read overflow: visible with the source shown as your rule, while an Embedded View placed outside the container still computes overflow: auto.

Delivery Method: Advanced Stylesheet vs Style-Class Injection

Two mechanisms carry custom CSS into a Perspective session. Pick one; do not run both for the same rule.

Advanced Stylesheet. Current 8.1 releases provide a dedicated stylesheet resource under Perspective Styles. Paste the scoped rule there verbatim. This is the maintainable option: the CSS is readable, versionable, and shows up where the next engineer expects it.

Style-class injection. Older 8.1 builds (8.1.11 predates the stylesheet resource) have no place to type raw CSS, so the rule is smuggled through a style class's background-image value. The style class compiler wraps the value in a property declaration, and the leading and trailing braces close that declaration early and open a fresh rule:

}.psc-childEmbeddedOverflow .view-parent{overflow:visible !important}{

Enter that string as the background-image value of any style class. The class carrying the injection does not need to be applied to a component; its mere existence emits the rule into the session stylesheet. Use a separate class for the injection and a separate class (childEmbeddedOverflow) for the container hook, or combine them; both work because the selector, not the carrying class, decides the scope.

Check 5: in the browser inspector, locate the injected or stylesheet rule in the loaded CSS and confirm it appears exactly once. Expect no duplicate rule; a duplicate indicates both delivery methods are active and one should be removed.

Global Override: When and Why Not

A project-wide rule is a single line:

.view-parent {
  overflow: visible !important;
}

Placed in theme.css or through injection, it flips every Embedded View in every session to visible overflow. It is the wrong practice for anything beyond a throwaway prototype. The !important flag that makes it beat the inline default also makes it unbeatable later: no per-instance overflow: auto or hidden on any Embedded View will take effect again, because inline styles cannot override an !important stylesheet rule. Dashboards that rely on scrolling embedded lists or tables will break silently. Theme file edits also live outside the project export and are lost on gateway upgrade unless the custom theme is managed separately.

If the global form is used anyway, the scoped selector remains the escape hatch: a more specific !important rule applied to a container can restore auto beneath it. That is two layers of override to maintain, which is the argument for starting scoped.

Check 6: if a global rule exists, open any view that contains a scrolling Embedded View (a long alarm list or table wrapper). Expect scrolling to still function. If content bleeds instead, replace the global rule with the scoped version.

Drop Configuration and Component Variants

Drop configuration maps a UDT type to a view and creates a stock Embedded View on drop. There is no field in the drop configuration to preset component style, which is why the instance-level fix cannot be automated today. Two open features address this directly: user-defined component variants in the component palette (an "Overflow Visible" variant of Embedded View saved with overflow: visible already set), and the ability to name a component variant as the drop target for a UDT. Neither requires a backwards-incompatible change, so either can land in any release, but neither is committed for 8.2.0 or 8.3.0. Until then, the container-scoped style class is the mechanism that gives drop configuration the correct default.

Check 7: confirm the mimic container carries the childEmbeddedOverflow class before handing the project to operators. Expect any UDT dragged into it by a later engineer to render with visible overflow without editing the instance.

End-to-End Verification

1. Designer preview. Open the symbol view standalone. Expect the label outside the declared bounds to be drawn; the view root is at overflow: visible.
2. Embedded instance in scoped container. Open the mimic view in preview mode and in a browser session. Expect every Embedded View inside the classed container to show the external label with no scrollbar.
3. Computed style. Inspect one view-parent element inside the container. Expect overflow: visible from your rule, overriding the inline auto.
4. Control instance. Place the same symbol outside the classed container. Expect overflow: auto and scrollbars, proving the scope boundary.
5. Fresh drop. Drag a new UDT instance from the tag browser into the container, save, reload. Expect correct rendering with zero manual property edits.
6. Regression. Open one view that intentionally scrolls an embedded view. Expect scrolling intact; if it is not, a global .view-parent rule is still present and must be removed.

FAQ