/** | |
* Pass in an element and its CSS Custom Property that you want the value of. | |
* Optionally, you can determine what datatype you get back. | |
* | |
* @param {String} propKey | |
* @param {HTMLELement} element=document.documentElement | |
* @param {String} castAs='string' | |
* @returns {*} | |
*/ | |
const getCSSCustomProp = (propKey, element = document.documentElement, castAs = 'string') => { |
function decorate(tag, template) { | |
customElements.define(tag, class extends HTMLElement { | |
constructor() { | |
super(); | |
this.attachShadow({ mode: 'open' }); | |
} | |
connectedCallback() { | |
let root = this.shadowRoot; | |
if(!root.firstChild) { |
// Possible `gender` values. | |
type Gender = 'male' | 'female' | 'other' | |
// Generic `person` interface. | |
interface IPerson { | |
// Specific string. | |
gender: Gender | |
// Any string. | |
name: string |
export default scope => { | |
// match the filter on autofilled elements in Firefox | |
const mozFilterMatch = /^grayscale\(.+\) brightness\((1)?.*\) contrast\(.+\) invert\(.+\) sepia\(.+\) saturate\(.+\)$/ | |
scope.addEventListener('animationstart', onAnimationStart) | |
scope.addEventListener('input', onInput) | |
scope.addEventListener('transitionstart', onTransitionStart) | |
function onAnimationStart(event) { | |
// detect autofills in Chrome and Safari by: |
All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
/* debug.css | MIT License | zaydek.github.com/debug.css */ if (!("is_debugging" in window)) { is_debugging = false; var debug_el = document.createElement("style"); debug_el.append(document.createTextNode(`*:not(g):not(path) { color: hsla(210, 100%, 100%, 0.9) !important; background: hsla(210, 100%, 50%, 0.5) !important; outline: solid 0.25rem hsla(210, 100%, 100%, 0.5) !important; box-shadow: none !important; filter: none !important; }`)); } function enable_debugger() { if (!is_debugging) { document.head.appendChild(debug_el); is_debugging = true; } } function disable_debugger() { if (is_debugging) { document.head.removeChild(debug_el); is_debugging = false; } } !is_debugging ? enable_debugger() : disable_debugger(); |
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
- There are always 24 hours in a day.
- February is always 28 days long.
- Any 24-hour period will always begin and end in the same day (or week, or month).
The proposal you’re about to read is not just a proposal. We have a working implementation of almost everything we discussed here. We encourage you to checkout and build our branch: our fork, with the relevant branch selected. Building and using the implementation will give you a better understanding of what using it as a developer is like.
Our implementation ended up differing from the proposal on some minor points. As our last action item before making a PR, we’re writing documentation on what we did. While I loathe pointing to tests in lieu of documentation, they will be helpful until we complete writing docs: the unit tests.
This repo also contains a bundled version of npm that has a new command, asset
. You can read the documentation for and goals of that comma
'use strict'; | |
class HTMLElementPlus extends HTMLElement { | |
static defaultAttributeValue() { | |
/* the name of the attribute is parsed in as a parameter */ | |
return; | |
} | |
static parseAttributeValue(name, value) { |