W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Recording rationale behind CSS design decisions (Was: Re: Features and fixes incompatible with backward compatibility)

From: Anton Prowse <prowse@moonhenge.net>
Date: Tue, 21 Feb 2012 08:48:24 +0100
Message-ID: <4F434C48.2030001@moonhenge.net>
To: www-style@w3.org
CC: Brian Manthos <brianman@microsoft.com>
On 21/02/2012 03:48, Brian Manthos wrote:
> David Singer:
>> ... I think it would be of great help to this mailing list if we
>> all re-read the previous discussions on this topic, before we post
>> much more.
> Unfortunately, this is a very tall order.  And for most (employed)
> humans is simply unachievable as the mountain continuously rises.
> What's needed is a human effort to coalesce prior discussions *and
> conclusions* into a central location, remove redundancy, etc.  The
> specifications codify the versioned "answers" but not the why or how
> those answers were reached.
> On a related note, discussions often trail off and never get
> answered.  For example, there are several occasions where a long
> discussion followed a proposal (for example: splitting
> background-position).  The last two or three posts (regarding
> scenarios and issues) goes completely unanswered and (to my
> knowledge) undocumented beyond being "in the archive".  As an author
> of some of those "unanswered last posts," I find it very frustrating
> -- especially when the discussion resets to zero again and I have to
> dig up my old posts and link them repeatedly.  Often the subsequent
> response doesn't move things forward much at all, and then silence
> returns.
> Part of scaling up (people and modules) requires having a memory of
> contributions and efficiently incorporating them into the evolution
> of the product, in this case the CSS specifications.  I often feel
> like this forum is incredibly lossy in that regard, which is
> disrespectful of people's time and effort.  I'm not suggesting
> chasing anyone down with torches; it doesn't really matter who is at
> fault (if anyone at all).  Rather I'm just pointing it out as
> something that could and should be improved.

I fully agree.  One thing that could help would be if spec editors used 
a wiki page corresponding to their spec to describe the more 
difficult/controversial/misunderstood decisions, either through a 
summary of the arguments or even just links to pertinent mailing list 
posts.  (This would also assist other WG members who perform spec reviews.)

I like the fact that the EDs of specs are becoming ever more 
informative, with links to bug reports and descriptions of issues.  In 
an ideal world we would have annotated versions even of RECs, where 
rationale is summarized, though I don't think that's realistic at the 
moment given the current feeling that the WG is already unable to 
progress specs fast enough.  Smaller specs again seem to be the way to go...

Anton Prowse
Received on Tuesday, 21 February 2012 07:48:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC