Re: [css3-images] Simplifying radial gradients

On Sep 19, 2011, at 6:44 PM, Brian Manthos <brianman@microsoft.com> wrote:

> I disagree with the overall premise.
> 
> My understanding was that the intent of direct gradient support in CSS was to move away from people using bitmaps.  One could argue that SVG allows you do the same thing, so then the question becomes:  Why do it in CSS at all?  

Because CSS is a language that is simple and easy to understand and learn by ordinary people. It is optimized for that, usually. With SVG, the raw power is more important, which is why there are many more CSS authors than SVG authors, and why SVG is more likely to be written by software than by authors typing it out. There is a place for each approach, and when the complexity of the CSS makes it as hard to learn or understand as when reading or writing SVG code, then CSS loses a lot of it's appeal for the broad niche it currently occupies. 

If radial gradients can be simple and still fulfill 95+% of the authorial needs, then that's the right approach, IMO. That is a large benefit that makes it worth doing. But it's not worth it to add complexity that makes it hard to learn, in order to fulfill the more rare needs of creating edge case gradients (needs that are already being fulfilled by a different harder to learn language of SVG).

> One answer might be "because the cover, contain, nearest, farthest syntaxes directly interact with the 'box' and that's where much of the interesting power of the syntax comes from".  

But that power is already largely present in background properties. You can easily size the background by percentages and offset it, and retaining a 'circle' keyword and letting it give the image an intrinsic aspect ratio gives you some more of that sort of power. Most gradients usually don't have hard edges that have to line up with anything with any kind of precision, so it is pretty easy to adjust percentages to get something suitable for the design needs. 

> I think that captures some of the value, but doesn't capture all of it.
> 
> I've come to appreciate the power that the current spec's flexibility with gradients provides.  Putting on my author hat, the neutering of that capability by dumbing it down as described below would make me just use SVG instead so I see it akin to just saying "why don't we just remove radial-gradient from CSS entirely".
> 
> Easily 90% of my sample pages can't be rendered with the syntax below.  Granted, that's skewed because my sample pages test many of the "interesting cases" heavily.  Nonetheless, it's a data point.

