- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 16 Oct 2013 14:43:05 -0700
- To: www-style@w3.org
On 10/16/2013 01:53 PM, Alan Stearns wrote: > On 10/16/13 1:46 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote: > >> On 10/09/2013 11:33 AM, Alan Stearns wrote: >>> >>> And this would introduce a dissimilarity between how percentages are >>> handled on x,y arguments in rectangle() versus how they are handled >>> in polygon() >> >> Well, polygon() is a series of points, whereas rectangle() is a size >> and a position. So I don't this concern is valid. If you're looking >> for a rectangle function that works like polygon(), then you want >> rect(): it is two pairs of coordinates defining a rectangle, just >> as polygon() is multiple pairs of coordinates defining a polygon. >> >> Does that make sense? > > A while back you had brought up the possibility of the first x,y > coordinate in polygon specifying a <position> that the rest of the x,y > points were relative to. I was assuming that would be the start of a > CSS-style shape(polygon ...) function, and that the use of <position> > there could be made consistent with a CSS-style shape(rectangle ...) > function. No, I was thinking to just add more arguments to the first "global setup" argument in polygon(), before the list of points, kindof like gradients have all their parameters in the inital "global setup" argument, followed by a list of colors. I'm not sure yet what those arguments would be, but I'm happy to leave that to another level. There is space for them currently, so I'm not concerned. But anyway, my point was, rect() is the analog of polygon(), not rectangle(). :) ~fantasai
Received on Wednesday, 16 October 2013 21:43:32 UTC