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

Re: [css3-images] Simplifying radial gradients

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 30 Sep 2011 16:51:21 -0700
Message-ID: <CAAWBYDDB0GyFc+9mcAKvbxfcX2kwjbMnHQuTP=W6bzmorQkf0Q@mail.gmail.com>
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 GMT

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