RE: [css3-images] Gradient Magic

From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
>On Mon, Jul 18, 2011 at 10:33 AM, Brian Manthos <brianman@microsoft.com> wrote:
>> For consideration...
>>
>> Aren't there really 4 options:
>> a. square made from nearest side
>> b. square made from farthest side
>> c. square made from nearest-corner
>> d. non-square, snap directly to corner
>>
>> Option c matches the WD and ED.
>> Option d is what Behnam would like to have available in some form.
>> Options a & b haven't been discussed.
>>
>> I mention the above because we already have keywords from radial-gradient that align with a, b, and c fairly well.
>
>Behnam doesn't actually want a square, though what he wants can be described as first drawing it into a square and then stretching it into the final rectangular form.

I didn't say he wants a square.  Reread 'd'.

>On Mon, Jul 18, 2011 at 7:51 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> My "as-square" proposed keyword, as I described it [1], would actually have created the gradient this way (although now I notice my renderings were wrong). Thus, if the gradient is in a square and you >use a multiple of 45deg, it not only goes corner-to-corner, but also the mid point stretches between the other two corners. Then when you let the square act as a dimensionless box and conform its width >and height of the size of the background painting area (as linear-gradient does now), and you also let the angle flex with the box to go from 45deg to something else. So the midpoint that stretched >between the other two corners would also continue to do so.

>It actually wouldn't work with your as-square as you described it, since that only affected the angle; the rendering was then done into the full rectangle.  You need to actually draw the entire gradient into >a square and then stretch it, like what Behnam described with using an SVG gradient and background-size, or do coordinate space tricks that accomplish the same thing, like with SVG's >"objectBoundingBox" coordinate space:

That's one way to think about it.  That's not the way I think about it though.

I think about it as control points.

Going back to my 4 options above, the logic is as follows:
1. you start with a rectangle from the box
2. adjust the rectangle for cases a, b, and c:
 a. if the box is a non-square rectangle:
  i. if wide rectangle, move the left rightward and the right leftward equivalently until a square is reached
  ii. if tall rectangle, move the top down and bottom up equivalently until a square is reached
 b. if the box is a non-square rectangle:
  i. if wide rectangle, move the top up and bottom down equivalently until a square is reached
  ii. if tall rectangle, move the left leftward and the right rightward equivalently until a square is reached
 c. if the box is a non-square rectangle:
  i. if wide rectangle, move the left and right inward and top and bottom outward equivalently until a square is reached
  ii. if tall rectangle, move the left and right outward and the top and bottom inward equivalently until a square is reached
 d. (leave the rectangle alone)
3. the corners of the rectangle after 2 define your start end and end points for the gradient line

Your approach of "gradient ... stretch" is concerning to me.  Adjusting rectangle coordinates before you build a gradient in the first place is far simpler and I don't find it concerning.

Sidenote: In case 'c', nearest-corner and farthest-corner mean the same thing in the above algorithm because the spec has the gradient line pass through the center of the box.  It doesn't *have* to be this way, and a future version of the spec could define an alternate pass-through point that would make nearest-corner and farthest-corner behave differently.  If that happens, case 'c' would split into two slightly different algorithms.

Received on Monday, 18 July 2011 19:27:25 UTC