How to add features to HTML5 (Was: tracker already has ternary state - RAISED)

I noticed a query on the www-archive list regarding what the process was 
for adding features to the spec. I tried to find somewhere where this was 
documented, but all I could find was how to raise issues, which is a 
different process altogether. So, here's a look at how to propose new 
features. I hope it is helpful.

On Sat, 7 Jun 2008, Laura Carlson wrote:
> 
> So...
> 
> Step number one is...?
> Step number two is...?
> Step number three is...?
> etc.
> Last step is proposal is  incorporated into spec.

Actually that's far from the last step.

The process for adding features to the spec is:

 1. Research the use cases and requirements by discussing the issue with 
    authors and implementors. Read the responses. Listen to the feedback. 
    Consider whether your ideas are good solutions to the use cases and 
    requirements put forward. Discussions here should be done in public,
    e.g. on an archived public mailing list or documented in blogs.
 2. Get implementors to commit to implementing the feature. If you can't 
    get several implementors to implement the feature, then get at least 
    one user agent to implement it experimentally. Experimental 
    implementations should be publicly available.
 3. Bring the experimental implementations to the attention of the spec's 
    editors. Document the experience found from any implementations, the 
    use cases and requirements that were found in the first step, the data 
    that the design was based on.
 4. Participate in the design discussions, considering all the proposals 
    carefully. Typically at this step the original design gets thrown out 
    and a significantly better design is developed, informed by the 
    previous research, new research, and implementation and author 
    experience with experimental implementations. Sometimes, the idea is
    abandoned at this stage.
 5. The spec is updated to reflect the new design.
 6. Implementations are updated to reflect the new design. More authors 
    and implementors are exposed to the design.
 7. The spec is updated to fix the many problems discovered by authors and 
    implementors, over a period of several years.
 8. At the same time, write a comprehensive test suite. This will also 
    find problems in the spec, which have to be fixed.
 9. Eventually, a number of provably interoperable implementations are 
    deployed. At this point development of the feature is somewhat frozen.

This is the process that has been followed for almost all the new features 
in HTML5. Some features failed to go through this process, most of those 
are likely to be removed (e.g. the data templates stuff).

I should add that in almost all cases, features fail to make it past the 
first few steps. Even after reaching step 5 (adding the feature to the 
spec), if the feature doesn't get implemented widely it can (and will!) 
_still_ be dropped. The default state for a feature request is for it to 
be rejected; the default state for a section of the spec is for it to be 
eventually dropped. I can't could the number of ideas I've had that I've 
thrown out, sometimes before even talking to anyone about them (step 1).

Also, at the moment I'm being especially negative in terms of new 
features, since HTML5 has so many new things already and implementations 
are lagging behind. We don't want to add so many things to the spec that 
user agents all implement different new features and nobody is compatible! 
Because of this, the bar for adding features right now is basically a 
threat from an implementor that if we don't add the feature they'll just 
make it up themselves and implement it anyway. This limits it only to 
things that are so important that browser vendors (an especially stingy 
and overworked group) are actually ready to commit money and risk interop 
issues over it.

(This doesn't apply to features that were proposed last year or earlier, 
since those would already been processed last year, before the feature 
freeze was announced, if it wasn't for me being slow.)


> Where does bugzilla fit in?
> Where does issue tracker fit in?

Those are more useful for tracking problems and errors in the spec, than 
for tracking new features.


> Where and how is this agreement made?

That doesn't really matter so long as it is publicly archived and that the 
core community (for lack of a better definition, those on the public-html 
and whatwg lists) knows about it soon enough.


> Which implementors and authors are you referring to?

As many as possible. Certainly we'd want representatives of the top four 
browser vendors involved (or at least invited).

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 9 June 2008 21:52:32 UTC