I think it is skewed, and that your needs to create interesting edge cases is not indicative of its general value to a wider audience of Web authors. Web authors writing real Web pages are who we should be designing it for, and a simpler syntax would serve well over 90% of their radial gradient needs. Making something that is easy for more widespread uses, without complicating it to serve very unusual cases (and cases where the end result often doesn't even look like what anyone would call a gradient) is not akin to removing radial-gradient from CSS entirely. Except for you (and those like you), but you admit to being able to use SVG to good effect anyway. 

> 
> -Brian
> 
> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
> Sent: Monday, September 19, 2011 6:24 PM
> To: Brad Kemper
> Cc: Brian Manthos; www-style@w3.org
> Subject: [css3-images] Simplifying radial gradients
> 
> Brad recently sent an email with feedback on radial gradients, arguing
> for a significant simplification.  Below I quote only his conclusions;
> his full email can be found at
> <http://lists.w3.org/Archives/Public/www-style/2011Sep/0019.html>
> 
> On Sun, Sep 4, 2011 at 11:37 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> • Explicit sizing within the image offers no advantages over 'background-size', aside from the entirely theoretical and unlikely or rare use outside of backgrounds.
>> • 'farther-side' is only useful when there is a offset center within the image. But such offsets within the image are not necessary, because the entire image can be positioned within the background positioning area.
>> • 'closest-corner' is not useful.
>> • Limiting the implicit sizing keywords to 'contain' and 'cover' would be more than enough power to include, and would simplify the understandability of the syntax. Since 'cover' is the same as ('contain' x 142%), the syntax can be simplified even more, and eliminates multiple way of doing the same thing. This simplification would be a great benefit to authors and learners, with little to no downside.
>> • Letting all radial gradients be 'contain' has a slight expressive advantage (for when you want a hard edge color stop to just touch the sides) over letting them all be 'cover', without giving up any of the power to create gradients that do cover.
>> • Letting the 'circle' keyword create an implicit aspect ratio for the image will benefit authors positioning a round gradient that has width or height that is based on a percentage of the background positioning area.
>> • Adopting a more limited approach now for CSS3 images does not prevent us from adding back in more controls for CSS4 images if there turns out to be a greater demand for it (which I still consider unlikely).
>> • Having a syntax that is nothing but color stops and an optional "circle" keyword is so simple that anyone can quickly and easily learn it, without having to understand complex interrelationships of more complex syntax. Given that these type of images will most often be used almost exclusively in backgrounds, it will be sufficient to use existing background properties for position and size.
>> • Any radial gradient needs beyond those can be handled with this simpler syntax are more appropriate for SVG. We already have this distinction for linear gradients, to great effect, and we should carry the same guidance into designing the radial-gradient syntax.
>> • The need for radial gradients starts out being small compared to the need for linear gradients. The need to offset the gradient within the image or size the gradient within the image for gradients appearing in non-backgrounds, or in places where they cannot be sized or positioned by other means (mostly this is list markers and border images) extremely minor, and we should not be adding complexity to the syntax for just those rare and limited cases.
> 
> His proposal is to simplify the syntax to:
> 
> radial-gradient( [circle,]? <color-stop># );
> 
> With this, gradients would automatically be centered and use "contain"
> sizing.  The 'circle' keyword would switch between a circular and
> elliptical gradient.
> 
> Overall, I'm sympathetic to his arguments.  Linear gradients have been
> simplified  significantly due to feedback.  Radial gradients have
> received much less feedback, and so probably have received less
> pressure to simplify.  As well, it is true that most of the complexity
> doesn't appear to be needed for the non-background uses of radial
> gradients - they'd generally be okay with a centered box-filling
> gradient.  Much of the complexity isn't strictly needed for background
> uses, either - most of them can be addressed by the
> background-position/size.
> 
> One of the reasons for the complexity was specifically to address
> Transitions - Simon argued that we should always be able to represent
> the intermediate forms (so that, for example, we can return it if
> getComputedStyle() is called in the middle of a transition).  I agree
> with this, but I've also come to believe it's less of an issue.  The
> best-looking linear-gradient transitions can, barely, be expressed
> within the linear-gradient syntax, but it would be probably be clearer
> to explicitly do something like "transition(<gradient 1>, <gradient
> 2>, <percentage>)" (basically, the cross-fade() function, just
> generalized for all transitions).  Something like transition() would
> probably be required for other types of transitions that we need to
> allow, like "height:200px" to "height:auto".  Once transition()
> appears, we could use it for representing the intermediate forms of
> radial gradients as well.
> 
> I disagree with Brad's assertion that it's acceptable to only use
> "contain" sizing and require authors to multiply their color-stop
> positions by sqrt(2) to achieve "cover" sizing.  The fact that this
> works requires some trigonometry work to figure out, and is not
> generally known.  At the very least, I'd argue that "cover" *must* be
> included.
> 
> An additional downside of simplifying as Brad suggests is that it
> becomes harder to both explicitly size a gradient and make the
> gradient cover the entire element.  This is useful for, for example,
> "spotlight" effects.  This can be solved by making the gradient
> extra-large (say, 200% 200%), so the image always covers the full
> area.  This would also be solved by "background-position:extend",
> which may show up in B&B4.
> 
> Another downside is performance-related.  To position a gradient in
> the upper-left corner, for example, you'd have to do:
> 
> background-image: radial-gradient(white, black);
> background-size: 200%;
> background-position: 100% 100%;
> 
> This produces an image four times as large as the element, even though
> you'll only be using a quarter of that, which is somewhat wasteful of
> system resources.  I'm not sure how big of a deal this is, though.
> 
> 
> So, with this taken into account, a possible simplification is the following:
> 
> radial-gradient(
>  [ circle || [cover | contain], ]
>  <color-stop>#
> )
> 
> ~TJ
>

Received on Tuesday, 20 September 2011 05:04:55 UTC