Discover gists

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?."

Defining a scoping inner-boundary in CSS

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.

Generic web component HMR

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.

WTF is "x-layout", "Layout" and "filename"

General

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.

Forms

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.

withRehydration

This is a Skate mixin for serialising and rehydrating props and state for a component. Essentially it will apply JSON encoded attributes for props and state after rendering on the server. When rendered on the client, it then takes those attributes and decodes them as props, essentially rehydrating the component state.

Notes

The didMount callback is specific to Skate and is called after the component is connected.
The didRender callback is specific to Skate and is called after the component renders.

Declarative / composed Shadow DOM

This is a light proposal for Shadow DOM (no pun intended). The purpose of this proposal is to flesh out how we can take the current state of Shadow DOM and allow certain aspects of it to be used separately and composed together. The goals are:

Being able to use CSS encapsulation separately from DOM encapsulation (SSR is one beneficiary of this)
Being able to enable DOM encapsulation on a previously CSS-only encapsulated node (rehydration)
Maintaining backward compatibility

	"use strict";

	(function () {
	var xSizeEls = [],
	custom = {
	width: {},
	height: {}
	},
	breakpoints = {
	width: {

	com.android.bips
	com.android.bookmarkprovider
	com.android.printspooler
	com.android.providers.partnerbookmarks
	com.android.stk
	com.android.traceur
	com.bsp.catchlog
	com.facebook.appmanager
	com.facebook.services
	com.facebook.system

	function wrap(func) {
	return function(value) {
	try {
	return func(value);
	} catch (e) {
	console.error(e);
	throw new Error(e);
	}
	};
	}

	import { autorun, toJS } from 'mobx';
	import { props } from 'skatejs';

	export const withObserver = (Base = HTMLElement) =>
	class extends Base {
	constructor() {
	super();
	const { stores } = this;

	// This dynamically adds props post construction, so this happens for every instance that is created. One way to