RE: Proposal: <star> element

I agree both that 
a) stars and regular polygons are pretty darn common elements in graphics in general and on the web. Google "star" and I get 20 billion hits. Googling "polygon" which is already in SVG, gives me only 7 million. Of course it is not clear that (in ANOVA terms) there is not a keyword-by-image interaction, but the mere strength of the main effect would hardly be washed out by any statistical interaction, one would guess.
b) having the angular thing in path syntax certainly helps -- if there were a repeat subcommand to allow seven iterations of rotation 6pi/7, for example that would be even easier.

I use a little drawing program I wrote a zillion years ago that generates N-pointed stars and gives nice coordinates without too darn many decimal places. I think SVG-edit may have that now, though am not sure about Inkscape and Illustrator's ability to control precision.

Having it in <path> will mean that we won't have to worry so much about precision!

Cheers
D

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Thursday, April 10, 2014 3:04 PM
To: Philip Rogers
Cc: Dr. Olaf Hoffmann; www-svg@w3.org
Subject: Re: Proposal: <star> element

On Thu, Apr 10, 2014 at 11:49 AM, Philip Rogers <pdr@google.com> wrote:
> Adding <star> means every SVG user/implementation will need to carry 
> around the star generation code. This will be a net-negative for users 
> unless we have data showing hand-authored stars are sufficiently 
> popular[1]. There may be an argument here for <triangle> but my 
> intuition is that neither stars nor polar coordinate path primitives meet this bar.
>
> Dr. Olaf Hoffmann,
> Both <star> and polar coordinates for paths would certainly be helpful 
> for some authors. My worry is that these proposals make SVG larger, 
> slower, and more complex in order to support a small subset of users. 
> Do you think we might be able to extract out a subset of your request 
> (possibly as a tool or separate spec module) that would benefit SVG 
> authors without burdening existing tools and implementations?
>
>
> [1] One way to collect this data would be to scrape Wikipedia's SVG 
> corpus and determine what percentage includes non-trivial paths with 
> radial symmetry.

Also, note that Web Components, when applied to SVG, allow authors to use their own <star-> elements (or whatever name you want) with whatever semantics and abilities they want. They're sharable, too.  We can then lean on that data in the future to see what kinds of components are really popular, to see what is useful to bake into SVG proper.

(That said, stars and regular polygons really are common.  I avoid using them in my SVG because they're so *frustrating* to write - I have to do freaking trig to make a pentagon, and that's ridiculous.
However, <path> with the new bearing commands makes it a lot less annoying to write, so maybe it's sufficient to lean on that for a while instead of making a new element.  I dunno.)

~TJ

Received on Thursday, 10 April 2014 21:41:51 UTC