From: Brian Manthos <brianman@microsoft.com>

Date: Sat, 1 Oct 2011 00:20:03 +0000

To: Tab Atkins Jr. <jackalmage@gmail.com>, Brad Kemper <brad.kemper@gmail.com>

CC: "www-style@w3.org" <www-style@w3.org>

Message-ID: <9710FCC2E88860489239BE0308AC5D17EF4425@TK5EX14MBXC266.redmond.corp.microsoft.com>

Date: Sat, 1 Oct 2011 00:20:03 +0000

To: Tab Atkins Jr. <jackalmage@gmail.com>, Brad Kemper <brad.kemper@gmail.com>

CC: "www-style@w3.org" <www-style@w3.org>

Message-ID: <9710FCC2E88860489239BE0308AC5D17EF4425@TK5EX14MBXC266.redmond.corp.microsoft.com>

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

*
This archive was generated by hypermail 2.3.1
: Monday, 2 May 2016 14:38:50 UTC
*