Re: [css3-images] simplifying radial gradients

On Oct 7, 2011, at 4:07 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Fri, Oct 7, 2011 at 3:25 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote:
>> Whatever you think is more helpful. I'd personally start
>> with something even more pedestrian and understandable to
>> a larger audience. Take these two popular gradient demo
>> pages:
>> 
>> Lea Verou's pattern gallery: http://leaverou.me/css3patterns/#
>> Estelle Weyl's gradient page: http://www.standardista.com/cssgradients/
>> 
>> For each - or a large subset of them - I'd like to see either the
>> equivalent based on Brad's proposal. Or an indication that it wouldn't
>> be doable.
>> 
>> Is it a perfect test ? No. But given where we are, I think it's fair
>> to assess a simplification proposal in terms of the impact it would
>> have on authors' ability to do what they already do.
> 
> Most of the patterns in Lea's gallery don't use any sizing or
> positioning at all, only color-stops, and so are equally doable with
> either the current syntax or Brad's suggested change.  They would all
> need their color-stop positions divided by sqrt(2), though, as Brad's
> suggested default sizing behavior is "contain".

IIRC, converting them is a matter of multiplying by 1.72 (or thereabouts). 

Note that this doesn't mean taking some intuitive measure and converting it. Either syntax requires finding good color stop placement through trial and error, or by doing multiplication/division of the gradient line length. . 

> There are only a few that seem complex enough to be relevant:
> 
> 1. <http://leaverou.me/css3patterns/#hearts>  This pattern is authored
> in a confusing way, because Webkit/Gecko don't currently support
> explicit sizing, which would make this much simpler.  It is possible
> to write it in an equally simple manner that is compatible with Brad's
> suggested syntax.

And in fact I did so in that earlier lengthy e-mail. 

> 2. <http://leaverou.me/css3patterns/#waves> This cannot be reproduced
> in Brad's suggested syntax.  It relies on the ability of the current
> syntax to create a "half-ellipse".

Agreed. But I wouldn't think of that pattern as a gradient. It is a hack to use a gradient syntax in order to draw a non gradating pattern tile. Same goes for "hearts", too. 

> 3. <http://leaverou.me/css3patterns/#yin-yang> This cannot be
> reproduced in Brad's suggested syntax, for the same reason as #2.

Same response from me as #2.

> 4. <http://leaverou.me/css3patterns/#seigaiha> Same as #2.

Yep. 

On the other hand, I am reconsidering my stance on bg-position within the gradient image. If still adds a complexity, but it was limited to sides and corners, the way linear-gradient is (maybe even with 'from' keyword), and the way you suggested recently before changing your mind, then it would still be much less complicated than if any bg-position was allowed (percentages, lengths, etc.). Then if you had a color stop at, say, 10%, that would always be either 10% of the width or 10% of half the width of the image itself (substitute the words "narrowest dimension" instead of "width", if the 'circle' keyword is used). And you gain easier alignment with element edges/corners. For arbitrary placement in a background, 'background-position still works well. 

It is really the changing of the gradient path length in multiple ways that makes it so complicated and hard to conceptualize in one's head, when you start combining gradient sizing  (explicit or by keywords, in two dimensions) with all the ways you can change the path length by moving the center around by random amounts vertically and horizontally, and then combining all that with the often unexpected ways that they interact with 'circle'. But I can see the value of having an easier way to align the centers with edges and corners of the element background, than trying to percentages in background-position. 

> Estelle's are similar - many of them use only color-stops, or
> color-stops plus 'contain', the latter of which would just require
> dividing all the color-stop positions by sqrt(2) under Brad's
> suggested syntax.  

See response to similar comment, above. 

> A few are complex enough to be interesting:
> 
> 1. Apples.  Again with the need for half-circles.  This is pretty far
> down the "you should be using SVG" trail, though.

Right. I don't think we need to have extra complexity in something called 'radial-gradient' just to serve a separate desire to draw little pictures of things. Drawing a wide variety of pictures is part of what SVG exists for; 'radial-gradient' should be optimized for drawing radial gradients. 

> 2. Radial Hearts.  Once again with the need for partial-ellipses.
> These aren't quite half, but they do rely on the part of the gradient
> outside the drawing area being clipped.  They could probably also be
> simplified a little bit with explicit sizing.
> 
> Overall, most of the gradients displayed in these two galleries do not
> use any complex sizing or positioning at all, and wouldn't be altered
> if those were dropped.  Several rely on the simple sizing of the
> 'contain' and 'cover' keywords, and would have to alter their
> color-stops in a non-obvious way under Brad's proposed syntax.  

I really think you are exaggerating the difficulty of just using color-stop  positions instead of separate sizing via keywords. If the 100% color stop was always to the side, then it is a very simple matter to create a color stop that is greater than 100%. And even if you go slightly past the corner, it's rarely going to make any difference to the design. It is a good thing to be able to rely on 100% being in the same relative place all the time. If the gradient line is measured from left to right, then it is intuitive for 100% be where it intersects the right edge. This also makes it more conceptually consistent with linear gradients. 


> A few
> from each do require the more complex syntax currently in the spec,
> mostly relying on the fact that half of a gradient is not displayed if
> you position the center on one of the sides.  A few would be
> significantly simplified by explicit sizing, but may also be amenable
> to using background-size.
> 
> ~TJ

Received on Monday, 10 October 2011 21:33:23 UTC