W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: [css3-images] remaining gradient issues

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 26 Jul 2011 15:24:14 -0700
Cc: www-style list <www-style@w3.org>
Message-Id: <B9468366-64C0-4304-BFEA-EB565F989667@gmail.com>
To: Brian Manthos <brianman@microsoft.com>

On Jul 26, 2011, at 1:45 PM, Brian Manthos wrote:

> Brad:
>> I understood very little of what you describe above.
>> In any event, are you saying we should have a different
>> rendering in a future version of gradients than in what
>> this version ends up with once it makes it to REC?
> 
> As you've phrased it, no.
> 
> (1) The current rendering of corner-to-corner gradients is less appealing than the "reverse ratio" renderings that were discussed recently in the "Gradient Magic" thread.
> (2) My last mail provides an algorithm for producing the "reverse ratio" renderings (unless I messed it up).

OK, if you say so. Is that the same result as the way I described it ("In corner to corner gradients, having a midpoint that stretches between the other corners, and a gradient path angle that is perpendicular to that")?

> (3) There was discussion on Monday of moving corner-to-corner gradients out of the v3 module (and into the v4 module).
> (3a) If we choose to move them, I recommend we consider (2) for the preferred corner-to-corner gradient rendering.
> (3b) If we keep corner-to-corner gradients in v3 and the current rendering behavior stays through REC, then I withdraw my (2) proposal since it becomes a painful divergence in v4 which isn't worthwhile (unless we introduce a new magic/auto/whatever syntax).

I agree with you then, on each point.

> 
>>> Regarding Brad's proposal "add 'from' keyword".An equally
>>> attractive and unattractive proposal is to add the 'to' keyword
>>> instead.  I recommend against both approaches.
>> Why? It is a simple, clarifying change in existing keyword text
>> in a simple, usable model. I don't understand what you have
>> against it. If 'bottom left' was nearly good enough, but a little
>> ambiguous, then what do you have against adding a word to
>> clarify the meaning?
> 
> It's verbose and cumbersome.
> 
> Left(wards), right(wards), down(wards), up(wards) - single words that succinctly and clearly indicate a direction for the gradient vector.  Using more words is just pollution.
> 
> Using pairings of these two words is just as succinct and clear.  Adding more words has additional cost and offers no additional value.

I disagree. I think it is much clearer and natural to say "from top left" than "downwards bottomwards". The latter is awkward AND longer. But I'm happy to leave it to a WG vote. Or even to leave it up to the module author at this point (unless others object), as I think he understands both points of view and can probably decide on something that can get consensus agreement. My view is that "from" has a small advantage over "to", but both are less cumbersome than adding "wards" to each. You disagree. But we don't need to debate it forever until it is perfect for all, we just need to choose something that is good enough for nearly everyone.

> As hinted in my previous mail, I suspect the whole problem probably stems from an original "looseness of language".  If terms such  "gradient vector" were used rather than "gradient line", the backwards notion of "keyword means starting point" probably would have been avoided in the before time.

Well I, for one, found term "gradient vector" an unfamiliar and mathy way of talking about direction. Anyone can understand what a line is though, and that it can be described by endpoints and direction. In degree notation, the endpoints are based on the direction, and in keyword notation the direction is based on the endpoints (one specified and the other determined by opposite corner). With the newer "gradient magic" version, it is still two corners that determine the direction, but in a slightly more roundabout way (that the author won't really care about as long as it looks nice).
Received on Tuesday, 26 July 2011 22:24:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:42 GMT