RE: [css3-images] Simplifying radial gradients

> 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

No it doesn't.  Having too many words confuses people.  This is why we all mess up English so often.  "We should just remove the more complex words to keep it simple.  If a 3rd grader can't understand it, it must be bad for the language because it's unfair to the underdeveloped mind."

It's exactly the same thing as what you're saying.  You're just too close to the "dumb down the syntax" premise to see it.

> 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

That's not what I said, and it's not what any draft has tried.  It's about exposing the full capabilities of linear and radial gradients.  Your proposal removals ALL non-centered CSS3 gradients from module 3.  That's a significant step backwards that, as I've said, makes me think we're better off just considering not including it at all rather than including a playschool version of the feature.

> create the gradients that are needed by authors. There is a lot of
> value in keeping it simple.

You've made the assertion that your version is simpler.  Again, it's like saying "let's only allow 3 letter words".  Sure it's simpler, but that doesn't make it better.

If you want to make it simpler for the "just beginning to use the technology" folks, the right was is to address making the defaults / optional parameters solid rather than removing capabilities.  Again, when those capabilities are interoperably understood and time-vetted.

> >> 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.

The actual designs today is too narrow-minded.  Again, you call them unusual to marginalize them rather than recognizing that this is people exploring what you can do with the syntax.  Until it's in the wild unprefixed for a few years, it's hard to make any useful assessment of how much of the capability people actually found useful.
 
> > "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.

No, it's not.  It's the same reason why people like Alan have issues with premultiplied interpolation: CSS WG has made the decision that "it looks ugly" and taken a capability to do the "dirty looking" interpolations from them.

> >>> 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.

I don't accept your use of "most" here.  Let's say I have a div that's 100x100.  Ignoring fractional values, there 10,200 locations for the center of a radial gradient.  Only 1 of those 10,200 locations are supported by your syntax.  So only 0.009804% of the radial gradient renderings are included in your proposed syntax.  Less than 0.01% is not "most".

And that's if you choose the explicit sizing, ignoring for a moment the nuances of the implicit sizing options.

> Background-size can handle most of what the
> <size> keywords or explicit sizing in 'radial-gradient' does.

Incorrect.  Background-size has no way to let an author tap into aspect ratio, the current radial-gradient syntax does.  This is important functionality for those that want to use the same background-image property value across multiple box ratios without having to define separate rules for each, as well as for authors wanting to have similar flexibility for different device form factors.

> Background-color can extending the last color stop out to the rest of
> the image,

Doesn't work very well for repeating gradients, and again requires hard-coding of numbers based on a fixed aspect ratio.

> 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).

I haven't said or agreed to anything about 'background-extend', so that assertion is too broad.

And AFAIK, it's not a CSS3 property so you're taking functionality out of CSS3 with your proposal.

> 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.

Yes you are -- for all cases of radial gradient that aren't centered in the box.

> 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.

Actually you're doing the opposite.  You're proposal removes facilities internal to gradients-as-image and pushes authors to find a way to achieve them with other properties.  So you're making it *more* complicated rather than less.

> > 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.

They do not duplicate background properties.  You keep asserting they do, but they don't.

Again, how do you tile a quarter-ellipse gradient in your proposal?  Perhaps if I saw your proposed syntax, your mental model would be clearer.

> > 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?

Background-extend for one.

> 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.

Again, tiled quarter-ellipse.  Show me the syntax.

> > 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.

Yes, so is completeness so we don't have to "immediately" revise it in CSS4 because we gave authors a crayon instead of a useful design tool.

> 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.

That's an argument for adjusting the syntax or defaults, not for removing capabilities.  At least IMO.

> >> 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.

It's an example of a rendering, a rendering currently supported by the syntax and that you're proposing to render.

A box-centered ellipse isn't a gradient either.  It's a rendering of a portion of the infinite brush containing a gradient.

No, it doesn't show that.  You're projecting.

What I'm arguing for is retaining the notion that CSS radial gradients represent a rendering of a rectangular portion of a brush, where the center of that rectangle and the center of the gradient do not have to coincide.  You're proposing to take away that functionality, and related keyword-based flexibility as well.

> 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.

Wait, now you're making the argument that we shouldn't bother doing functional syntaxes for <image> and just do everything as rasterized BMP, GIF, JPG, and PNG files?  You lost me.  Why are we even talking about doing gradients -- radial or linear -- at all in CSS if you have that opinion?  Might as well throw out SVG too.

> 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.

Perhaps that's because none of the browsers implemented until somewhat recently (2011).

> It is not like authors couldn't create that before now, they just
> haven't needed to or wanted to.

... or it was just too expensive and inflexible (to pay the rasterized image tax).

> >>> 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

Partly because we've circularly discussed linear a bit too much, IMO.  Comparing quality based on volume of alias email volume seems like a bad approach.

> 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.

Actually, that's debatable, but I'm hopeful.

> > 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.

No, I'm saying the existing capabilities have value that you're taking away from authors.  So much so that I suspect many authors will just walk away from CSS gradients because on the march from prefixed to unprefixed we'll have made it suck.

For better or worse, prefixed implementations have been around a while and the expected feature set is somewhat established.  As part of the process, the syntax has changed in some subtle and not-so-subtle ways (linear coordinate system, keyword direction changes, etc.) but -- for the most part -- across those changes an old rendering could be achieved with the new syntax by making some minor adjustment.  Your proposal changes that -- you're removing capabilities entirely.  I'm against that proposal.


If you'd like to amend your proposal to leave radial-gradient alone and add radial-gradient-simple (or whatever) then I could maybe get behind that.

Received on Tuesday, 20 September 2011 17:27:00 UTC