Specification styles

Boris Zbarsky bzbarsky at MIT.EDU
Thu Jan 30 11:07:39 PST 2014

On 1/30/14 10:20 AM, Forrest L Norvell wrote:
> So far, this has been a very straightforward spec to implement.


I think I may have been a bit unclear, my apologies.

I think we all agree that ES-style specifications are in fact more 
straightforward to transcribe into an ES implementation.

What is harder, in my experience, is understanding whether the 
specification actually says what it means to say and determining whether 
there are bugs in the specification.  This arises to some extent from 
the core functionality being partially obscured by a fair amount of 

Now I agree this is somewhat subjective.  Some people prefer to have all 
the complications explicitly written out, both in specifications and in 
code, while others prefer reusable tested black boxes that have certain 
defined behavior.  The former approach is much more verbose and can thus 
hinder understanding of the big picture.  The latter approach involves 
in-depth understanding of the black boxes to understand the details.  In 
practice, both the WebIDL and ES styles use some mixture of the two; 
what differs is the exact set of black boxes used.  The ES style black 
boxes are mostly more fine-grained than the WebIDL ones.

I wish I had a good way to combine the strengths of the two approaches 
more than existing specification formalisms do right now.  In some ways, 
something that allows looking at higher-level definition in terms of 
black boxes and then on-demand (e.g. a "expand this" or "expand all in 
this section" link) allows the reader to inline the black boxes to see 
all the details might be a possibility.  That would involve creating 
some tooling, obviously.

> As an implementor, I find this all a refreshing contrast to trying to
> wrap my head around WebIDL

I honestly think that this (just like other people's experiences with 
trying to wrap their heads around ECMASpeak) is at least partially due 
to familiarity, or lack thereof, with the black boxes being used as 
specification primitives...  Partially it may be due to the wrong 
primitives being used, of course, which is a real problem in both styles 
I believe.

> I have nothing against formal specification methods per se, but, at least for things
> that are implementable in pure JavaScript (as Domenic's proposal is)

It's not, actually, since it requires asynchronous callbacks which do 
not currently exist in pure JavaScript.  This is not quite a nitpick, 
since properly defining asynchronous callbacks is a fairly nontrivial 
matter with security implications, as I already pointed out in this thread.


More information about the es-discuss mailing list