Skip to content

Instantly share code, notes, and snippets.

View bkardell's full-sized avatar

Brian Kardell bkardell

View GitHub Profile

Who we are: Igalia are active participants in ECMA, W3C and WHATWG and are very significant contributors on all of the browser engines and Web Platform Tests, as well as some downstream browsers. We are also the maintainers of 2 of the official WebKit ports for Linux: WebKitGtk+ is the engine Epiphany (now named as Web) is built on top of, and its the browser shipped by default in various linux Desktop distros; we are also the creators of WPE, a WebKit port optimized for embedded devices.

Position comments:

There are a number of ways to frame a question. "Should the web have maps?" seems like such an easy one: The obvious answer is yes.

However, by itself this is not a very useful answer: The web does have maps. Some of the earliest popular uses of <img> were for geographical maps. That's purely declarative, and it's in HTML. But most of us would agree that that's not what we mean.

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}
});
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]

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 March 7, 2019 17:11
@zcorpan's dasherized elements in the HTTPArchive dataset, organized/grouped by number of occurences
{
"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 March 7, 2019 01:45
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
{
"lb": {
"lb-component": {
"name": "lb-component",
"ct": 1153
},
"lb-tabset": {
"name": "lb-tabset",
"ct": 26
},
@bkardell
bkardell / custom-element-data-by-prefix.json
Created March 7, 2019 01:37
This is a json file which takes data from https://gist.github.com/zcorpan/56d1040e1afaa883b610c342c2e7a437 http archive report and organizes it by prefix.
This file has been truncated, but you can view the full file.
{
"lb": [
{
"name": "lb-component",
"ct": "1030"
},
{
"name": "lb-component",
"ct": "65"

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 June 17, 2018 18:08
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
"use strict";
(function () {
var xSizeEls = [],
custom = {
width: {},
height: {}
},
breakpoints = {
width: {

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