Re: Proposal: <star> element

Dr. Olaf Hoffmann and Paul,

I worry that the costs of <star> are not being taken into account.

Adding <star> will unnecessarily break compatibility with existing SVG
viewers, many of which do not have plans to support SVG2 (Presto, Batik,
etc). Additional spec complexity reduces the chance that a new SVG2
implementation will be written: the barrier to entry is already above what
a hobbyist can achieve. Lastly, the code behind even a simple feature must
be downloaded all users (with browsers this is now in the billions).

These are real costs and they are not worth the convenience of a handful of
authors. Instead of adding fun experiments as first-class features, we
should provide the primitives that let authors be creative without a
multi-year spec process. ShadowDOM is this primitive: it lets users build
<triangle>, <star>, <polar>, or <chiliagon>.


On Thu, Apr 10, 2014 at 7:09 PM, Paul LeBeau <paul.lebeau@gmail.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].
>
> The code is pretty simple.  It's a lot less ambitious than the <polar>
> element.  And for shapes with more than a few points, I would expect it
> would be quicker than parsing the equivalent path element.
>
> The bearing path commands can be used for producing these shapes, but
> working out the angles and getting the positioning right is going to be
> tricky for a lot of people.
>
> Paul
>
>
>
> On 11 April 2014 12:16, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:
>
>>
>> Philip Rogers wrote:
>> ...
>>
>> >My worry is that these proposals make SVG larger, slower, and
>> >more complex in order to support a small subset of users.
>>
>> This applies for all new elements.
>> But for documents, where this element is not used at all, there should be
>> no relevant difference, only due to the increase of the number of
>> elements,
>> a viewer has to distinguish.
>>
>> Well, if this new element is used in a document, indeed processing
>> can be much faster, because to simulate several issues, the file
>> size can increase dramatially by orders of magnitude.
>> Typically authors will not publish such large documents at all -
>> if you do not find it, it is no indication, that authors would not
>> use it, if it would be possible to have documents at normal size.
>>
>> Currently you will see almost no SVG documents simulating more
>> complex gradients as well for a similar reason.
>> For fun once I tried this with methods used in quantum chemistry
>> to guess initial charge distributions for atoms and molecules
>> as a start for numerical calculation of realistic distributions,
>> but the results became very big files, not worth to care about.
>> But there are now ideas to have elements and structures
>> for more complex gradients in SVG 2 - maybe those will help
>> some subset of authors to solve problems with acceptable
>> file size as well.
>>
>>
>> >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?
>>
>> Stars or objects with rotation symmetry or broken rotation symmetry are
>> surely
>> popular, but many of this can be covered with the new path command - and
>> what is not covered, will often not be published, if the simulation is too
>> complex or difficult, therefore difficult to say - counting the new path
>> command in file in five years for five years to see the relevance and
>> introducing this element in maybe fifteen or twenty years with SVG 4
>> is a quite frustrating promise for authors wanting to use it maybe
>> already now or a least in a few years ;o)
>>
>> About path data in polar coordinates - on the one hand, it is quite common
>> to use this for problems related to such symmetries, but beyond pie
>> charts -
>> maybe nobody knows, if people will really use Bezier curves in polar
>> coordinates to solve problems. This would be a nice and interesting
>> experiment. Here applies: No risk, no fun. As for many 'inventions'
>> and improvements, the future will show.
>> If we take a laser, today many people have some in daily use.
>> An old professor (atomic and molecular spectroscopy) told me once,
>> if they had seen, that this is somehow useful for everyone, they had
>> invented
>> something like dye lasers much earlier than the first laser was invented
>> (Maser/Laser ~1950/1960) -  they already had all devices and the light in
>> daily use,  they just did not see applications beyond their analysis of
>> atomic and molecular spectra and structures ;o)
>>
>> If the SVG group cares only about known applications and use cases,
>> there will be no surprising and exciting 'inventions' in SVG content.
>>
>> ...
>>
>> > >
>> > > [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.
>>
>> Not necessarily - if the simulation is too big or complex, you will see
>> PNG or
>> JPEG/JIF instead.
>> If you only look on what already is and what you know, you will miss, what
>> could be in the future ;o)
>>
>>
>> Tab Atkins Jr. wrote:
>> > 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.
>> >
>>
>> Well, as far as I understand this draft, there is no declarative method
>> to provide information about functionality and how to animate, therefore
>> this is of limited use for authors interested in declarative methods and
>> accessible documents. Therefore I think, we can neglect this for this
>> purpose. This is maybe more for fun, styling and decoration, not content.
>>
>> And a related declarative method for content should not differ a lot from
>> the
>> general XML concept, and this requires, that the user-agent indentifies
>> the
>> namespace and interpretes the language to get a meaningful presentation,
>> therefore no need to reinvent this already existing concept ;o)
>>
>>
>> > (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
>>
>> Well, it is not so difficult to create some paths with rotation symmetry
>> or going from this to broken rotation symmetry (take into account, that
>> more exciting 'star' appear to have no exact rotation symmetry).
>> I have many PHP-scripts (the simulations in the proposals are just two
>> examples, there are much more in my art gallery)
>> for different purposes to generate this at least for static files and
>> for some simple animations, but it really gets difficult for some kind of
>> animation, that would be easy with thought through attributes,
>> but without you get this Megabytes of data per animation element soon.
>> The new path command helps to get alternative, not really simpler
>> PHP-scripts
>> or to do simpler cases by hand, but this will be not a big change for
>> authors,
>> they still need knowledge in polar coordinates and vector algebra to get
>> what
>> they want from such PHP-scripts.
>> With such new elements there should be an easier access to this type of
>> shapes
>> for other authors as well.
>>
>> A specific element for only regular polygons can already help to animate
>> this
>> type of shape better than having only a path command, but still you are in
>> trouble, if you want to be slightly more creative or flexible and to
>> differ
>> from others with 'your own' shape.
>> And to what yet another 10 or 20 years to be 'more creative' here, is just
>> frustrating ...
>>
>>
>> Olaf
>>
>>
>>
>>
>