Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

On Sat, Aug 20, 2011 at 12:21 PM, Ian Hickson <> wrote:
> On Tue, 16 Aug 2011, Adrian Bateman wrote:
>> At Microsoft, we also prefer smaller more specific specifications for
>> all the same reasons that it makes sense to engineer software in
>> smaller, more modular parts.
>> * It is easier to implement and test smaller modules. Developers find it
>> easier to focus on one thing and it is easier for testers to do a
>> thorough job of preparing a test suite.
> This doesn't apply to specs, since smaller specs usually just means that
> the same complicated feature is now split over multiple specifications.
> This actually makes testing harder, since you have to try to work out how
> the specification work together rather than having just one document that
> defines the behaviour.
>> * It's much easier to measure "done" when dealing with a smaller spec.
> Specifications are never "done", however small.

As an implementer I agree more with Adrians email than with yours for
what it's worth.

When implementing and reviewing webworkers I *never* looked at the
document here:

I *always* used the much smaller document that used to be available here:

(I now see that that url redirects to the web-apps spec, I have no
idea if this change comes with any other changes than the same
document living on a different url. If it is then that is very
unfortunate. I guess I can just use

When implementing a spec, the first thing I'd like to do is to read
the whole spec front to back. This in order to get a sense for the
various concepts involved which affects the implementation strategy.
It is also important as it's required to review the specification.
With a spec the size of, for example, the HTML5 spec, this is
substantially more difficult. Not only does it take significantly
longer to read the full HTML5 spec if all I want to implement is the
pushState feature. It's also impossible to hold the fully spec in
memory, even at a high level.

Small specs are absolutely more easily implemented and reviewed.

Additionally, having releases of a spec makes it possible to know what
browser vendors and other significant players agree on. A ever
changing slowly evolving spec doesn't say what browser vendors agree
is good as opposed to what the editor happened to have put in since
the various stake holders took a look at it.

Yes, bug fixes need to continue to happen, but that is different and
much more manageable.

/ Jonas

Received on Monday, 22 August 2011 09:23:08 UTC