css-chain dev challenges diary

[sashafirsov]

The thoughts around the project.

Shadow DOM vs light DOM

css-chain meant to support as classic web components with shadow DOM as usual HTML within/out of web component.
Method $( ...arr ){ return $( this.shadowRoot || this ).$(...arr); } would work in both.

Slots. Shadow DOM vs light DOM tests

where to get the complete SLOT coverage test set?

The slots manipulation by cs-chain in light dom should produce the same result as in shadow DOM as in light DOM. But what is the complete use cases set? I expected to see its coverage in web components polyfill, but could not find. The Chromium sources do have some:
https://github.com/chromium/chromium/blob/main/third_party/blink/web_tests/external/wpt/shadow-dom/slots.html

slotted-element API

has a gentleman set of operations and unit tests for them. css-chain-test would adopt those.

[sashafirsov]

slots-light-vs-shadow.html design

• sections would be cloned from blink tests ^^.
• template content would be cloned and appended to its container by
  • light dom init routine which would utilize initLightDOM( template, slotParams )
  • shadow dom init routine from blink tests createTestTree()
• both clones tested by
  • blink test case code
  • innerHTML and innerText taken by CssChain match for both clones
  • clones DOM match
    Visually container would have 3 sections rendered: original, light DOM, shadow DOM.

[sashafirsov]

unit tests match to slots-light-vs-shadow.html

TBD

[renoirb]

👋 This is a comment in lieu of an email :)

I wanted to say hi! I'll spend soe more time reading this, there's cool stuff! Are you using this code in production?

I have some code stashed (1, 2, 3, and some more here) around related to slot management and other DOM things like extracting slot assigned children, adding a className when slot is empty or not, etc. But before organizing my snippets I wanted to see what others are doing. I found this nice, it reminds some of what lit does (4, 5), and wanted to see where you're going.

Anyway. Hi!

[sashafirsov]

@renoirb , this code is not yet in production , I have created it to support of slotted-element which is in production. slotted-element would be upgraded with css-chain as last has full coverage for templates/slots from browser sources unit tests. As far as I am aware, css-chain is most compliant implementation of light dom with slots and templates.

[renoirb]

Random thought. What's cool with slotted-element is that it matches well with the idea we had with ESI, and what's documented in micro-frontends (for example; asset loading, "fragments" and composition) so we can "compose" things together. When it's an URL with HTML, the contract is simpler than having to expose an ESM module over HTTP (e.g. https://example.org/packages/team-a/v1.1.1/main.mjs), so we avoid to have to deal with a loader such as WebPack.

I might experiment with slotted-element and event propagation in its internal DOM tree.

[sashafirsov]

@renoirb, slotted-element is a middle dot in a web 3.0 toolchain. The micro-frontends is just a UI/frontend part of microapplication concept. This UI tier could be implemented by html include, slotted-element, IFRAME, or microapplication container.

While the slotted-element helps to load remote context/data, it is not self-sufficient to be presented as generic micro-application UI. It would require extending of own implementation for particular microapplication. Once the slotted-element would adopt TypeScript and published with compiled binaries, my focus would be back on microapplication container, this time of commercial quality. It would be based on embed-page but capable of running all major frameworks content from Angular to React. The compatibilities of web components from different vendors on same page is a bit of challenge for now, would phase Lit for later.

emebed-page (a microapplication container POC) already includes the concept of scriptlet which you mentioned, and of course CDN based loader. Pairing with package manager and loader also planned so WebPack would not be needed.

[sashafirsov]

Not much visible, but making template() be shadow DOM compatible on each test been quite challenging. I was able to penetrate the most comprehensive visual test from Chromium. Hopefully it would be sufficient to match shadow DOM based site template.

Unfortunately not all API unit tests from Chromium have passed due to incomplete match of slots computation. It does not prevent the visual pass in https://unpkg.com/css-chain-test@1.1.7/dist/slots-light-vs-shadow.html

Leaving API compatibility on unit tests in todo for now. The light-dom-element based site template has higher priority.

[sashafirsov]

It is handy to have visual and unit tests together. In slots-light-vs-shadow.html there visual and initialization code for shadow and light DOM comparison followed by unit tests which meant to be run by @web/test-runner-mocha.

The test is 50% complete and commented out in test config for now. Since visual match is 100%, the API match is minor and phased out. assignedNodes is not overridden in light DOM and substituted by surrogate CssChainAssignedNodes property for now.