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 19:04:19 UTC