My Open Source OKRS (Nov 2023 – Apr 2024)

By admin
Perhaps I’ve been working in big tech too long, but I find OKRs (

Objectives
ORG

and Key Results) to be a useful goal setting tool in my professional life. For me they’re way better than the infinite flavours of

Agile
ORG

. I’ve internalised them to the point where I try to use them for my Open Source work, and I’ve been doing so for

the last 2 years
DATE

. Instead of keeping them to myself I figured I’m egotistical enough to share them; hopefully if you’re reading this you’ll be interested in stuff I’m working on and we can work together on it!

WTF is an OKR?

If you don’t have big tech brain worms you might be wondering what an

OKR
ORG

is. As opposed to

weekly/fortnightly
DATE

sprints,

every fiscal quarter
DATE

a team sets a set of

Objectives
ORG

they wish to achieve, that are measured by Key Results – a quantifiable or verifiable rubric that gives verification and exit criteria for the Objective. Similar to

Agile Sprints
ORG

, the given OKRs will be distributed among the team (in my experience

1
CARDINAL

-3 engineers will be tasked with

1
CARDINAL

OKR for

the entire fiscal quarter
DATE

, and a team might have

2
CARDINAL

-4 OKRs). The goal is to end

the quarter
DATE

having completed the Objective, as measured by the Key Result.

Open Source moves a little bit slower than the corporate world, so my Open Source OKRs happen on

a 6 month
DATE

cadence (not least because the majority of this will be done in my free time). I also find I work best with multiple OKRs, where I can dip in and out to sustain energy (if

one
CARDINAL

project stalls or I lose energy, I just move onto the next).

With that said here are my priority ordered Open Source OKRs for

the next 6 months
DATE

, from

November 2023 to April 2024
DATE

:

Objective

1
CARDINAL

: Ship "

Invokers
PERSON

" proposal to all major browsers

My job working on

the Primer Design System
ORG

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
ORG

. Under the guidance of some great mentors like

Mason and Scott
ORG

(among others), I proposed

Invokers
PERSON

, which will give <button> elements superpowers to be able to control interactive elements like <dialog> s.

This work actually began

6 months ago
DATE

in

April 2023
DATE

, when I set out to resolve an issue I filed in

2018
DATE

, asking for a way to open modal Dialogs without JS. My (not published)

April-November
DATE

OKRs were to try and land a proposal to fix this issue, which resulted in a mini proposal for dialogTargetElement , concerns were raised about it not being generic enough, and so that proposal evolved into the Invokers Proposal.

For

the next 6 months
DATE

, 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
LOC

, and "intents to prototype" have been filed for

Chrome
ORG

, and

Firefox
ORG

. Luckily I have

three
CARDINAL

fantastic colleagues helping me here;

Tyler
PERSON

, a colleague at

GitHub
ORG

, is working on the

Chrome
ORG

implementation with me.

Lindsey
PERSON

, a colleague at

GitHub
ORG

, has been working on the

WebKit
ORG

implementation with me. Additionally

Luke
PERSON

, a colleague on the Open UI team, has been improving the proposal and working on the

Chrome
ORG

implementation.

A shoutout to GitHub here, who give their engineers the space and flexibility to make contributions to open source as individuals.

Key Results:


invoketarget & invokeaction
ORG

(feature flag opt in may be required) can open <dialog> elements without JavaScript in the

3
CARDINAL

main browsers – Safari,

Firefox
ORG

,

Chrome
ORG

.

& (feature flag opt in may be required) can open elements without

JavaScript
PRODUCT

in the

3
CARDINAL

main browsers – Safari,

Firefox
ORG

,

Chrome
ORG

. The major elements requiring the above are specified in the HTML standard (minimimally: open PRs to the

WHATWG
PERSON

standard, maximally: merged PRs).


MDN
ORG

documentation PRs filed for the featureset.

Objective

2
CARDINAL

: Ship "CustomStateSet" proposal to all major browsers

I’ve been a huge fan of native

Web Components
ORG

, and use them

daily
DATE

in my professional and personal projects. GitHub uses

Web Components
ORG

extensively among a whole host of other companies. Before joining GitHub class based

React
ORG

components were my go to, but then things got weird. When my colleagues at

GitHub put Web Components
ORG

