Think about how rules are written, applied and work.

In talking about a tree, you have very few basic constructs: Element name, attribute, ancestor/descendant relationships.

You write a CSS selector like .foo bar * bat. These are based on, effectively, element names and attributes (tho there are some 'special' kinds of attributes like ID which is really just an attribute with unusually high specificity and class which is really just an attribute that contains a serialized DOMTokenList). Aside from these the only other thing in your vernacular is "descendant of" or "child of" or some few things about your immediate siblings.

Now, think about when the document is parsing, what does the browser have to do? At some point, it needs to figure out "which rules apply to this element right now" and then make sure that they are applied, in specificity order so that it can figure out what to paint.

Let's imagine that you have a few hundred rules, that's not entirely unusual. Let's imagine that your DOM

This is how great ideas often happen, they fade into view over a long period of time... The challenge for all of us is how do you create environments that allow these ideas to have this kind of long half-life, right? It's hard to go to your boss and say "I have an excellent idea for our organization. It will be useful in 2020 [about a decade at the time of this recording], uh, could you just give me some time to do that?."

Concretely, I want to implement simulated CSS scoping for react-shade. This uses the imperative Shadow DOM APIs, by default, to enable scoping on the client. However, in order to get fully-scoped CSS when using SSR, we need either:

• A declarative API for shadow DOM (closed due to lack of implementer interest), or
• A way to tell CSS to stop selecting elements in slots. So, we'd need to be able to select between an ancestor and a descendant in a given DOM tree.
• ...?

I am currently able to find solutions for :host and :host-context, and can scope stuff to descendants of a shadow root tree, the hard part is just simulating the exclusion of slotted content.

I'm messing around with a generic way to do hot-module-replacement with generic web components whether they be vanilla, or done in a framework like Polymer or Skate.

The idea is that you call hmr(customElementConstructor) in your module files and it will set up the proper hooks.

The const filename should be inserted at build time so that it can remember the original localName of the component for the module.

• Recent F2F meeting: WICG/webcomponents#713. We discussed a lot of this stuff there which I'll link to below. Minutes are linked to at the bottom.

• Super-verbose CodeSandbox showing issues: Shadow DOM and form issues - CodeSandbox. LMK if it doesn’t make sense.
• Related issue: WICG/webcomponents#187.
• Validation discussed at the end of F2F day 1: https://www.w3.org/2018/03/05-webplat-minutes.html.