Gathering detailed insights and metrics for @webcomponents/shadycss
Gathering detailed insights and metrics for @webcomponents/shadycss
Gathering detailed insights and metrics for @webcomponents/shadycss
Gathering detailed insights and metrics for @webcomponents/shadycss
npm install @webcomponents/shadycss
Typescript
Module System
Node Version
NPM Version
99.9
Supply Chain
100
Quality
82.2
Maintenance
100
Vulnerability
100
License
HTML (61.96%)
JavaScript (28.06%)
TypeScript (9.77%)
CSS (0.21%)
Total Downloads
23,051,877
Last Day
5,434
Last Week
92,828
Last Month
552,037
Last Year
5,873,149
1,151 Stars
4,268 Commits
165 Forks
35 Watching
67 Branches
118 Contributors
Latest Version
1.11.2
Package Id
@webcomponents/shadycss@1.11.2
Unpacked Size
481.80 kB
Size
132.38 kB
File Count
40
NPM Version
9.5.1
Node Version
19.8.1
Publised On
30 Mar 2023
Cumulative downloads
Total Downloads
Last day
-79%
5,434
Compared to previous day
Last week
-31.2%
92,828
Compared to previous week
Last month
-4.1%
552,037
Compared to previous month
Last year
26.5%
5,873,149
Compared to previous year
ShadyCSS provides a library to simulate ShadowDOM style encapsulation (ScopingShim), a shim for the proposed CSS mixin @apply
syntax (ApplyShim), and a library to integrate document-level stylesheets with both of the former libraries (CustomStyleInterface).
ShadyCSS requires support for the <template>
element, ShadowDOM, MutationObserver, Promise, and Object.assign
ShadyCSS can be used by loading the ScopingShim, ApplyShim, CustomStyleInterface, or any combination of those.
The most-supported loading order is:
Import the @webcomponents/shadycss
module to interact with ShadyCSS. Note this
module does not load the polyfill, instead this module is used to interact
with ShadyCSS if the polyfill is loaded, and is safe to use whether or not
ShadyCSS is loaded.
There is also a legacy global API exposed on window.ShadyCSS
. Prefer use of
the @webcomponents/shadycss
module described above.
1ShadyCSS = {
2 prepareTemplate(templateElement, elementName, elementExtension) {},
3 styleElement(element) {},
4 styleSubtree(element, overrideProperties) {},
5 styleDocument(overrideProperties) {},
6 getComputedStyleValue(element, propertyName) {},
7 nativeCss: Boolean,
8 nativeShadow: Boolean,
9};
ScopingShim provides simulated ShadyDOM style encapsulation, and a shim for CSS Custom Properties.
ScopingShim works by rewriting style contents and transforming selectors to enforce scoping. Additionally, if CSS Custom Properties is not detected, ScopingShim will replace CSS Custom Property usage with realized values.
Here's an example of a custom element when Scoping Shim is not needed.
1<my-element> 2 <!-- shadow-root --> 3 <style> 4 :host { 5 display: block; 6 } 7 #container slot::slotted(*) { 8 color: gray; 9 } 10 #foo { 11 color: black; 12 } 13 </style> 14 <div id="foo">Shadow</div> 15 <div id="container"> 16 <slot> 17 <!-- span distributed here --> 18 </slot> 19 </div> 20 <!-- /shadow-root --> 21 <span>Light</span> 22</my-element>
becomes:
1<style scope="my-element"> 2 my-element { 3 display: block; 4 } 5 my-element#container > * { 6 color: gray; 7 } 8 my-element#foo { 9 color: black; 10 } 11</style> 12<my-element> 13 <div id="foo">Shadow</div> 14 <div id="container"> 15 <span>Light</span> 16 </div> 17</my-element>
ApplyShim provides a shim for the @apply
syntax proposed at https://tabatkins.github.io/specs/css-apply-rule/, which expands the definition CSS Custom Properties to include objects that can be applied as a block.
This is done by transforming the block definition into a set of CSS Custom Properties, and replacing uses of @apply
with consumption of those custom properties.
The @apply
proposal has been abandoned in favor of the ::part/::theme Shadow Parts spec. Therefore, the ApplyShim library is deprecated and provided only for backwards compatibility. Support going forward will be limited to critical bug fixes.
Mixin properties cannot be modified at runtime.
Nested mixins are not supported.
Shorthand properties are not expanded and may conflict with more explicit properties. Whenever shorthand notations are used in conjunction with their expanded forms in @apply
, depending in the order of usage of the mixins, properties can be overridden. This means that using both background-color: green;
and background: red;
in two separate CSS selectors
can result in background-color: transparent
in the selector that background: red;
is specified.
1#nonexistent { 2 --my-mixin: { 3 background: red; 4 } 5}
with an element style definition of
1:host { 2 display: block; 3 background-color: green; 4 @apply (--my-mixin); 5}
results in the background being transparent
, as an empty background
definition replaces
the @apply
definition.
For this reason, we recommend avoiding shorthand properties.
Here we define a block called --mixin
at the document level, and apply that block to my-element
somewhere in the page.
1html { 2 --mixin: { 3 border: 2px solid black; 4 background-color: green; 5 } 6} 7 8my-element { 9 border: 1px dotted orange; 10 @apply --mixin; 11}
becomes:
1html { 2 --mixin_-_border: 2px solid black; 3 --mixin_-_background-color: green; 4} 5 6my-element { 7 border: var(--mixin_-_border, 1px dotted orange); 8 background-color: var(--mixin_-_background-color); 9}
CustomStyleInterface provides API to process <style>
elements that are not inside of
ShadowRoots, and simulate upper-boundary style scoping for ShadyDOM.
To add document-level styles to ShadyCSS, one can call CustomStyleInterface.addCustomStyle(styleElement)
or CustomStyleInterface.addCustomStyle({getStyle: () => styleElement})
An example usage of the document-level styling api can be found in examples/document-style-lib.js
, and another example that uses a custom element wrapper can be found in examples/custom-style-element.js
1<style class="document-style"> 2 html { 3 --content-color: brown; 4 } 5</style> 6<my-element>This text will be brown!</my-element> 7<script> 8 CustomStyleInterface.addCustomStyle( 9 document.querySelector('style.document-style') 10 ); 11</script>
Another example with a wrapper <custom-style>
element
1<custom-style> 2 <style> 3 html { 4 --content-color: brown; 5 } 6 </style> 7</custom-style> 8<script> 9 class CustomStyle extends HTMLElement { 10 constructor() { 11 CustomStyleInterface.addCustomStyle(this); 12 } 13 getStyle() { 14 return this.querySelector('style'); 15 } 16 } 17</script> 18<my-element>This this text will be brown!</my-element>
Another example with a function that produces style elements
1<my-element>This this text will be brown!</my-element> 2<script> 3 CustomStyleInterface.addCustomStyle({ 4 getStyle() { 5 const s = document.createElement('style'); 6 s.textContent = 'html{ --content-color: brown }'; 7 return s; 8 }, 9 }); 10</script>
To use ShadyCSS:
Import the ShadyCSS interface module. (Note that this module does not load the polyfill itself, rather it provides functions for interfacing with ShadyCSS if it is loaded.)
1import * as shadyCss from '@webcomponents/shadycss';
First, call shadyCss.prepareTemplate(template, name)
on a
<template>
element that will be imported into a shadowRoot
.
When the element instance is connected, call shadyCss.styleElement(element)
.
Create and stamp the element's shadowRoot.
Whenever dynamic updates are required, call shadyCss.styleSubtree(element)
.
If a styling change is made that may affect the whole document, call
shadyCss.styleSubtree(document.documentElement)
.
The following example uses ShadyCSS and ShadyDOM to define a custom element.
1<template id="myElementTemplate"> 2 <style> 3 :host { 4 display: block; 5 padding: 8px; 6 } 7 8 #content { 9 background-color: var(--content-color); 10 } 11 12 .slot-container ::slotted(*) { 13 border: 1px solid steelblue; 14 margin: 4px; 15 } 16 </style> 17 <div id="content">Content</div> 18 <div class="slot-container"> 19 <slot></slot> 20 </div> 21</template> 22<script type="module"> 23 import * as shadyCss from '@webcomponents/shadycss'; 24 25 const myElementTemplate = document.body.querySelector('#myElementTemplate'); 26 shadyCss.prepareTemplate(myElementTemplate, 'my-element'); 27 28 class MyElement extends HTMLElement { 29 connectedCallback() { 30 shadyCSS.styleElement(this); 31 if (!this.shadowRoot) { 32 this.attachShadow({mode: 'open'}); 33 this.shadowRoot.appendChild( 34 document.importNode(myElementTemplate.content, true) 35 ); 36 } 37 } 38 } 39 40 customElements.define('my-element', MyElement); 41</script>
To set the value of a CSS Custom Property imperatively, use the styleSubtree
function from the @webcomponents/shadycss
module. This function supports an
additional argument of an object mapping variable name to value, and works
whether or not ShadyCSS is loaded.
When using ApplyShim, defining new mixins or new values for current mixins imperatively is not supported.
1<my-element id="a">Text</my-element> 2<my-element>Text</my-element> 3 4<script type="module"> 5 import * as shadyCSS from '@webcomponents/shadycss'; 6 7 const el = document.querySelector('my-element#a'); 8 // Set the color of all my-element instances to 'green' 9 shadyCss.styleSubtree(document.documentElement, {'--content-color': 'green'}); 10 // Set the color my-element#a's text to 'red' 11 shadyCss.styleSubtree(el, {'--content-color': 'red'}); 12</script>
You must have a selector for ascendants of the <slot>
element when using the ::slotted
pseudo-element.
You cannot use any selector for the <slot>
element. Rules like .foo .bar::slotted(*)
are not supported.
@apply
Dynamic changes are not automatically applied. If elements change such that they
conditionally match selectors they did not previously,
styleElement(document.documentElement)
must be called.
For a given element's shadowRoot, only 1 value is allowed per custom properties. Properties cannot change from parent to child as they can under native custom properties; they can only change when a shadowRoot boundary is crossed.
To receive a custom property, an element must directly match a selector that defines the property in its host's stylesheet.
<custom-style>
Flash of unstyled contentIf applyStyle
is never called, <custom-style>
elements will process after
HTML Imports have loaded, after the document loads, or after the next paint.
This means that there may be a flash of unstyled content on the first load.
<slot>
Crawling the DOM and updating styles is very expensive, and we found that trying to
update mixins through <slot>
insertion points to be too expensive to justify for both
polyfilled CSS Mixins and polyfilled CSS Custom Properties.
External stylesheets loaded via <link rel="stylesheet">
within a shadow root or
@import
syntax inside a shadow root's stylesheet are not currently shimmed by
the polyfill. This is mainly due to the fact that shimming them would require
a fetch of the stylesheet text that is async cannot be easily coordinated with
the upgrade timing of custom elements using them, making it impossible to avoid
"flash of unstyled content" when running on polyfill.
ShadyCSS mimics the behavior of shadow dom, but it is not able to prevent document
level styling to affect elements inside a shady dom. Global styles defined in
index.html
or any styles not processed by ShadyCSS will affect all elements on the page.
To scope document level styling, the style must be wrapped in the <custom-style>
element
found in Polymer, or use the CustomStyleInterface
library to modify document level styles.
ShadyCSS works by processing a template for a given custom element class. Only the style elements present in that template will be scoped for the custom element's ShadowRoot.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
security policy file detected
Details
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 12/19 approved changesets -- score normalized to 6
Reason
0 commit(s) and 7 issue activity found in the last 90 days -- score normalized to 5
Reason
dependency not pinned by hash detected -- score normalized to 3
Details
Reason
SAST tool is not run on all commits -- score normalized to 1
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
77 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-12-16
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More