Re: Request for Future Feature: Star Element

Doug Schepers wrote:
> | 1 the size and complexity of the standard, 
> 
> Let's put this into perspective. The entire page for basic shapes is only
> one of 23 in SVG1.1. In fact, it is one of the shortest normative sections
> in the entire Spec, comprising rather less than 5% of the length of the
> document. This is split up into roughly 6 sections, one each for 'rect',
> 'circle', 'ellipse', 'line', 'polyline', and 'polygon'. So, each of those is
> less than 1% of the Spec. Add to this the fact that they all inherit from
> the Shape Module, and you have a very compact footprint for each of those
> shapes. You could add half a dozen more and it would still be a very minor
> part of the Spec. There is no additional complexity necessary, such as
> dealing with transformations, viewboxes, etc. It's just a simple shape.

Doug, I agree with your arguments, I believe such a regular, generic
shape is indeed a useful addition to the SVG spec., alas which cannot go
to the spec. before the 1.3, if ever...

> | 3 the level of use this feature would get, 
> 
> Quite a lot, I suspect.
 >
 > | 5 the ease with which the same feature can be done by other means.
 >
 > As I've said before, it's not very easy to manage in a dynamic fashion.

I agree too. Not everybody is using graphical tool or code generators to
make their SVG files.
This has been already argued (is it only a small fringe or a signifiant
portion of SVG creators?) and unless a serious survey is made, this will
probably remain controversy.

> | With all this taken into account, I think that rectangles and 
> | ellipses do have a place in the standard (with some 
> | reservations, see below), but more complex shapes do not.
> 
> I would find it difficult to disagree more.

I concur!

> | Actually, we do use <path> not only for stars or spirals, but 
> | for ellipses and (soon) rects too. Reasons are simple:
 >
 > | So we decided
 > | that it's better to lose some level of semanticity in the SVG
 > | code that we produce than to subject the user to the
 > | restrictions that look completely arbitrary,

Perhaps that's too convoluted, but why don't you use primitives when
they are used "primitively", and convert them to path when user want to
do more funky stuff with them?

Oops, you mention this possibility below:

> | or than to 
> | implement a complex "smart switching"
> | code to store shapes either as shapes or as paths, depending 
> | on what is done to them.

Is it so complex? It can be if you want to revert to primitive,
otherwise, it seems quite easy.

> That, on the other hand, is a poor choice, in my opinion.

Sorry, but here I don't understand. What is a poor choice, to make the
"smart switching" or to choose not to do it?

> | (2) the ellipses are made a bit richer to be able to create 
> | arcs and segments.
> 
> Not sure I agree there.

Well, there is a demand on making pie charts easily... Current arc in
path is quite hard to use, and is lacking semantics...

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Received on Friday, 26 August 2005 08:41:58 UTC