To be honest this always drove me nuts when we were trying to do WebSockets. Having code is great for conformance tests, but a spec IMO should do a good job of setting out preconditions, postconditions, performance guarantees (e.g. STL algorithms specifying runtime complexity) and error handling. When you just list code for what the function means, that leaves alternate implementations rather ambiguous as to what is a spec violation and what is not. For instance, stringifiers - what if an implementation rounds things to some finite precision rather than multiplying by 100 and spewing out some arbitrary length percentage? is this correct? Or do you have to just use the code in the spec as given? And if you use the code in the spec as given and everyone implements in exactly the same way, why not just publish a library for it and say to heck with the spec?
2015-06-11 13:32 GMT-07:00 Dimitri Glazkov <dglaz...@google.com>: > Folks, > > Many specs nowadays opt for a more imperative method of expressing > normative requirements, and using algorithms. For example, both HTML and > DOM spec do the "run following steps" list that looks a lot like > pseudocode, and the Web components specs use their own flavor of > prose-pseudo-code. > > I wonder if it would be good the pseudo-code would actually be ES6, with > comments where needed? > > I noticed that the CSS Color Module Level 4 actually does this, and it > seems pretty nice: > http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor > > WDYT? > > :DG< >
