Override for Shadow DOM Encapsulation

[brianblakely]

Feature Request

Description of Problem:

I have been working on a third-party theme for Perspective and have run into a couple friction points:

1. Not everything I want to style is exposed by Perspective via CSS Variables.
2. Some of the styles which are exposed do not have full CSS compatibility due to the affected elements being encapsulated in Shadow DOM. For example, I cannot pass my own CSS Variables to --d3fc-series variables, as the d3fc plugins are encapsulated and cannot see my variables.

Potential Solutions:

perspective-viewer-datagrid has an undocumented renderTarget property that helps a lot with regular-table styling when it is set to light, before any datagrid components are instantiated. Make this an attribute for perspective-viewer and propagate it to all subcomponents.

This lays the groundwork for encapsulating all subcomponents by default, making them safer while still keeping a back door unlocked for DX. It also doesn't require the whenDefined API on the application's side, which can be vulnerable to race conditions.

[texodus]

Unfortunately this is out-of-scope for OSS Perspective. We chose to render this element in the Shadow DOM because it is encapsulated, so that presentation and functionality are consistent.

Some of the styles which are exposed do not have full CSS compatibility due to the affected elements being encapsulated in Shadow DOM. For example, I cannot pass my own CSS Variables to --d3fc-series variables, as the d3fc plugins are encapsulated and cannot see my variables.

The perspective built-in themes are not magic - they are just CSS variables in an external stylesheet. Please follow the docs, examples and MDN documentation for defining variables. Custom CSS variables are visible in the Chrome dev tools just like any plain CSS variable.

Important note: renderTarget is undocumented for a reason - this API is not stable, nor guaranteed to exist in a future version (hint hint).

[brianblakely]

For clarity, in my experience this can be flaky when, instead of passing a raw value, you use another variable.
--d3fc-series: var(--my-own-color);
But that could very well be an intermittent browser bug or other external issue.

Do you intend to keep Shadow Roots open for the foreseeable future?

[texodus]

I suspect you have an issue with specificity rather than a Chrome bug - IME this is an exceptional claim without evidence. The built-in themes also e.g. inherit) without issues. The Chrome dev tools style tab is very helpful for debugging issues with specificity/inheritance.

Do you intend to keep Shadow Roots open for the foreseeable future?

Shadow roots cannot be actually closed, at least not without playing obfuscation games (you can e.g. monkey patch attachShadow to skip this argument in 3rd party code), so Perspective will use "open" mode. What is more important is the explicit intention - the DOM internals of <perspective-viewer> aren't intended to be stable between versions, nor modified by external rules. Unexpected CSS changes can also break actual functionality, as the drag/drop impl, list virtualization, expression editor, workspace layout, modal/dropdown windows, etc. have JavaScript/getBoundingClientRect() calls which depend on the CSS-applied layout dimensions.

If this explicit intent does not deter you, "closed" would not either.

[brianblakely]

The Chrome dev tools style tab is very helpful for debugging issues with specificity/inheritance.

Indeed. In these cases, it will report that my variables are undefined in PSP’s encapsulated elements, while remaining completely intact in the Light DOM. I suspect it’s an edge case interaction between layers of Shadow DOM and relaying CSS Variables.

If this explicit intent does not deter you, "closed" would not either.

That is a sound point!