in front of me I saw all the strengths that originally switched me onto React, I was hooked!

Web Components are not trouble free though; cross browser interop is spotty. Things have improved a lot over

the last few years
DATE

and browsers have made huge strides at interop, but there are still a few stand-out areas that I’d like to address.

My (unpublished)

November 2022 – April 2023
DATE

OKRs set out to increase adoption and understanding of

Web Components
ORG

by building

Web Components Guide
ORG

, working together with great engineers like

Kristján
PERSON

and

Nathan
PERSON

. I’m proud of the work we’ve accomplished so far but started to find it difficult to write effective documentation without caveating all of the various compatibility issues. Of particular note was the lack of support for CustomStateSet – effectively custom pseudo classes for components. CustomStateSet is a really nice feature and works well in

Chrome
ORG

, and while ponyfills exist they’re awkward to use due to the lack of ability to polyfill CSS.

For

the next 6 months
DATE

, my aim is to fix this. I’m going to work on getting viable implementations in

Firefox
ORG

and

Safari
ORG

, as well as work with

Joey
PERSON

on the

Chrome
ORG

team to make sure this feature gets fully fleshed out including great test coverage.

Key Results:

CustomStateSet exists in all browsers (feature flag opt in may be required) and can style a custom element using a pseudo class.

exists in all browsers (feature flag opt in may be required) and can style a custom element using a pseudo class. Web Platform Tests offer robust and comprehensive coverage for the featureset.

All browsers pass

90%+
CARDINAL

of CustomStateSet Web Platform Tests.

Objective

3
CARDINAL

: Bring "hdx" closer to production readyness

A huge bug-bear I have when developing websites is just how poorly native CSS is utilised. It’s a fantastic language that is, in my opinion, poorly invested in within the open source community as well as the teams I’ve worked in. 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
ORG

hasn’t progressed at the same pace, and we’re still stuck with the same methods and practices from

the last decade
DATE

. While SASS delivered incredible value in

the 2010s
DATE

, writing SASS files in

2023
DATE

feels archaic but it’s still a blessing compared to CSS-in-JS.

My (unpublished)

April 2023 – November 2023
DATE

OKRs 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
PRODUCT

project (work began on the lexer with

csslex
PRODUCT

) but I pivoted to using

Rust
ORG

to develop it after seeing the impressive work from

Boshen
PERSON

on the oxc compiler which has acted like a blueprint for building hdx. A shout out here goes to

Romain
PERSON

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.

I’m going to continue this

OKR
ORG

into

the next 6 months
DATE

, with the aim to get the parser fully parsing and minifying

3
CARDINAL

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
DATE

working on a large refactor of the existing code base to get it on track to doing these things.

Key Results:

hdx parses

3
CARDINAL

and minifies more example files, to the same quality and size as other popular CSS parsers.

Objective

4
CARDINAL

:

Chai
PERSON

5 as an

ESM
ORG

module

I’ve been the maintainer of the Chai JavaScript testing framework since

2014
DATE

. The majority of my work here has been guiding other contributors and stewarding the project to try and keep it stable, as it’s one of the most used testing libraries in the ecosystem (if you’re not using it directly, you might be indirectly: @openwc/testing,

Vitest
ORG

, and

Cypress
FAC

make use of it).

Chai
PERSON

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
CARDINAL

last major hurdle is to get it working with

ECMAScript Modules
ORG

(esm). I’ve tried a few times over

the last few years
DATE

but my enthusiasm has waned.

Luckily some great developers have stepped up to help in this effort. Both

Kristján
PERSON

and

James
PERSON

have put in serious effort to refactor

Chai
PERSON

and its dependencies to support esm

first
ORDINAL

class, breathing new life into the project. My aim here will be to continue to mentor and support them to ensure

Chai 5
PERSON

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
PERSON

.

Key Results:

Chai 5 is released as the stable latest version of

Chai
PERSON

.


Chai
PERSON

5 can be imported and used in an esm only project.

Conclusion

There it is, those are my

four
CARDINAL

big open source projects for

the next 6 months
DATE

. If any of them sound interesting to you, please reach out via the usual channels (links in the header). I’ll be writing about this again in

April
DATE

, reflecting on these

4
CARDINAL

and giving myself some new ones.