Skip to content

Instantly share code, notes, and snippets.

Brian Kardell bkardell

View GitHub Profile
View archive.mjs
import fetch from 'node-fetch';
export async function requestSnapshot(url, data) {
const response = await fetch('https://little-paper-d118.bkardell.workers.dev', {
method: 'POST',
mode: 'no-cors',
headers: {url: url}
});
View camel-to-kebab.js
let _str = (function(){
const tag = document.createElement('span')
return {
propToAttr: (string) {
tag.dataset[string] = true
return tag.attributes[0].name.split(/^data-/)[1]
},
attrToProp(string) {
tag.setAttribute(`data-${string}`, true)
return Object.entries(tag.dataset)[0][0]
View one-platform-draft.md

As I mentioned in Harold Crick and the Web Platform, the HTML specification contains a section on “Other Embedded Content” which specifically mentions SVG and MathML. In that piece I explained their unique histories and how they wound up being “special”.

I think that we need to talk about how that "specialness" relates to the larger Web Platform and I'd like to make the case that we need to move toward a common vision for how to move forward as One Platform. Let me explain what I mean and why this is currently problematic...

Let's talk about parsing

Imagine that I have a document:

<!-- this is the entirety of my.html -->
<p>This is awesome</p>
@bkardell
bkardell / gist:2f6d674308632ff00ad111800ce4074b
Created Mar 7, 2019
@zcorpan's dasherized elements in the HTTPArchive dataset, organized/grouped by number of occurences
View gist:2f6d674308632ff00ad111800ce4074b
{
"1": [
"navbar-login",
"login-prompt",
"test-directory",
"carousel-principal",
"vue-dropdown",
"dropdown-watch-search",
"bootstrap-session-timeout",
"head-search-input",
@bkardell
bkardell / custom-element-data-by-prefix.json
Last active Mar 7, 2019
cleaned up data from https://gist.github.com/zcorpan/56d1040e1afaa883b610c342c2e7a437 http archive report, organized by tag prefix to potentially identify popular groups, saved as json. Uses insertion order from the file to keep recurrent ones early
View custom-element-data-by-prefix.json
{
"lb": {
"lb-component": {
"name": "lb-component",
"ct": 1153
},
"lb-tabset": {
"name": "lb-tabset",
"ct": 26
},
@bkardell
bkardell / custom-element-data-by-prefix.json
Created Mar 7, 2019
This is a json file which takes data from https://gist.github.com/zcorpan/56d1040e1afaa883b610c342c2e7a437 http archive report and organizes it by prefix.
View custom-element-data-by-prefix.json
This file has been truncated, but you can view the full file.
{
"lb": [
{
"name": "lb-component",
"ct": "1030"
},
{
"name": "lb-component",
"ct": "65"
View johnson-quote.md

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

@bkardell
bkardell / declarative-resize-observer.js
Last active Jun 17, 2018
Uses mutation observers to create a declarative `ResizeObserver` pattern based on a boolean `resize-observer` attribute. These elements track the size of their elements in batch and set a tshirt-size container attribute. If `ResizeObserver` isn't implmented, it uses a lightweight approximation. The whole thing weighs in at <1k gzipped and minified
View declarative-resize-observer.js
"use strict";
(function () {
var xSizeEls = [],
custom = {
width: {},
height: {}
},
breakpoints = {
width: {
View selectors.md

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

View reply-draft.md

I think that for the most part I like this proposal. I have three 'concerns'.. The first two are mostly about impact and messaging.

The first is just that as steve said earlier it'd be effectively building in a pattern that would create something we historically advise authors to explicitly not to write manually. That could use a solid explanation of why everyone is ok flipping on that (and confirmation that they are) or I think that could go badly.

Second is that as it stands, for those people who spent a lot of time and effort using sectioning and made good headings that didn't rely on the phantom 'document outline' that never shipped, the beautiful AT heading relationships, the conceptual 'outline' that they built will get less beautiful. For example, given something like:

  <article>
    <h1>Apple varieties</h1>
    <p>The apple is the pomaceous fruit of the apple tree...</p>
You can’t perform that action at this time.