Keith Cirkel

What is it?

A while ago I wrote a template parts polyfill in order to push forward the "Template Parts" (aka DOM Parts) proposal. It didn't do what I had desired, but further discussions in various working groups shows there is still some interest in DOM parts, but an implementation beyond Chrome would be a great next step.

What's happening?

I intend to implement a prototype similar to the one in Chrome inside WebKit or Gecko in order to help validate that DOM Parts is a worthwhile endeavour. This will involve work at the HTML parser level, all the way up to new DOM APIs; a significant amount of work!

What is it?

interesttarget is a way to wire up tooltips or other ephemeral floating UI (e.g. hovercards) in an accessible way, without using JavaScript. To explain it in code:

<a interesttarget="my-popover" href="..">
  A link somewhere
</a>
<div popover="my-popover">
  I'm a tooltip that appears when a user
  focuses/hovers on the link!
</div>

The sibling feature - InvokeTarget - now exists as a way to wire up buttons to actions. The natural next step, and part of the original explainer for invokers is the "interesttarget" attribute.

What's happening?

My aim is to continue the next phase of invokers (interesttarget), by getting implementations of it in all the browsers and write the formal specifications. Luke has already picked up implementation work in Chrome so I'll likely focus on WebKit and Gecko implementations, as well as the spec.

What is it?

CloseWatcher is a new primitive that consolidates the various mechanisms for closing floating UI (dialogs, popovers, fullscreen) abstracting away from the input method (esc keypress, touch gesture etc), as well as allowing web developers to implement their own watchers of these gestures.

Domenic has been spearheading the spec effort with specs and implementation work in Chrome, and Luke has been working on the WebKit implementation.

What is happening?

I'm going to implement the Firefox implementation for this.

What is it?

headingoffset= is a newly proposed attribute that goes on any element, and changes how <h1> to <h6> are perceived by assistive technology (like screen readers). It transparently shifts all the headings by the number given.

For example a <div headingoffset=1><h1>Hello</h1></div> is the equivalent of <div><h1 aria-level=2>Hello</h1></div> today.

This is useful for websites with User Generated Content, where the HTML inside the <div> is authored by the user, not the web developer.

Mu-An originally devised this proposal in whatwg/html#5033.

What is happening?

Clay and I will be prototyping this out in Chromium, and gathering feedback during the process. From there we will likely move to a spec.

What is it?

Web Components are always registered to the main document, but there exists a proposal for "scoped" element registries, so that developers can register a Web Component to a particular shadow root. The Web Components community is very vocal about this feature, so I've agreed to work on this.

What is happening?

I'll be implementing Scoped Element Registries in Firefox and Safari, and working on the HTML Specification for this. This is a big chunk of work, but luckily I have some help from various members of the Web Components community, including Rob Eisenberg, Justin Fagnani, Peter Burns, Pascal Schilp and Kristján Oddsson. Getting support and assistance from all these wonderful people will definitely make this a fun one!

What is it?

ARIA is the set of standards for extending accessible patterns in browsers. Typically this is done with aria- prefixed attributes, but there also exists the ARIAMixin which is an imperative JavaScript API. It has a couple of issues though, the reflection is a bit wonky and some properties are missing.

I've joined the ARIA Working Group (a benefit of my employment at Microsoft GitHub is that I can participate in web standards groups) in the hope I can provide assistance, especially when it aligns with my other goals such as promoting & improving the use of Web Components.

The ARIAMixin is very useful for custom elements, as would be some nascent proposals such as the Semantic Delegate, exportid proposal, and cross-root aria reflection proposals.

What is happening?

This is going to be quite an exploratory area, so it's hard to pin down some concrete goals. I'd like to resolve ARIA issue #1110 to fix some of the issues with ARIAMixin, and get the Element reflection APIs from that spec into browsers, so that this page is a bit more green. I'd also like to explore the current proposals for cross-root element reflection to try and get a grasp on how we can get declarative cross-root ARIA reflection, and maybe prototype one of those solutions in a browser.

What is it?

Observables are a "reactive programming" primitive. You might have heard of them through more popular library names like mobx, rjxs, or the older baconjs.

