Re: A question on proposals.

Thanks David, for taking your time to answer this.

What I understand from your message is that the idea being good is not  
enough and the syntax and interactivity should be thought out too. (But  
I'd have guessed my last message on standin-color could have pleased  
everyone!)

Taking that standin-color as an example, could it be that such an  
important accessibility feature might be talked over more and modified by  
the working group so we have the same functionality but with whatever  
syntax that suits the current model? Or will I have to re-iterate the same  
idea until I can please the Working Group? If the idea has potential to be  
included, do you come up and say "Yes, we'll try to implement this so no  
need to talk about it anymore, just wait and comment on the draft". Or  
will you come up and say "There is no way we can ask a user-agent to set a  
standin color until images load with whatever method so don't waste your  
time.". This is just an example so I don't lose my own time and make you  
lose time in future.

Thanks a lot for your work, I guess it is really hard job keeping track of  
everything.


On Mon, 11 Apr 2005 17:31:05 -0700, L. David Baron <dbaron@dbaron.org>  
wrote:

> 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
>



-- 
Emrah BASKAYA
www.hesido.com

Received on Tuesday, 12 April 2005 10:59:20 UTC