Proof of concept / strategy decision: Complete isolation / Shadow DOM everywhere vs slots.

[damontgomery]

Do we want our web components to have no styles coming from outside them?

Web components already isolate styles from going from the web component to the light DOM.

The various parts of the web components do not fully isolate styles from coming from the light DOM.

• Some text based styles like color and font are inherited from the light DOM
  • https://lamplightdev.com/blog/2019/03/26/why-is-my-web-component-inheriting-styles/
• Slots use light DOM styles
• Some web component (base element) styles can be overwritten by light DOM styles
• Nested elements in the shadow DOM are less easily customized from the light DOM
  • (may be a misconception on my (Dan's) part)
• How do we want to handle isolation of styles coming INTO the web component?
• Should the component have complete control over all the markup inside of it?
• Should the light DOM have control over some of the styles?

Notes

Some posible solutions:

• Construct a shadow DOM structure that mimics the slotted components so it can be styled more easily
• Use attributes to populate the shadow DOM, such as HTML in a string or a JSON object
• Move all the components into the shadow DOM, removing them from the light DOM

Some challenges with those solutions:

• How does a developer access / update content in a slot if that slot has been removed?
• Shadow DOM elements are not in the light DOM and this has it's own challenges such as form inputs and focus
  • See Proof of concept / strategy decision: Form inputs #56
  • See Proof of concept / strategy decision: Extend or wrap built in elements. #59

[damontgomery]

::shadow pseudo selector used to be available to style shadom DOM from light DOM, but it was removed in ~2017 from chrome.

https://www.w3.org/TR/css-scoping-1/#shadow-pseudoelement

[damontgomery]

I remember reading that you could override styles in shadow DOM elements if you really wanted, but I can't find this article any more. There used to be a way (as linked above), so maybe the article was out of date or I misunderstood.

If we want to prevent the text-based cascading styles, we can reset them in the web component styles. Example https://developers.google.com/web/fundamentals/web-components/shadowdom#reset.

If we want to allow partial overriding, I think the part feature can be used: https://developer.mozilla.org/en-US/docs/Web/CSS/::part.

[damontgomery]

On an internal project, we have been using slots for content and properties / attributes for configuration when we can. This has worked pretty well.

When we have issues with styling in a single component, such as facts in an infographic, we make a separate component.

example-infographic and example-fact or example-infographic-fact.

This is a little work, but it's honestly not that much and the components themselves are pretty simple.

We've used this pattern for mostly menus, pager, slides, and infographic.

In Storybook, we put them in a subcomponents folder and they are more or less hidden.

The exception so far to this rule is form elements like checkboxes that we have parsed and re-created in the shadow DOM. Otherwise we try to leave the light DOM alone.

Somewhat related, I've tried to stop using the default slot whenever possible. It is vague and we typically end up with multiple slots. Knowing which unlabled slot is what is confusing. So, we give them all names / labels.