Re: [CSSWG] Minutes and Resolutions 2009-08-12

On Thu, Aug 13, 2009 at 3:19 PM, Brad Kemper<brad.kemper@gmail.com> wrote:
> On Aug 13, 2009, at 11:53 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> On Thu, Aug 13, 2009 at 3:08 AM, Robert O'Callahan<robert@ocallahan.org>
>> wrote:
>>>
>>> That seems far more complicated than what we currently have. By writing
>>> it
>>> as a 'gradient' rule you don't benefit background-clip,
>>> background-position,
>>> background-repeat, multiple backgrounds, and falling back to a background
>>> image. It's not extensible to other kinds of gradients, and doesn't
>>> handle
>>> repeating gradients. And even so,
>>
>> Agreed - it should stay as a functional notation denoting an image
>> that just happens to be constructed by the browser.
>
> I'm not sure what you are agreeing with. The rest of what you wrote is much,
> much closer to what I was proposing than to the Mozilla/webkit versions that
> Robert O' favors.

Agreeing with ROC on that point, that specifying a gradient as a
function that generates an image is better than making it a special
property as you propose.

>> The vast majority of gradients will, I believe, be simple 2-color
>> fades.  As such, requiring someone to write "from(white),to(black)" is
>> almost criminal when they could just write "white,black" or even
>> "white black".
>
> Right. Like I proposed.

In general, you and I are proposing *very* similar things.  Please
don't take offense when I specify something that appears identically
in your proposal.  ^_^

>> More complex gradients are also overcomplexified.  The vast majority
>> of complex gradients will be simple n-color fades, going from one to
>> the next in turn.  Again, it's criminal to then make someone write
>> "from(white),color-stop(50%,orange),to(black)" when they could just
>> say "white orange black".
>
> That's an interesting idea, letting the colors be evenly spaced when no
> distance is mentioned. Although I tend to disagree with the notion that one
> people start adding more than two stops that they will usually want them
> evenly spaced. I think the reasons for adding more than just start and
> finish colors (three or more stops would be minority use cases) would be
> more varied than that.

Perhaps true, but I don't think there's any reasonable way to
distribute the colors *except* evenly when their stops aren't
specified.  If you want more control, you just specify the stops, no
problem.  I figure that a 3-color equal-length fade is probably the
most common fade outside of the simple 2-color fades.  We don't lose
anything by allowing the shortening, and don't add any real complexity
to understanding the rule.

>> That is, specifying "white, green, orange, 66% blue, red, black"
>> would, in addition to killing my eyes, be equivalent to "0% white, 22%
>> green, 44% orange, 66% blue, 83% red, 100% black".
>
> That second part of your equivelency staatement is almost identical to what
> I was proposing for multiple-stop (more than two) gradients. All it's
> missing is an angle and a reversal of each of the paired values.

Right.  In this section I was *only* talking about color, so
direction/length/etc weren't aprt of what I was talking about.  Also,
my full proposal allows the color-stop production to be in either
order.

>> You can do LDB's
>> rainbow example without doing a lick of math, just by specifying each
>> color in turn.
>>
>> This does mean that the color list is now at least somewhat
>> order-dependent, which wasn't true before.
>
> That would be a problem if you wanted to mix fixed lengths and percentages
> in the same gradient, but I dont think that should be allowed, because of
> the odd results it can create.

Hmm, agreed.  I'm not sure exactly if we want to address that.  The
most common case when I'd want to mix the two is if I want the
gradient to *start* a length away from the edge, but then have the
color-stops be spaced with %.  You can do that with the start/end
points, so I think I may just prevent color-stops from mixing the two.
 Sole exception: allow the end point to still be 100%.  Like "white,
gray 200px, black" would be a 200px wide fade from white to gray, then
a fade from gray to black over whatever space is left.

>> First, I much prefer using "linear-gradient()" and "radial-gradient()"
>> to "gradient(linear,...)" and "gradient(radial,...)".  It lets you
>> describe the syntax of each type without having to worry about the
>> other - I found the webkit blog explanation of the gradient syntax
>> rather confusing because it mixed the radius argument in.  It'll get
>> *much* worse if we start allowing more keyword-heavy specifiers, a la
>> Brad's suggestion.
>
> Here I disagree. I don't think it is helpful to have two nearly identical
> properties, when the only difference between them is that linear need an
> angle but not a definition of what 100% means, and the reverse difference
>  is true for radials. And which one overrides the other? Or does one appear
> above the other if they ate both specified? No one will ever need to use
> both at the same time (unlike box-shadow and text-shadow), so they should
> just be one.

I'm not completely sure what you're talking about here, so I'll defer
to my fuller proposal, linked in a bit.  Tell me if you still disagree
with how things are done then.

> I am only including one slot for a keyword in mine, and just a lot of useful
> values, but they can be reduced down if you don't think they'll all be
> useful. I think "corners" would be pretty common for shaped radials, and
> maybe "longest-corners" if you want to keep the radial circular. I could
> also accept being able to substitue a fixed radius there with something like
> radius(200px).
>
>> Now, positioning.  For linear gradients, the standard 2-point syntax
>> works fine when it's necessary.  I have no problem with that at all.
>> However, I'd also like to use left/right/top/bottom in there.
>> Webkit's syntax allows it (FF's may too), but requires the use of
>> *two* keywords, frex "left top,left bottom" as used in the blog
>> example.  [...]
>>
>> You should also be able to specify an angle directly, rather than as
>> two points.  Use any of the degree units, normalized to within [0deg,
>> 360deg).  The gradient originates from the corner opposite a ray at
>> that angle; in othe words, [0deg,90deg] originate from bottom left,
>> [90deg,180deg] originate from bottom right, [180deg,270deg] originate
>> from top right, and [270deg,360deg] originate from the top left.
>
> Yes, this is what I was saying, regarding angles. Once you specify an angle,
> you dint need the top, right, bottom, left keywords at all. And it is easier
> to type 90deg than to type "bottom" for the start and "top" for the end. You
> say my propsal is keyword heavy, but it only required a single keyword for
> radials, while yours has two slots for utterly redundant keywords for all
> gradients. They're useless once you allow angles.

Actually, I don't think I said anything about your keywords, except in
a passing note - I actually like them a lot!  However, I disagree that
writing "90deg" is always easier to write or understand than
"bottom,top".  The latter seems *extremely* clear to me, while the
former requires me to remember the direction that 90deg points in.
That's fine when you need the fine control of angles, but I think
using side keywords is very worthwhile.

>> At this very moment I'm writing all of this up into a separate
>> proposal, which is much much shorter and more concise than the text
>> above.  I'll have a link for it by this evening.

Soon!

~TJ

Received on Thursday, 13 August 2009 20:51:55 UTC