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

On Aug 13, 2009, at 1:50 PM, "Tab Atkins Jr." <jackalmage@gmail.com>  
wrote:

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

I don't think that is what he meant, and it is not what I mean. He was  
talking in favor of functional notation within the value of his  
gradient property. I don't see any of what we've been mostly talking  
about as being a difference between me saying gradient should be a  
separate property (which is what Mozilla already has) and him saying  
it should be used in place of URL() as an image type (although he  
doesn't seem keen on that, either, actually). It's a little easier to  
discuss it as a property, but presumably turning it into an image  
would mean replacing "gradient:values" with "gradient(values)". Which  
I supported. And still do.

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

None taken.

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

Well yeah. I was saying to use the slightly more verbose form when  
doing more complicated gradients. Such as those with more than two  
steps.

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

All right.

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

I guess that would work for me then. I like to see it with the color  
first because it's easier to read that way (the optional percentage  
coming after the required color).

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

More or less the same as I envisioned, but what happens on a 100px box  
then? Does it end with black, or halfway between white and gray, or  
just gray? (I'd say B).

>
>>> 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 mean that if you have two different properties, then they can both  
apply. Doesn't matter if we are only talking about an image type  
though. But it's still early in that part of the discussion. I'd  
rather define one property or image type instead of two.

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

It wouldn't seem so from "It'll get
>>> *much* worse if we start allowing more keyword-heavy specifiers, a  
>>> la

Brad's suggestion.". But OK. My bad.


> However, I disagree that
> writing "90deg" is always easier to write or understand than
> "bottom,top".

It's certainly shorter. That makes it easier to write. And it's sinker  
(1 value instead if 2), so it is easier to understand.

> The latter seems *extremely* clear to me, while the
> former requires me to remember the direction that 90deg points in.

Is that really a concern? The keyword only apply to multiples on 90  
degrees. The only one I have to stop and think about is 270, which is  
why I prefer writing it as -90. But you could use turns too.

How about "bottom,right"? Still extremely clear. Sorry, but I REALLY  
don't see the advantage of using those words or the xy coordinate  
system that you'd have to include with them. They just aren't needed.

> That's fine when you need the fine control of angles,

Do far I've been mostly referring to multiples of 90 as being simpler.  
There are only four, and you can right them in different ways  
acvording to preference.

> 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 22:09:11 UTC