A TC39 proposal for Observables has been around since 2015, but has seen little progress. Renewed interest has happened over in the Web Platform Incubator Community Group (WICG) proposal for the same thing, and Chrome has been actively prototyping it.

I've been a big fan of Observables for a long time. One of the first projects I picked up at GitHub was to try and introduce TC39 style Observable to the codebase, which resulted in mini-observable. Perhaps it's time to revisit this with more gusto.

What is happening?

Dominic and Ben have been driving the spec work and the Chrome implementation, and so I'll be mostly taking what they have worked on and applying it to Firefox & Safari. So the plan is to write implementations for Observable within Gecko (Firefox) and WebKit (Safari), to try and get these adopted more quickly into the web platform.

What is it?

My April 23 goals set out to start work on a best-in-class CSS toolchain, in an aim to shift the industry back to writing CSS (a lofty goal reserved for developers with delusional amounts of hubris, like me). The eventual goal is to build out an LSP and compiler toolchain capable of giving engineers a developer experience that makes it easier to write fast, efficient, and modern native CSS but all projects have to start somewhere. This project started out as a JavaScript project (work began on the lexer with csslex) but I pivoted to using Rust to develop it after seeing the impressive work from Boshen on the oxc compiler which has acted like a blueprint for building hdx. A shout out here goes to Romain who's produced some excellent work to make CSS tooling better, including the CSS-import and css-tokenizer gauntlet tests, and offered some great guidance and mentorship.

What's happening?

I'm going to continue this goal into the next 6 months, with the aim to get the parser fully parsing and minifying 3 more of the example files. This sounds like a comparatively smaller goal but there's still a lot of ground work to build out here, hdx doesn't do a good job of parsing CSS variables and I'm still new to Rust development, so I've spent the last month working on a large refactor of the existing code base to get it on track to doing these things.

Lessons Learned

CSS is hard! Creating a parser capable of robustly building a useful AST beyond the base syntax is a mountain of work for CSS, especially compared to other languages. I'll be continuing to work on hdx for a lot longer though, as I'm confident it can have a good impact on the industry.

What is it?

My job working on the Primer Design System for GitHub has lead me to spending time with the Open UI team, a standards community group tasked with extending the Web to provide useful new primitives common to Design Systems. Under the guidance of some great mentors like Mason and Scott (among others), I proposed Invokers, which will give <button> elements superpowers to be able to control interactive elements like <dialog>s.

This is a continuation of my goal to Propose a solution for opening <dialog> without JS.

What's happening?

My aim is to continue this work to its conclusion, by getting implementations in all the browsers and write the formal specifications. To be clear, a lot of this work is underway. For example some of the implementation is already in Chrome Canary, and "intents to prototype" have been filed for Chrome, and Firefox. Luckily I have three fantastic colleagues helping me here; Tyler, a colleague at GitHub, is working on the Chrome implementation with me. Lindsey, a colleague at GitHub, has been working on the WebKit implementation with me. Additionally Luke, a colleague on the Open UI team, has been improving the proposal and working on the Chrome implementation.

Lessons Learned

This has been something of a landmark in my career, I feel. I've learned so much about browsers, specifications, politics, and the energy it takes to get something shipped. I think we're incredibly close to actually putting this in front of users (which was not part of the goals I set myself) and I hope that this feature is as useful as developers are anticipating it will be.

What is it?

CustomStateSet is a proposed feature for CustomElements that lets custom element authors derive their own pseudo classes for their elements. Much like built-ins have :hover or :modal or :checked, custom elements could have for example :state(loaded), :state(open), :state(revealed). The .states property is part of elementInternals and so custom elements keep full control and outside code can't change states (as opposed to classes or attributes).

What's happening?

I'm going to work on getting viable implementations in Firefox and Safari, as well as work with Joey on the Chrome team to make sure this feature gets fully fleshed out including great test coverage. Chrome currently ships an older syntax (:--foo vs :state(foo)), but standards working groups resolved to specify the new syntax, and so I aim to ensure that all browsers support the new syntax.

Lessons Learned

