- From: Stephen Chenney <schenney@chromium.org>
- Date: Thu, 13 Feb 2014 09:11:06 -0500
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <CAObCcUqzqUo=NULDjwyq5tSL=3Zv1Ntx2-PC9m=67yJjCoSotA@mail.gmail.com>
On Thu, Feb 13, 2014 at 12:14 AM, Cameron McCormack <cam@mcc.id.au> wrote: > Hi Olaf, > > > Dr. Olaf Hoffmann wrote: > >> In detail: Alternatively to a number representing an angle in degree, it >> would be useful to be able to note number1/number2. >> This expression represents a fraction of a full turn. >> In case number2 is accidently noted as 0, one can define 0 degree as >> rotation. >> >> Advantages: >> a) Authors do not have to calculate the approximate angle >> in degrees and do not have to bother about residuals from rounding this >> number. >> b) This gives more accurate (semantical) information about the intended >> shape than rounded numbers, therefore it is simpler to identify the >> intented >> meaning or purpose of a shape. >> > > You're right there would be an advantage to allowing fractions in here for > values like 1/7. On the other hand we don't allow numbers to be expressed > like this anywhere else in SVG. > > For stars, pie charts, etc., which are the kinds of things that I'm > thinking the bearing commands will be used for, fractions of the form 1/n > would be appropriate. I wonder though whether people would want to have > more complex expressions, like "0.5 + 1/7". (Of course they can just > compute that to "8/14".) > > People have previously asked to be able to use CSS length values in the > middle of path data strings, and <polygon> points attributes. Although we > hadn't planned on doing that right now, as it's quite a change, it would > let you do fractions using calc(). > This makes the most sense to me, as it re-uses existing spec and is more powerful than randomly enabling fractions for one particular attribute. > I think if we allowed fraction values, implementations wouldn't > necessarily perform their path/bearing calculations using fraction values > but instead still work with floating point. > >
Received on Thursday, 13 February 2014 14:11:41 UTC