RE: [css3-images] Simplifying radial gradients

Tab:
> After substantial consideration, I've decided to leave radial
> gradients as they are.  I believe that almost every feature can
> justify itself sufficiently, and the few that can't are either
> justified by consistency or are minor enough that I don't consider
> further changing existing implementations to be worthwhile.

Agree.  I haven't heard anything that motivates me to support deviating from the "W3C Working Draft (8 September 2011)" w/r/t the Gradients section and its subsections.




Some details...



Tab:
> As well, creating an image 2 or 4 times the size of the
> background positioning area is potentially bad for performance -

There are substantial optimization opportunities.

> gradient images still take up the same in-memory space as any other
> image of their size.

This is not a requirement for conformant rendering of either linear or radial gradients.



Tab:
> Sizing the gradient with cover/contain
> --------------------------------------
> As I previously argued, the fact that multiplying an ellipse's size by
> sqrt(2) converts it from inscribing to circumscribing a rectangle is
> non-obvious.  Brad discovered this fact through experimentation, but
> if you do so it's still non-obvious that this is always true and can
> be relied on.

In case you'd like to incorporate it somewhere for reference, here are my notes from March:

// Elliptical Radial Corner Sizing Math
//
// http://www.w3.org/TR/2011/WD-css3-images-20110908/#radial-gradients

// ‘closest-corner’ and ‘farthest-corner’ size the gradient-shape so that it
// exactly meets the closest or farthest corner of the box from its center,
// respectively. If <shape> is ‘ellipse’, the gradient-shape has the same
// ratio of width to height that it would if ‘closest-side’ or ‘farthest-side’
// were specified, as appropriate.
//
// Excluding the offsets, the ellipse equations are:
//
//      closest-side                closest-corner
//
//       2        2                  2        2
//      x        y                  x        y
//      --   +   --   =   1         --   +   --   =   1
//       2        2                  2        2
//      a        b                  A        B
//
// The second sentence from the spec above speaks to maintaining aspect
// ratio, and thus defines another equation:
//      a / b = A / B
//
// From this we can simplify:
//  1. Solve for B relative to a, b, and A in the ratio equation:
//      B = A * b / a
//  2. Substitute a and b into the closest-corner equation for x and y:
//      a*a/A/A + b*b/B/B = 1
//  3. Replace B using equation from step 1:
//      a*a/A/A + b*b/(A*b/a)/(A*b/a) = 1
//  4. Simplify second term on the left:
//      a*a/A/A + b*b*a*a/A/b/A/b = 1
//      a*a/A/A + a*a/A/A = 1
//  5. Multiply both sides by A*A:
//      2*a*a = A*A
//  6. Solve for A:
//      A = a * sqrt(2)
//  7. Solve for B using equation from step 1:
//      B = A * b / a
//      B = a * sqrt(2) * b / a
//      B = b * sqrt(2)
//
// Conclusion:
// The length of the X axis for closest-corner is sqrt(2)
// times the X axis for closest-side.  Similarly for Y axis.
//
// Note: Farthest-corner and farthest-side behave similarly.



Tab:
> In other cases, in order for background-size to have the same effect
> as an explicit gradient-size, you need to pair it with
> background-repeat:extend, which otherwise has relatively little
> justification.  Solving the sizing problem directly in the type of
> image that needs it seems like a slightly better idea.

Also, as previously observed, the "background-repeat: extend;" keyword doesn't exist in any CSS draft (yet?) so it's a "vapor property".  Replacing functionality directly present in a WD with a cobbling together of other properties *including* vapor properties is unwise IMO.

Received on Saturday, 1 October 2011 00:20:34 UTC