Re: [css3-images] Simplifying radial gradients

On Tue, Sep 20, 2011 at 12:46 AM, Brian Manthos <brianman@microsoft.com> wrote:
> 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.

If you're going to use a silly example, at least make it accurate.
Only the letters J, Q, and X are used in less than 5% of the words in
English.  Y is comparatively popular at just under 20%.  (Based on
Chrome's hunspell dict.)

Brad's point stands.  Your argument is specious.  The point of an
alphabet is to write all the words in a language.  The purpose of CSS
is not to express all visual effects, but rather just to expose a
useful subset of effects in a simple-to-use manner.


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

It's only wordplay if you actually make up numbers and have no
supporting examples.


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

Brad is not arguing to expand the capabilities of the background
properties in any way.  (Well, except for background-repeat:extend,
but that's actually my hobby-horse, and it's useful regardless.)


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

One possible answer is "make the gradient in SVG".


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

The value added is simplicity.  Writing a *-gradient() function is
much simpler and terser than writing SVG, for the values that can be
expressed.


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

Note that either proposal would be a strict subset of what's currently
in the draft.  Adopting such would be almost purely a matter of
removing code.

~TJ

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