Re: [css3-images] simplifying radial gradients

On Oct 5, 2011, at 9:19 AM, Chris Lilley wrote:

> Hello Brad,
> 
> On todays call, the CSS WG considered whether to move css3 images to Last Call, and noted that you have a proposal relating to radial gradients.
> 
> We would prefer that you either resolve this issue within two weeks, or alternatively agree that we can move forward and re-raise the issue during Last Call if you are not satisfied.
> 
> Are those options acceptable to you?

I would love to resolve within two weeks. Unfortunately, when the main person I need to resolve it with has said "I've decided to reject [Brad's] proposal for simplifying radial gradients", and doesn't suggest any alternatives to the problem (or acknowledge the problem), it makes it tough to try to work out a resolution that is satisfactory to all (or even good enough to most). I don't feel it was nearly as widely reviewed as linear-gradient was, and so far the only ones to consider my complaints (and say anything on the list) were Tab (the author of this part of the spec) and Brian (an implementor who probably feels that the large effort he contributed to implement radial-gradient in IE10 should not be wasted). It might help if more WG members who are generally familiar with the radial gradients spec can read and consider my in-list comments, and comment back on them (agree that they are valid points, or tell me that I am off my rocker).

As to sending it to Last Call, I feel that doing so implies a level of maturity that I it doesn't have (for radial gradients).  One of its self proclaimed goals is to "specify such an image in a terse syntax", and in that it fails, IMO. It has a complex syntax that can end up with 5 different spots for component values, all of which can be or include lengths or percentages, whereas linear gradients has just 2 spots for component values, and only one of them can include lengths or percentages (I am counting the color stop list as one such place for both linear and radial gradients, even though an unlimited number of stops is possible there).  So, even though there is not a formal requirements document, I fee the spec hasn't "satisfied its relevant technical requirements ", because of the lack of adequate terseness that it sets as its goal, and therefore should not yet be a Last Call.

The many different spots for values and the many different types of values that can go in those spots leads to complex interactions between those values. They can be very hard to guess at the result when you type out or read a radial-gradient using different combinations of all those various values (for me, any way). I think is much more confusing than what this WG normally has as its goal, and so makes it not ready for Last Call.

My impression is that the following points are normally true of WG modules:
we don't add extra features without having a clearly demonstrated need or demand for them, or feel that they will be widely used once available, 
the syntax should be easy to learn and understand by regular human authors familiar with CSS in general,
"date-driven milestones are unreasonable" (quoted from elsewhere, about the prospect of some other specs being rushed to CR), meaning that a module is not done until it is done.
These points are not in the charter, but then, the charter really says nothing about those types of requirements (I believe old charters used to say something similar to the second point, above). Regardless, the process document indicates that we should go to LC when the draft "receives only indications of support for the document , with no proposals for substantive change".[1] That is not the current situation, and will not be in two weeks if Tab and I (and Brian) cannot come to agreement. If we are at an impasse, then the ideal conditions for advancing to LC will not be met (and in theory don't HAVE to be). But I am still hoping that we can find a way to move forward with changes that are more acceptable. We did so for linear gradients, and had good results after much bickering. Now we should make radial gradients just as good and simple for authors, even if it takes more than two weeks to do so.

So, short answer: I will do what I can to work with Tab to resolve differences, but no, I do not think the "resolve or move to LC anyway in two weeks" plan is really acceptable. If radial gradients were moved to a CSS4 module, I would have no problem advancing the rest, but I don't really feel that is the best option either.


1) http://www.w3.org/2005/10/Process-20051014/tr#last-call