Re: Proposal: <star> element

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.


On Thu, Apr 10, 2014 at 2:36 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>wrote:

> Hello,
>
> due to the requirements, it was already rejected to introduce a star like
> element in SVG 2:
>
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Polar_element
> (it references my proposal including examples and a PHP-script simulation
> the
> appearence and usage of such an element)
>
> Previous attempts to provide a specific element only for regular polygons
> (convex or not convex) comparable to your proposal was already discussed
> earlier and it was rejected, because it was assumed, that it does not have
> enough use cases, therefore my proposal tries to cover much more use cases
> and allows to extent the simple shapes to complex objects straight forward.
> I think, inkscape has some different approach, easier for some simpler
> shapes,
> but far less general than my proposal.
> Furthermore with the new path command for bearing, the simple use cases
> like convex or not convex regular polygons (and some more shapes of
> discrete
> rotation structure) are already covered now, but obviously using this in
> the
> path element without semantic meaning requires the use of the elements
> title
> and desc to give information, if a specific named object is realised.
> Finally the existence of this new path command limits the usefulness of a
> specific element just for regular polygons even more as before, when such
> elements were already discussed and rejected.
>
> The question here is, if a simple approach is not sufficient and its use
> cases
> are already covered by the new path command and a more general approach
> is rejected and the computation is left to scripts of the author, what
> could
> be a successful proposal for objects with discrete rotation symmetry
> (including an option to break the symmetry if required)?
> I still think, that something like the polar element from my proposal could
> be pretty helpful for authors, especially if they not only want to compute
> such shapes with their own script but want to apply declarative animation
> to such a shape as well (a simulation with a current path element has
> always the tendency to blow up the souce code to several Megabyte per
> animation element, effectively excluding the publication of such
> documents).
>
>
> At least it was accepted to introduce some path notation with polar
> coordinates:
>
> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Polar_coordinates_for_paths
> but this did not appear yet in the SVG 2 draft.
> Maybe helpful to continue the discussion here?
>
>
> Olaf
>
>
>
>