This was a fantastic experience! Getting more heavily involved with the standards process and WebKit & Firefox implementations. I managed to gain experience in Gecko's CSS parser - which is uses Rust - and to grips with its advanced invalidation machinery. Being able to take this feature from start to finish, and having it ship in both Safari 17.4 and Firefox is a career highlight for me.

What is Chai?

Chai is the most popular assertion library in the Node ecosystem, often used with the second most popular test runner in the ecosystem, Mocha. I've been the maintainer of the Chai JavaScript testing framework since 2014. The majority of my work here has been guiding other contributors and stewarding the project to try and keep it stable.

What's happening?

Chai is showing its age a bit, and it's been a lot of effort to try and get it working with new primitives like Maps, Sets, Promises and so on. One last major hurdle is to get it working with ECMAScript Modules (esm). I've tried a few times over the last few years but my enthusiasm has waned. Luckily some great developers have stepped up to help in this effort. Both Kristján and James have put in serious effort to refactor Chai and its dependencies to support esm first class, breathing new life into the project. My aim here will be to continue to mentor and support them to ensure Chai 5 is released as a robust library, and an easy transition from the commonjs Chai 4. Make no mistake though, all the credit goes to them and the other contributors to Chai 5.

What is it?

There is a long standing issue I filed in 2018, asking for a way to open modal Dialogs without JS. Dialogs are, in my opinion, an important part of the platform which enable more "app like" experiences while (hopefully) improving accessibility. In subsequent years, <dialog> hung in the balance as implementations stalled but it has been picked back up (see whatwg/html#4937 for more on that). Adjacent to <dialog> is the new popover attribute which has the ability to open/close without JS.

With popover getting the ability to open/close without JS, and renewed interest in <dialog>, it stands to reason that the ability to open dialogs without JS is a worthwhile feature to explore.

What's happening?

I'm going to work on getting a viable proposal that, in general, browser vendors and spec maintainers agree to pursuing.

Lessons learned

The initial proposal did not get the traction I'd hoped, but it has evolved into a larger proposal around solving the general case, with Invokers.

What is it?

CSS is a wonderful language. It's also underused and underinvested in. A lot of places still use Sass, or Postcss with lots of custom extensions, and this - in my opinion - hold us back. Despite the csswg moving mountains and delivering amazing new standards such as new colour primitives, CSS nesting, layers, variables and even the long awaited :has(), I feel like the community surrounding CSS hasn't progressed at the same pace, and we're still stuck with the same methods and practices from the last decade. While Sass delivered incredible value in the 2010s, writing it in 2023 feels archaic but it's still a blessing compared to CSS-in-JS.

What's happening?

Thinking back to my previous work on making a protobuf parser in JavaScript, and how rewarding and educational that experience was, I'd like to try and write a modern CSS parser, that comes with all the "DX" goodness that new developers expect, such as linting, integration with editors via an LSP, and a plugin system for playing with new features.

Lessons learned

Originally I set out to write this in JavaScript, and produced the first part - csslex. I then chose to pivot to writing it in Rust, inspired by the oxc JS compiler. I think the result is a great start, but there's a long road ahead to get this production ready.

What is it?

I'm a huge fan of web standards. I'd like to be a more active contributor, and try to implement a feature in one (or more) of the browsers.

What's happening?

I'm going to find a feature proposal to work on (or make my own), and get it implemented and shipped in all 3 browsers. That doesn't necessarily mean I'll write all the browser implementations, although I would like to.

I've only dabbled in the occasional bit of C/C++ (which I understand all the browsers are written in), and while I've made some contributions to the JS specs, I've never contributed to other web specs, so this will largely be a learning experience for me.

Lessons learned

This was a hugely rewarding experience and I lucked out in finding a suitable feature to work on that was small enough in scope and easy enough to implement (see this issue comment). I learned a lot about the contribution models for the various browsers and got some excellent hands-on experience in C++.

What is it?

Alongside my desire to build out WebComponents.guide - in order to increase community mindshare around web components - I thought a more experimental way to raise awareness would be to produce a series of videos developing new web components out in the open.

What is happening?

I have come up with a completely original idea called "24 Web Components", every (week)day over December I'll be live-streaming to make 1 component per episode, with special guests from the Web Components community, and my GitHub colleagues.

This one is more for fun than any serious endeavour, and more as an experiment.

Lessons Learned

Streaming is a really interesting way to get people involved with a project, and I found this project to be super fun, if a little intimidating. It is amazing how inept you can feel live-coding in front of strangers.

What is it?

GitHub has been using web components for a very long time. Back in 2021 Kristján and I wrote about how we use them at GitHub. They're a great piece of technology but suffer from lack of developer awareness.

At GitHub we created Catalyst as a way to get developers more interested in Web Components, but I'd like to make that work more generally applicable.

Following this work, Kris and I committed to writing a book, and set to work on writing and researching, and of course the ever pivotal step of buying a domain name (webcomponents.guide). However we resolved that this should be an open source living document, and so that's the plan in the coming months.

What is happening?

I want to increase adoption and understanding of Web Components by building Web Components Guide. With the help of Kristján we'll take our learnings, and the work we've done on Catalyst, and make a general purpose guide for how to use Web Components, akin to the documentation sites for popular frameworks like React, Vue and Svelte.

Lessons Learned

Writing documentation is tough! I think we got the existing documentation in a good place but there's lots of open questions and we're struggling to stay motivated to write more. I still plan on revisiting this but I'm not sure when.

On the success side though, it has definitely turned more people onto web components and we've had good feedback around the quality of existing documentation. One thing I had hoped to get out of this is to point people at some relevant docs when they ask me questions about Web Components and this does just that. Someone recently informed me that they used web components for a project and used this website as their main resource for learning, so that's great!

What is it?

Two areas of heavy development in the Primer Design system (my current day job) are anchored positioning and popups/overlays. These exist mostly because the web platform lacks useful primitives.

open-ui - a collaboration between Microsoft, Google, and other partner companies like Salesforce are working to define UI primitives that can be standardised into html/css standards.

They've defined specs for CSS anchored positioning and a popup html attribute. Implementation work is underway in Chromium for these, and Google is also funding OddBird to develop polyfills for both features.

What's happening?

I'm going to work with OddBird on these polyfills to get them feature complete more quickly, to help push these features reach standardisation quicker. By polyfilling we'll be able to provide useful feedback to browser vendors.

Lessons learned

This was a success! It's the defacto polyfill for popovers, used in many places and made my day job quite a bit easier. The polyfill has grown over time to be quite robust and I'm proud of the work done here.

What is it?

Protobuf is a popular format for transmitting across servers, similar in principle to JSON but more efficiently packed and has better type security. The protobuf package turns a .proto file, containing a DSL for the message format, into code for various languages, like Go. There is a JS output format but it leaves a lot to be desired.

What is happening?

I'd like to create a self-hosted parser (i.e. one written in JS) that can produce a JS AST of the .proto DSL, and in turn create a tool that generates JS code you might actually author if you were implementing protobuf without using generated code.

I want to do this not only to make Protobuf more of a viable alternative in JS, but also to get more experience writing parsers, which is a fun thing I've done a few times before (in various jobs I've written parsers for various formats, e.g zigbee & mqtt protocols), but wish I could do more of.

Lessons Learned

While I learned a great deal with this project, I don't think the resulting modules have had the desired impact. The parser is for the most part complete, and I've used it on a couple of occasions, but largely JSON is just faster and easier to use in JavaScript. One more recent successful outcome of this, though, is that the deno std library now uses my varint implementation.

What is it?

The HTML Template Instantiation proposal is a very interesting proposal that aims to provide "mustache style" template binding baked into the web platform. There's been a lot of active discussion around this and similar proposals, but little seems to be happening.

What is happening?

I'm going to implement a sort of polyfill for this in order to gather feedback and try to encourage adoption of this as a standard.

Lessons Learned

While I think the code created is useful, I'm not sure this did much to shift adoption of the standard. We did end up using it a fair amount at GitHub though, which proved it's a useful technology worth exploring. Maybe I'll do more here, one day.