Re: A question on proposals.

On Tuesday 2005-04-12 02:25 +0300, Emrah BASKAYA wrote:
> Can someone tell me(us?) how the proposals are being accepted / rejected?  
> There some good ideas / bad ideas, some of the bad ones could be improved  
> if thought over, some are repetitions of old ideas. Can someone enlighten  
> us who will be responsible for presenting a new idea to the working group,  
> and what is the criteria for getting an idea to the working group? Is  
> there a f.a.q. page on this that one can point us to? That would do too.  
> For example, I'd really like to know if something similar to my  
> standin-color idea could ever make it some CSS draft. Have I have already  
> made the proposal by simply sending it to this list?

As just one member of the working group, I'll make a few comments:

Generally, a good proposal:
 1. is concise,
 2. is precise,
 3. explains the need for the feature, and
 4. fits into the design of the relevant specifications.
If being precise and being concise are in conflict (which is not always
the case), then choosing between the two depends how far along the
proposal is.  By the time something is in a spec, it must be precise,
but discussion and consensus is often much easier with a proposal that
is simple.

There's been a huge amount of traffic on this list for the past few
weeks, and I've been pretty busy, so I've barely even read any of it.
(And if I don't have time to read it, I certainly don't have time to
implement it.)  Skimming the threads, I'd note a few main threads:

 A. The "Parent pseudo-containers" thread:  The proposal here seems to
    mix the motivation, the proposal itself, and the examples, which
    makes it less concise.  (A reader often wants to skim the motivation
    and the examples.)  The use case is well known and pretty clearly
    important, though, so there's not that much need to go into detail.
    And I don't think it fits into the design of existing specifications
    very well.  I'll try to respond to that later, when I have some
    time.

 B. The "Targeting CSS3 only" and "Conditional CSS sections" threads
    rehashed things that have been discussed many times before.
    Conditional per-UA comments are unacceptable since they make it
    almost impossible for new browsers to enter the market.  If there
    was anything new about property co-dependence in this thread, it was
    well hidden in the midst of messages repeating a discussion that
    seems to happen every few months.  (FWIW, the first step in solving
    the property co-dependence problem is deciding whether the problem
    it's solving is lack of browser support or being overridden in the
    cascade.  I tend to think it's really the latter, which is harder.)

 C. The "Stand-in color before images load" thread touched on a bunch of
    issues that the working group discussed when we ended up with the
    current multiple backgrounds proposal.  When we discussed that
    proposal, there were pretty serious problems with every option
    presented, and I think the goal of the group was to pick the least
    of many evils.  If I have a chance to read the thread, I'll try to
    point out some of the problems with the various approaches, if I
    remember them.  But there's a huge amount of email there.

 D. The "Style confirmation descriptors" thread had a very unclear
    proposal that as far as I can tell didn't add anything that's not in
    media queries, which also fits much much better with existing
    specifications.


That said, the working group is currently focused mostly on finishing
CSS 2.1.  Getting a specification that's clear enough to lead to truly
interoperable implementations is a huge amount of work, and the CSS
working group is currently attempting to do it with a rather small
number of people.

I'd also note that getting details right so that features are
interoperable requires thinking about how all the parts of the
specification interact with each other.  Features that don't really fit
into the processing model are thus both much harder to implement and
much harder to define precisely.

-David

-- 
L. David Baron                                <URL: http://dbaron.org/ >
          Technical Lead, Layout & CSS, The Mozilla Foundation