DEV Community

Discussion on: Beyond the polyfills: how Web Components affect us today?

View post
Collapse
 
smallscript profile image
David Simmons • • Edited

:host-context
Is uniquely valuable in allowing a web-component design to remain encapsulated. This begins to show up more visibly as one really builds an application model and framework using components; as one might classically have done in MVC etc APP frameworks that pre-date the web. (And I worked on many, including, ironically, those that Apple became famous for in the late 80's and 1990's).

Today, Apple/Safari seem to adhere to a notion that you should not or cannot build native equivalent or better apps using web technologies. Or, perhaps, it is just not in their financial interests with the risk it poses to retaining the App Store iOS market share foundation [making them behave like Microsoft of yesteryear].

Whatever the technical or non-technical reasons, lacking it, one has to effectively mine the transitive closure of all web-components being utilized and pull out an equivalent ":host-context" and write it into a global-style sheet. Which defeats the purpose of having #shadow-root support styles for encapsulation; and further pushes the compiler-linker style work-effort demands of webpack transpiling of monolithic web-properties.

As in:

<body sa="/main/">
<sh-main>
  #shadow-root
  <style>
  :host {display:none;}
  :host-context(body[sa*="/main/"]) {display:flex;}
  </style>
</sh-main>
</body>
Enter fullscreen mode Exit fullscreen mode

Allows the entirety of <sh-main> to be defined in a self contained mjs package, etc.

Without it, one (or a compile-link webpack toolset) has to add a global style for every web-component using this technique:

<style>
  /* -- ANTI-ENCAPSULATION POOH REQUIRED -- */
  sh-main {display:none;}
  body[sa*="/main/"] sh-main {display:flex;}
</style>
Enter fullscreen mode Exit fullscreen mode

Pushing all the heavy lifting into the transpilers webpack compiler-linker side of things is retro web behavior and not forward looking to a just-in-time dynamic compositional componentized architecture.

I.e., a class-like path selector model is unable scale without :host-context once one uses this encapsulation approach to build things like class AppModels for cmd-buttons on menu-bars etc to simplify enable/disable/visibility designs. A classic approach from MVC frameworks starting in the late 1980's and after.

What may not be obvious, is that with the above type of technique of using that "sa" attribute as a path list (similar to using "class"), one can completely manage SPA view layering, modal-overlays, and cmd-btns trivially by merely listing them in three distinct body attributes. One for view-paths, one for modal-overlays, and one for enabled/disabled but visible icon/cmds.

If it is "technically challenging" for Safari et. al., to implement; that is fair. But the evolution of browsers and related technology has always been a road of technical challenges. What is not "ok" is not being "transparent" about the reasons for not doing it and instead "deflecting" because of turf-competition attitudes or worse, lack of technical awareness as to the bad web-design issues it promulgates.

If it is because Apple et. al., have the opinion that #shadow-root styles have some deep-flaws due to the lack of sharing model between instances of a given class of web-component, then that is what should both be said, focused on, and addressed. See Constructable StyleSheets.