Why does Ignition Perspective table filter ignore margin-right?

Scope, Terms, and the Elements Involved

This applies to the Ignition Perspective Table component. The problem was reported on Ignition 8.1.41. The same selectors behaved as expected on 8.1.20, which means the filter DOM structure did not change in a way that matters between those releases. The symptom: padding and margin apply on the top, bottom, and left of the table filter, but a right margin has no visible effect. Table rows show the same behavior.

The terms below keep one meaning throughout:

• Table filter: the search bar Perspective renders above the table header when filtering is enabled. Its wrapper carries the class tableFilter and sits inside .table-container.
• Filter results: the separate div inside the filter that shows the match count. Its class is filterResults, and it is a sibling of the text input.
• Row group: the per-row wrapper in the table body, selected by .t .tr-group.
• Theme: the Perspective theme CSS files that set default sizes, including the 100% width on row groups.

Check 1: Open the session in Chrome, open DevTools, and inspect the filter bar. Expect a .tableFilter element inside .table-container, with the input and a .filterResults div as children. If the class names differ, your build has a different DOM, and every selector below needs to be re-derived from the inspector.

Width, Margin, and the Over-Constrained Box

Right spacing disappears because of the element's width, not because of CSS precedence. For a block box in normal flow, the horizontal sizes must add up to the width of the containing block: left margin, left border, left padding, width, right padding, right border, and right margin. When width is fixed at 100% and you add a margin, the equation is over-constrained. In a left-to-right layout, the browser resolves this by discarding the declared right margin. The computed style still reports the margin, but the layout does not use it.

Flex children fail in a similar way. A child sized to 100% plus a right margin overflows the parent by the size of the margin. Any overflow clipping then cuts off the right edge, which on a table row means the last column's content.

This explains the one-sided symptom:

• Vertical margins and padding take no part in the horizontal equation, so they always render.
• A left margin shifts the whole box to the right. The excess is pushed off the right edge, so the left spacing appears while the right edge stays flush or clipped.
• A right margin is the one term the browser drops or pushes out of view.

This also explains why !important does nothing here. marginRight: 5px !important in the component style, or margin-right with !important added to the theme files in DevTools, only wins the cascade. The margin was already winning. Inline styles outrank theme rules even without !important. The layout still discards the margin because the width leaves no room for it. The fix is to change the width.

Check 2: In DevTools, select the filter wrapper and open the Computed tab's box-model diagram. For the broken state, expect the content width to equal the container width and the right margin to render as zero-width or fall outside the container outline. Record the width value; it is the baseline for Check 3.

Filter Width Set to Auto

With width: auto, a block box takes the space left after its margins, padding, and borders. The equation is no longer over-constrained, and the right margin is kept. This is the change that fixed the filter.

1. In the Designer, select the Table and open the filter's style object in the Property Editor.
2. Add a width style property and set it to auto.
3. Add marginRight with the spacing you want, for example 5px. Leave out !important; it is not needed once the width is correct.
4. Save, then reload the session in the browser. Designer preview and a live session can apply theme CSS differently, so verify in the browser.

Check 3: Inspect the filter wrapper again. Expect the content width to be smaller than the Check 2 baseline by the right margin (plus any left margin), and expect a visible gap between the filter's right edge and the table container. If the width is unchanged, another rule is setting a fixed width. The Styles pane lists it with its source file; scope an override to that rule.

Filter Results Collapse

Empty space on the right of the filter bar can also come from the filter results div. It is its own element, and its flex sizing can reserve space even when it shows nothing useful. To collapse it to its content size, add this to the project stylesheet or test it first in DevTools:

.table-container .tableFilter .filterResults {
  flex: 0 0 auto !important;
  margin-right: 5px !important;
}

The shorthand flex: 0 0 auto means: no growth, no shrink, and a basis equal to the content size. The div then occupies only what its text needs. The !important is justified here because the rule has to override flex values set by the theme on an element you cannot style inline.

One side effect: when the results div collapses to zero width, its margin-right still applies, leaving a 5 px strip with nothing in it. You have two options:

Check 4: Type a filter string that matches rows, then clear it. Expect the results div width in the box model to follow its text content, and expect no growth region to the right of the input. If a gap remains when the results div is at 0 width, trace it to margin-right on .filterResults and choose one of the options in the table.

Row Group Width Override

Rows fail for the same reason, but the fix goes in a different place. The theme sets row groups to 100% width. Rows are generated at runtime, one element per record, so the component's style properties cannot set an inline width on each row. The override has to go in a stylesheet, and it needs !important to beat the theme rule:

.t .tr-group {
  width: auto !important;
}

After this change, a right margin on the rows is kept, and content on the right side of the row is no longer cut off.

Turning virtualized off on the Table fixes some row-layout problems, because virtualized rendering sizes and positions rows differently. It does not fix this one: the theme's 100% width applies whether virtualization is on or off. Leave virtualization as the dataset requires. Turning it off on large datasets costs rendering performance and does not help here.

Check 5: Apply the row margin, reload the session, and scroll to the last visible column. Expect the full cell text of the right-most column, followed by the margin gap before the container edge. In the box model, expect row width equal to the container width minus the horizontal margins. A row width still equal to the full container width means the theme rule is still winning; check the Styles pane for a struck-through width on your rule.

Selector Scoping and Upgrade Exposure

The selectors above are global. Every Perspective Table in the project gets the collapsed results div and the auto-width rows. Treat that as a design decision, not a default:

• To limit the change to specific tables, add a style class to those Table components and prefix the rules with it, so they match only inside that class.
• Keep the rules in the project stylesheet, not in edits to the shipped theme files. Theme edits made in DevTools are only for diagnosis and are lost on reload. Edits to installed theme files make the project depend on a modified gateway and can be overwritten when the theme is updated.
• Classes such as tableFilter, filterResults, and tr-group are internal DOM names, not a documented styling interface. They matched on both 8.1.20 and 8.1.41. After any gateway upgrade, repeat Check 1 before assuming the rules still apply.

Check 6: Open a view with a Table that should keep default styling. Expect its filter results div and rows to keep the theme sizing. If they changed, the rules are unscoped and need the class prefix.

End-to-End Verification

Run these in a live browser session, not in the Designer preview, with the gateway's production theme selected.

1. Filter width: Inspect .tableFilter. Expect the computed width to be auto-derived: container width minus the horizontal margins and padding.
2. Filter right margin: Expect a visible gap of the configured size, for example 5 px, between the filter's right edge and the container.
3. Results div: With matches shown, expect .filterResults to be only as wide as its text. With the filter cleared, expect either no leftover gap (parent-padding approach) or exactly the configured margin (margin approach).
4. Row width: Inspect any .tr-group. Expect the computed width to be less than the container by the row margin, with the rule width: auto !important shown as active.
5. Right-most column: Expect the full cell contents of the last column with no clipping, both at the top of the table and after scrolling.
6. Virtualization state: Toggle virtualized once. Expect identical row width and margin in both states, which confirms the fix does not depend on it. Then restore the setting the dataset needs.
7. Scope: Open an unrelated Table. Expect default theme sizing unless it carries the scoping class.

FAQ