domenic

Context: tc39/proposal-set-methods#50

Proposed spec texts

Set.prototype.difference(arg), minimalist

1. If Type(this) is not Object, or this does not have a [[SetData]] internal slot, throw a new TypeError exception.
2. If Type(arg) is not Object, or arg does not have a [[SetData]] internal slot, throw a new TypeError exception.
3. Let diffList be a List containing all elements that are in this.[[SetData]] but are not in arg.[[SetData]], using SameValueZero to determine identity. (Optional: formalize this with a loop that operates on the Lists.)
4. Let newSet be ? OrdinaryCreateFromConstructor(%Set%, "%SetPrototype%", « [[SetData]] »).

domenic

Obtaining a resource from a link element

All [external resource links] have an algorithm to fetch and process the linked resource.

Individual link types may define their own [fetch and process the linked resource] algorithm, which takes the link element el. But if not otherwise stated, they use the following default fetch and process the linked resource algorithm, given el:

1. If el's href attribute's value...
2. ... stuff ...
3. Fetch request. To process response given the response response:
4. Let success be true.

domenic

  <style>
   .status { min-height: 0.6em; font: 1em sans-serif; width: 9em; padding: 0.3em; position: absolute; z-index: 8; right: 0.3em; background: #EEE; color: black; box-shadow: 0 0 3px #999; overflow: hidden; margin: -2em 0 0 0; border-collapse: initial; border-spacing: initial; }
   .status:hover { z-index: 9; }
   .status:focus-within { z-index: 9; }
   .status.wrapped > :not(input) { display: none; }
   .status > input { position: absolute; left: 0; top: 0; width: 1em; height: 1em; border: none; background: transparent; padding: 0; margin: 0; }
   .status > p { font-size: 0.6em; margin: 0; padding: 0; }
   .status > p + p { padding-top: 0.5em; }
   .status > p > strong { margin-left: 1.5em; }
   .status > .support { display: block; }

domenic

// This creates a copy, but does detach the source buffer

const mc = new MessageChannel();

ArrayBuffer.prototype.transfer = function () {
  const result = this.slice();
  mc.port1.postMessage(this, [this]);
  return result;
};

domenic

function curveInArchCoords(col, rows, cols) {
  const mathX = col / cols * 2 * Math.PI;
  const mathY = Math.cos(mathX);
  const archY = (1 + mathY) / 2 * rows;
  return archY;
}

function setFrame(frame, rows, cols, colOffset) {
  for (const i of frame) {
    frame[i] = 0;

domenic

"use strict";

const conversions = require("webidl-conversions");
const utils = require("./utils.js");

const impl = utils.implSymbol;
const HTMLElement = require("./HTMLElement.js");

function HTMLMarqueeElement() {
  throw new TypeError("Illegal constructor");

domenic

<!-- Clean light DOM: -->
<std-list id="list">
  <div class="item">0 - Domenic</div>
  <div class="item">1 - Ojan</div>
  <div class="item">2 - Drew</div>
  <div class="item">3 - Kevin</div>
  <div class="item">4 - Gray</div>
</std-list>

<!-- Via this structure: -->

domenic

A response to http://www.brucelawson.co.uk/2017/editing-the-w3c-html5-spec/

Unfortunately this post contains a lot of inaccuracies. For example, the claim that the WHATWG HTML Standard is future-facing and for incubation is false. Such additions are explicitly against the WHATWG working mode: see the sections on Additions and New Proposals.

It also misunderstands the outline algorithm, which isn't a requirement on browsers, but instead guidance for developers as to how to structure their pages. As such it's not some kind of speculative browser feature as this post characterizes it. (It's bad guidance for developers—but the proper fix for that isn't to include some warning box saying "this feature, which isn't meant for browsers anyway, isn't implemented in browsers" like the W3C HTML fork does. The proper fix is outlined

domenic

// Today, with underscore-prefixed "private"

class Point {
  constructor(x, y) {
    this._x = x;
    this._y = y;
  }
  
  length() {
    return Math.sqrt(squareLengthHelper(this));

domenic

(From a friend one mine; I'm just hosting this here.)

Issue 1: Relativity of Simultaneousness:

Your buddy Einstein is riding the interstellar express train. All the lights are off, but just as it passes your observation platform, he turns on a lamp in the middle of the train. You and he have taken bets on which end of the train, front or back, will light up first. As expected, your video cameras on the platform record the rear of the train lighting up first, since, as the light spreads out from the original location of the lamp, the rear of the train moves slightly closer to the source, while the front end is moving away. However, Einstein reports that his equipment shows both ends lit up simultaneously.

Both of you are correct. In your reference frame the events "light reaches front of train" and "light reaches rear of train" are not simultaneous, even though in Einstein's they are are.

Issue 2: Superluminal Travel