- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 30 Sep 2011 16:51:21 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: Brian Manthos <brianman@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
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. In particular, I can justify the following features: Positioning the center of the gradient -------------------------------------- Creating a gradient positioned centered on the side or corner of the box still seems pretty useful and simple. Achieving this in the manner that Brad suggests (make an extra-large gradient and position it with background-position) suffers on both usability and possibly efficiency concerns. The technique to position a background image that is larger than the background positioning area is unintuitive, as demonstrated by the fact that Brad got it wrong while defending the feature. As well, creating an image 2 or 4 times the size of the background positioning area is potentially bad for performance - gradient images still take up the same in-memory space as any other image of their size. Given the functionality of positioning a gradient on the side or corner of the positioning area, allowing the full range of <position> values is a minor complexity hit for a minor feature gain. This functionality is put to decent use on existing sites, such as <http://tweeplus.com/>. 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. Even if you *do* know that, it's still a burden to multiply either your size or your color-stops by 1.42. Thus, both cover and contain have a place. I have less justification for the closest/farthest-corner/side values. They are potentially useful for sizing a circular gradient, since it often has two choices for what to size itself to, but I don't think that's too valuable. Sizing the gradient with explicit sizes --------------------------------------- Brad gives a good example in his email about how relying on implicit sizing can make for some confusing and verbose gradients sometimes. He shows an alternative implementation with all the gradients centered and then background-position'd into place, which is much simpler. However, it only works because all the gradients used in this pattern happen to be the same size, which doesn't have to be true - variant heart patterns may be other sizes. As well, either an explicit gradient-size or a px position for the color-stops would make the gradient equally simple. 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. So, conclusions. Most of the features have decent justifications. While they do make the syntax more complex, I don't think they make it *too* complex. The one bit that I would still consider dropping are the four corner/side keywords for sizing. However, I'm inclined to keep them unless someone really hates them and at least one implementor agrees we should drop them. ~TJ
Received on Friday, 30 September 2011 23:52:10 UTC