On Sep 7, 2010, at 20:49 , Tab Atkins Jr. wrote: >> the first argument is one of the possibilities: b-t, t-b, l-r, r-l, bl-tr, >> tl-br, tr-bl, br-tl >> the second is an angle relative to that base vector >> the two combined give a computed gradient vector, and after that, >> everything falls out. > > Relative angles are actually a substantially different thing than the > current angles I use. It's impossible to use relative angles to just > say "give me a gradient at 45deg". I think that that is 45 degrees relative to the l-r line (i.e. x axis). > I think that in general relative > angles aren't very useful. (Personally, I think absolute angles > aren't too useful either, but I trust Brad when he says they are for > him.) > >> Transitions are then defined as interpolating between the computed gradient >> vectors, of course. >> >> Now we only need one syntax and we can interpolate, and so on. >> >> linear-gradient( base-direction, relative-angle, from-color, to-color, >> {stop%, stop-color}* ) where from-color is defined as from 0% and to-color >> is defined as to 100%. > > While this does let us unify, I think it loses too much useful > abilities that the current syntax offers. what do I lose? I think I lose the webkit cases where the start and end points are specifically given, which means that portions of the gradient <0 and >1.0 can be visible, but nothing from your proposal. (And the most complex here gives features yours does not have). David Singer Multimedia and Software Standards, Apple Inc.Received on Wednesday, 8 September 2010 16:59:59 GMT
This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT