Re: [css3-images] Simplifying radial gradients

On Sep 20, 2011, at 12:46 AM, Brian Manthos wrote:

>> From: Brad Kemper [mailto:brad.kemper@gmail.com]
>> Sent: Monday, September 19, 2011 10:04 PM
>> To: Brian Manthos
>> Cc: Tab Atkins Jr.; www-style@w3.org
>> Subject: 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
> 
> It's easy to play with made up numbers.  Why do we need all 26 letters in the alphabet?  Can't we just toss out Y because 25 is enough?  Certainly 95% of the words in most languages don't require the letter Y.

That is a specious comparison. An alphabet needs to needs to be able to create as many different words as can be said. That is not the priority for CSS. And certainly not for one type of image value. We don't need CSS to be able to create any gradient imaginable. We only need it to create the gradients that are needed by authors. There is a lot of value in keeping it simple.


>> 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).
> 
> It's also easy to call stuff that you don't want supported "edge cases" to marginalize them.  But that's just wordplay.

No it isn't. It is based on my observation that in most actual designs used on pages (printed or electronic), almost all with radial gradients could be accomplished with the simpler syntax. The only exceptions are the pages where people are writing about CSS and the unusual things you can do with it.

> "I think it's an edge case to use transparency in CSS.  Why would someone want to draw something invisibly?  Seems silly.  Let's just remove it 0 a valid alpha value from rgba."

Another specious comparison. Transparency and opacity are very valuable qualities to be able to style.

>>> 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
> 
> No, it's not.  Background properties *do* support some of the same capabilities that linear-gradient offers.  Radial-gradient is a whole 'nother ballgame, that the rect-based background properties don't even begin to handle.  And frankly, I don't think they should.

Background-position can handle most of what the <bg-position> in 'radial-gradient' does. Background-size can handle most of what the <size> keywords or explicit sizing in 'radial-gradient' does. Background-color can extending the last color stop out to the rest of the image, if an image has been offfset, for instance (and 'background-extend, which we've all seemed to agree with in principle, would help even more).

Perhaps you can give some examples of real world designs that use gradients, that really need the extra capabilities of having these sort of properties inside the image instead of just inside the background. 

> As it stands, the model is simple: background images act as a brush to fill a rectangle.  How they arrive at what to fill that rectangle with is internal to the brush itself.  

I'm  not changing that. I'm just suggesting a way for the brush to be simpler, when the extra complexity is not necessary, so that no one needs to understand all the complicated ways in which its component values interact.

> Comingling background properties with the internals of the brush is a step in the wrong direction.  

Creating brushes that duplicate background properties inside them is a step in the wrong direction for CSS. It is fine for SVG or canvas, where simplicity is not as important as being able to draw anything at all.

> This is similar to why I have objections to having start/end/before/after as part of the gradient syntax; it introduces another entanglement of properties that aren't currently connected.
> 
> Part of your argument seems to be "let's dumb down radial-gradients, limiting what they can do as an image brush provider" combined with "and let's grow what background properties do, to try to fill in some of the gaps".  That's wrong headed, complicating background properties even more than they already are today AND keeping users from using radial gradients in other <image> contexts effectively. 

Where am I growing what background properties do, in order to take over from radial-gradient sysntax? We already have positioning and sizing in backgrounds (and repeating, though I have already ceded that battle). I thought 'background-extend' was fairly non-conttroversial, but my arguments do not depend on it anyway. I've suggested a 'background-rotate' before, but that really has nothing to do with radial gradients, which is what we are discussing here.

> If you don't want to use the full capabilities of radial-gradients as in the WD, then don't.  But don't take that power away from authors that do.

My point is that simplicity is a good goal. Having complicated syntax that is rarely, if ever, needed, detracts from authors being able to learn it, or to understand what others have created. "Just because we can " is usually not a good enough reason for this group to create extra properties and values and complications.

>> 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.
> 
> A simple example...
> 
> How do you tile a half-circle gradient with background properties?  How do you use that half-circle gradient as a list-style-image?

A half circle is a shape. It is not a gradient in the typical sense of the word. This shows that what you really want is something that can create images of any shape. That is what SVG is for. 

What's more, it is a shape that is easily handled today via regular raster images, with very little downside to doing so, if an author wants that. Yet I don't recall ever seeing an actual Web page where a list-style-image was an image of a half circle with a gradient in it. It is not like authors couldn't create that before now, they just haven't needed to or wanted to.

>>> 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.
> 
> That's not what I was saying.
> 
> My point was simply that if there's no actual value over just using SVG, then why bother adding it to CSS at all?  Either you offer some value beyond what SVG provides, or keep CSS simpler instead of adding redundant functionality.

Oh come on. With that logic, we shouldn't have 'border' properties either, because they just add redundant functionality to what SVG provides. A large part of the value of using CSS over SVG is its simplicity and ease to understand and learn.

> That said, there's more to this story...
> 
> We've had long and deep discussions as well as a significant degree of interoperability above browsers.  And now you just want to reset and dumb it down to something new and different.  Why?  Why neuter half of a feature that has consensus in the CSS WD, and reset it?
> 
> Just because *you* want to only draw "centered in the box" ellipses doesn't mean that others don't want more than that.

We have not discussed radial gradients nearly as much as linear gradients. A lot of what came out of those linear gradients discussions was to make them simpler. Now they are very simple and easy to understand, and fulfill the needs of actual Web designers.

> Radial gradient grammar looks actually very similar to the grammar that it had at the initial addition to the spec in September 2009.
> http://dev.w3.org/cvsweb/~checkout~/csswg/css3-images/Overview.html?rev=1.8;content-type=text%2Fhtml
> So two years later, you take your deep look and decide "meh, let's scrap it" despite the vetting of time and implementation support?

No, I had similar reservations then, and also voiced them then. But most of my attention has been on linear gradients, as these are much more commonly used than radial gradients.

> Well just because that's your first deep look, doesn't mean that it's the first time for others -- including we implementers.

That is not a fair characterization. 

> I really don't understand the motivation to constantly rewind evolved specifications to first principles and then rebuild the wheel again.
> 
> Is there a goal to never have any of this converge?  I guess I just don't understand the CSS spec development model.
> 
> 
> Perhaps we should just move all Gradients to CSS.Never instead of torturing the early adopters by showing them a feature that will apparently near be mainstream, remaining a prefixed novelty. 

Is your point that these marginal capabilities are already in such widespread use that it would break the Web to change them? They are experimental, prefixed values whose syntax can change, and I don't think I am removing anything that can't still be accomplished in other ways.

Received on Tuesday, 20 September 2011 15:32:45 UTC