W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2015

Deprecating old IDL

From: Marcos Caceres <mcaceres@mozilla.com>
Date: Sat, 19 Sep 2015 11:55:21 -0400
To: public-script-coord <public-script-coord@w3.org>
Message-ID: <etPan.55fd8569.5836d8af.e760@Zero-privacy.local>
Hi All, 
tl;dr: The ReSpec team would like to start deprecating the use of "old school WebIDL" in ReSpec in favor of "contiguous WebIDL". We will soon begin showing a warning in ReSpec's pill-menu about this. 

For info on contiguous WebIDL: 


Long version: 
We are deprecating old school WebIDL. What is this "old school WebIDL" you ask? Well, it's IDL you add to a spec by using a <dl>, like:

<dl title="interface FooBar" class="idl">

Other stuff....


In its place, we want to encourage you to move to contiguous WebIDL: 

<pre class=idl>
interface FooBar(){
 readonly attribute DOMString baz;

You can read a little bit about it here:

And see detailed examples of usage here:

## Why?

There are a number of issues with the "old school" approach:

1. Tremendously tedious for authors to maintain. 

2. Tremendous redundancy: the generated tables and other gunk that ReSpec spits out from the IDL is already in the IDL. This leads to needlessly long specs.

3. More seriously, leads to bad specs: specs should be imperative, not declarative. Imperative in that they should define the algorithms/behavior, and not be a collection of statements. Old school IDL lends itself to bad specification practices, by forcing developers to write specs in such a manner. Over the years, we've had to add options to ReSpec like "noLegacyStyle" to avoid such problems, but this has led to other issues with in-document references, etc. Contiguous WebIDL solves this.

We will soon begin showing a warning in ReSpec's pill-menu soon. We will no longer be maintaining the old school code, but documents will continue to work just fine. 

Let me know if you have any questions or comments. 
Received on Saturday, 19 September 2015 15:55:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC