Re: Unprefixing CSS properties

On 24/11/2011 02:26, Tab Atkins Jr. wrote:
> On Wed, Nov 23, 2011 at 4:32 PM, Bjoern Hoehrmann<derhoermi@gmx.net>  wrote:
>> * fantasai wrote:
>>> And if I had come up with a Suboptimal Design Flaw, you would say
>>> there should be a rule that Suboptimal Design Flaw reviews should
>>> be done at an earlier phase. :) You'd really want a Review Everything
>>> Sooner Faster rule.
>>
>> Late reviews are the natural result from omitting design rationale from
>> drafts, not caring much about properly responding to early feedback, and
>> not actively seeking out early feedback, like asking horizontal review
>> groups to review prior to last calls. The net effect is that flaws are
>> caught only very late, meaning there will be additional last calls, and
>> that in turn means it's probably better to wait even longer to review a
>> draft as by the time of a first or second last call the design has not
>> stabilized yet. Of course, at the time of the third last call it's like-
>> ly too late to comment, so overall you don't get much review. In case of
>> the CSS Working Group, it doesn't even matter much whether you review in
>> this decade or in the next one, for many features.
>>
>> To avoid this self-defeating and disenfranchising effect we have things
>> like schedules, milestones, and process requirements, that allow people
>> to synchronize. If the first last call actually meant a Working Group's
>> done all it can to gather feedback and all issues are addressed, it just
>> wants to give the community one last chance to check if earlier feedback
>> has been missed or has not been addressed as agreed upon, rather than,
>> oh it kinda looks feature-complete so people should check it out, then
>> you would obviously get your feedback earlier and more predictably.
>
> Would you like to connect this criticism to anything that's actually
> happened, or would you prefer to just rant without context?
>
> The spec in question, after all, hasn't had a single Last Call yet,
> does often include rationale in drafts, and is produced by two of the
> most active and responsive editors in the CSSWG or the W3C as a whole,
> so I don't understand what this email is even attempting to correct.

As others have also said, it was not my impression that this criticism 
was leveled at any particular spec or editor, and it's clear to everyone 
that there are some very pro-active editors.

Bjoern's comments are very frank, but I can relate to at least some of 
them.  One thing in particular that I've found frustrating when doing 
early reviews of various specs is the lack of explicit design rationale. 
  Or, where design rationale exists in the spec, it is not of wide 
enough scope.  Things like use cases, prior art, known author 
frustrations and workarounds and errors, known relevant successes and 
failures, known and suspected interactions with other specs and groups 
are all rather useful to have summarized in advance of reviewing a spec. 
  It's unlikely we'd want such an analysis in the spec itself, but 
having a wiki page (possibly based on mailing list discussions) for each 
spec to hold such analysis would be useful.  I know the wiki is being 
used more frequently now, but I think there's further to go yet.

Of course, such analysis _is_ being done by the editors; it's just that 
it's often not recorded in a single place that would assist reviewers.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 27 November 2011 12:17:44 UTC