You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Web Machine Learning group asked me to give a talk on "Spec writing with Bikeshed using the latest WebIDL and Infra standard conventions" event. I wrote up some notes to prepare and thought I should post them somewhere public for posterity. I think they align best with this repo, so dropping them in an issue here so we can maybe migrate them into procspec in the future.
Examples below may be specific to WebNN since that was the audience.
What have we learned (by making mistakes) that got us here?
Earlier web specs gave high level description of behavior, e.g. input and output. Turns out a lot of the implementation can be observable and thus lead to compatibility problems. Developers don't test everywhere or read warnings.
Specs are for a specific audience: implementers; if you try to write for developers, you're gonna have a bad time. They should be looking at MDN.
If you define anything in two places you have twice the chances of getting it wrong. If you get out of sync, everything is wrong. Prioritize precision over readability.
Non-normative notes are your friend.
"domintro" sections help reconcile a lot of the tensions above. They're developer-facing non-normative notes in the spec. Use simpler phrasing, don't worry as much about edge cases, etc.
Important details:
WebIDL is the interface between your spec and JavaScript. 99.99% of the time your spec shouldn't mention anything related to JavaScript outside of examples. (So nothing Normative). And that 0.01% is REALLY HARD to get right, leads to security issues, etc.
Spec should be written in terms of Infra types - numbers, strings, lists, ordered maps, etc, with the defined operations.
Infra is not perfect or complete, you will go beyond it. Look at other specs for inspiration - better to follow precedent. Look at open Infra issues and consider filing issues if you're in novel territory.
e.g. debate between [[internal slots]] and "has an associated" text.
Bikeshed tips:
Think of Bikeshed as a compiler for your spec.
Like code: the less you write the lower your chances of having a bug
Link terms as much as you can. It helps avoid ambiguity. This is like writing strongly-typed code - you'll get errors earlier.
Use scopes when linking - scopes are good!
Using algorithm blocks correctly gets you error checking - ensures you don't have unreferenced variables, catches some typos, etc.
Keep your build error-free. ("--die-on=warning")
Prefer markdown to markup - shorter, more likely to catch errors
It is not perfect:
easy to end up with variables in the global scope, can't verify that.
can't verify types of inputs/outputs
Bikeshed is not bug-free, but you can generally work around things.
The Web Machine Learning group asked me to give a talk on "Spec writing with Bikeshed using the latest WebIDL and Infra standard conventions" event. I wrote up some notes to prepare and thought I should post them somewhere public for posterity. I think they align best with this repo, so dropping them in an issue here so we can maybe migrate them into procspec in the future.
Examples below may be specific to WebNN since that was the audience.
Background material:
Writing Procedural Specs
Writing Specifications with Bikeshed
Bikeshed Docs
What have we learned (by making mistakes) that got us here?
Important details:
Bikeshed tips:
Ecosystem
Conclusions:
The text was updated successfully, but these errors were encountered: