... to support more fine-grained commenting and collaboration.
#standardSQL | |
# Gatsby Core Web Vitals performance | |
CREATE TEMP FUNCTION IS_GOOD (good FLOAT64, needs_improvement FLOAT64, poor FLOAT64) RETURNS BOOL AS ( | |
good / (good + needs_improvement + poor) >= 0.75 | |
); | |
CREATE TEMP FUNCTION IS_NON_ZERO (good FLOAT64, needs_improvement FLOAT64, poor FLOAT64) RETURNS BOOL AS ( | |
good + needs_improvement + poor > 0 | |
); |
<!DOCTYPE html> | |
<html> | |
<head> | |
<title>Hello React</title> | |
<link rel="stylesheet" href="base.css" /> | |
<script src="http://fb.me/react-0.11.0.js"></script> | |
<script src="http://fb.me/JSXTransformer-0.11.0.js"></script> | |
<script src="channel/bcsocket.js"></script> | |
<script src="share.uncompressed.js"></script> | |
<script src="http://cdnjs.cloudflare.com/ajax/libs/showdown/0.3.1/showdown.min.js"></script> |
According to this gist, the modules break-out session at TC39 (a subset of the larger committee) decided to remove the
module x from "y";
#Composition is the Goal
I see several discussions now that vacillate around on encapsulation qualities of Shadow DOM and the flavors thereof. It's all my fault. I stuck encapsulation into the problem statement of the spec. I even glued the somewhat irrelevant term functional encapsulation on top of it. What a dork.
It was a couple of years ago, when one of my colleagues read the spec and noted: "Dude, it's like your story and whatever, but the way you tell it, Shadow DOM is not about encapsulation. It's about composition". The world went blank around me. I was blinded by insight.
My hipster colleague was right, of course. Encapsulation is just a tool. Composition is the goal.
This is why the people who'd never used Shadow DOM in real life get really hung up on the details of encapsulation, while those who actually use Shadow DOM stare at them quizzically.
When called, the register method must run these steps:
ENVIRONMENT
, the unit of related similar-origin browsing contextsDOCUMENT
, the context object of the methodNAME
, the custom element name of the element being registeredFUNCTION
, the custom element constructor function, optional
Install python-all-dev | |
emscripten/system/include/net/netinet/in.h | |
Add the following lines (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/arpa/inet.h.html) | |
#define INET_ADDRSTRLEN (16) | |
#define INET6_ADDRSTRLEN (48) | |
nanohttp.c |
var fallbacks = {} | |
, networks = {} | |
, cacheName = "OldSchoolAppCache" | |
, settings = {} | |
; | |
this.onmessage = function (e) { | |
var msg = e.data; | |
if (msg.type && msg.type === "manifest") { | |
var lines = msg.manifest.split(/\n+/) |
I’ve been having a play around with Mutation Observers this morning, trying to work out when notifications happen and what happens when removing a node that was just added.
If you’re unfamiliar with Mutation Observers, they let you receive notifications when an element, or elements, have been modified in a particular way (here's an intro to Mutation Observers from Mozilla).
Consider this: