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

RE: [css3-images] Simplifying radial gradients

From: Brian Manthos <brianman@microsoft.com>
Date: Tue, 20 Sep 2011 07:46:10 +0000
To: Brad Kemper <brad.kemper@gmail.com>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D17168D35@TK5EX14MBXC266.redmond.corp.microsoft.com>
> 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.

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

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


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

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.  Comingling background properties with the internals of the brush is a step in the wrong direction.  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.

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.


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

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



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.


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?

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

 
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.
Received on Tuesday, 20 September 2011 07:46:42 GMT

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