W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Re: [css3-images] Proposed Gradients changes

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 29 Nov 2010 18:12:35 -0800
Message-Id: <0619578E-8CAB-4AEB-92CC-FEF5F8245E05@gmail.com>
Cc: Rik Cabanier <cabanier@adobe.com>, www-style list <www-style@w3.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>


On Nov 29, 2010, at 5:06 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Mon, Nov 29, 2010 at 5:00 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Nov 29, 2010, at 4:48 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>> On Mon, Nov 29, 2010 at 4:10 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>> If Filters are the primary benefit of duplicating background capabilities inside gradient images, then please enlighten me about how that works. Is there a Filters draft that explains how images are used in filters? I thought CSS Filters were going to use SVG functionality. Doesn't SVG have it's own way of generating gradients that is as complex as anyone could ever want?
>>> 
>>> There is not yet a draft for such, though I believe that one will be
>>> forthcoming relatively soon.
>>> 
>>> From discussions, I believe that CSS Filters will expose the
>>> functionality of SVG filters in a functional manner, so that you can
>>> provide source images and pass them through filters (these source
>>> images may be actual images or discrete layers of elements, like all
>>> the backgrounds or all the text or whatever).
>> 
>> So it may be fine, or even preferable to use more powerful SVG gradients for filters instead of CSS gradients (which should be more optimized for easy learning and typing and reading by authors).
>> 
>> I'd rather see us start out with the simplest version of CSS gradients and only add extra arguments to the function if they are really needed. The existing way of getting pictures into CSS, url(), only has one argument after all. This should also help us to more quickly get matching implementations, and widespread author understanding of the essentials.
> 
> I agree.  I'm dropping the <angle> argument from radial gradients
> right now, actually, for precisely that reason.
> 
> Now, do you believe that it's easier to learn, type, and/or read to do:
> 
> background-image: radial-gradient(silver, white);
> background-position: -50% -50%;
> background-size: 200% 200%;

For this one, I'd already know 'background-position' and 'background-size' (or will need to anyway), and can write them more briefly using shorthand, so the new thing would only be' radial-gradient(silver, white)', which is simple and short to an extreme. So as a learner, it is almost nothing to understand and type. 


> ...than:
> 
> background-image: radial-gradient(top left, silver, white);
> 
> ?

There is not a huge difference in typing "-50% -50% 200% 200%" instead of "top left". Sure, it's a few more keystrokes, for a somewhat less common need. But I think it is worse to have duplicated functionality inside the image, creating multiple ways to do the same thing, with very little gain. Maybe if it was only edge names and 'center' to add to the syntax it wouldn't be that bad (and similar to linear-gradient). But there are all these other bits and bobs too (cover, contain, closest-corner, closest-side, farthest-corner, farthest-side, circle, ellipse, explicit lengths and percentages), that also must be learned and are also mostly redundant, which turn a very simple thing into a collection of unneeded complexities. No offense, but I'd call it over-engineered. 
Received on Tuesday, 30 November 2010 02:13:18 GMT

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