search

BryanWilhite / songhay-web-components

planting small shadow-tree seeds 🌱👁 and watching them grow in the manner of 🦉 the living standard
MIT License
0 stars 0 forks source link

there is no need to ‘protect’ the shadow DOM from light-DOM CSS #14

Closed BryanWilhite closed 4 years ago

BryanWilhite commented 4 years ago

the reason why i have no default CSS settings for rx-input-autocomplete was based on the incorrect assumption that light-DOM CSS styling might need to cascade down

Web Component CSS styling cannot be done from the document at all?

Document styles can affect:

  • shadow host (as it lives in the outer document)
  • slotted elements and their contents (as that’s also in the outer document)

https://javascript.info/shadow-dom-style#summary

https://developer.mozilla.org/en-US/docs/Web/CSS/:host()

This CSS-Tricks article shows step by step that the answer is yes:

https://css-tricks.com/styling-a-web-component/

we’ve totally lost the global styling. The Shadow DOM boundary (shadow root) prevents styling coming in or going out (sorta like an iframe)

BryanWilhite commented 4 years ago

additionally these CSS revelations imply a system must be put in place to address normalizing shadow-DOM CSS:

BryanWilhite commented 4 years ago
BryanWilhite commented 4 years ago

ah, this is quite a serious oversight: i need to review my entire configurable CSS strategy

:book: https://lit-element.polymer-project.org/guide/styles

i am pretty much using unsafe (older) CSS patterns like this:

const cssWidthAndZIndexStyleBlock = html`
    <style>
        :host div {
            width: ${this.cssWidth};
            z-index: ${this.cssZIndexBase + 1};
        }
        :host div > ul {
            z-index: ${this.cssZIndexBase + 2};
        }
    </style>`;

because cssWidth is just a string---which is unsafe

Use CSS variables and custom properties to make styles that can be configured at runtime

this sample is clearly showing me that CSS variables can penetrate the shadow DOM: https://stackblitz.com/edit/lit-element-example-sncrr7?file=index.html

<!doctype html>
<html>
  <head>
    <style>
      :root {
        --global-color: red;
      }
    </style>

    <script src="./node_modules/@webcomponents/webcomponentsjs/custom-elements-es5-adapter.js"></script>
    <script src="./node_modules/@webcomponents/webcomponentsjs/webcomponents-bundle.js"></script>

  </head>
  <body>
    <my-element></my-element>
  </body>
</html>

this is great news but forces me to consider dropping the ability to enter arbitrary CSS (composing css and html assuming this is possible) or confusing end users with two different CSS customization systems

BryanWilhite commented 4 years ago

the ‘mouse-based story of selecting items’ aforementioned leads me to question the need for handling the blur event which occurs when clicking on a Suggestion (unlike the use of the up/down arrow keys which keeps focus)

the blur handler is only needed when suggestions are displayed and the mouse clicks away (apparently abandoning Suggestion selection)