RE: Proposal: <star> element

+1

Before we decide what a language should not express, we really ought to decide what it can express!

Cheers
David

-----Original Message-----
From: Dr. Olaf Hoffmann [mailto:Dr.O.Hoffmann@gmx.de] 
Sent: Saturday, April 12, 2014 10:17 AM
To: www-svg@w3.org
Subject: Re: Proposal: <star> element

Philip Rogers wrote:
>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).

With this argument, we should forget about any new feature and SVG2 completely - the current draft contains already several backwards incompatibilities, event the second edition of SVG 1.1 unfortunately does not contain only bug fixes, but a few serious backward incompatibilities to the first edition as well (can be seen as bugs of the second edition).
Indeed even SVG1.1 contains lots of content, that is currently not yet implemented correctly or at all. 
If implementors stop to implement features from SVG1.1 or in future from SVG2, this can be finally a reason to stop W3C completely and forget about  Presto, Batik, WebKit, Blink, Mozilla Gecko, MSIE, Konqueror/KHTML/KSVG etc, because all this failed. 
Maybe this indicates, that all these 'leisure projects' should be replaced by for example an UNO project with competent academic commissions to get finally some proper recommendations and a reference implementation for free and everyone, that really does, what  is recommended ;o)

Without new features, this means to stop any progress now. 
Maybe implementors will need to get their SVG1.1 interpretation complete 5 or 10 years more - if this is done, you think, it is early enough to care about SVG 2?
Especially if we look with this approach on what happend to (X)HTML, they did not even manage to implement HTML4.01 properly up to now and there are already drafts for years now for HTML5 and even for HTML5.1 (these variants of HTML5 seem to indicate already, that HTML5 failed similar to HTML3 and HTML3.2) maybe it would be useful to concentrate von
XHTML1.1 and XHTML-RDFa, the last one at least allows authors to extend it for semantical reasons without much work to implement something.
CSS has lots of new drafts, some of them reinventing the wheel as the animation draft - do you think, W3C should stop this as well, because
a) it is backwards incompatible to CSS1 or CSS2.0?
b) not necessary, because there are already recommendations for the same purpose?

Backwards incompatibilities are a problem, of course, but therefore different versions of a format have different version indications (version attribute in SVG), user-agents should warn users to switch to another program, if the version is newer than that, what the user-agent knows. 
Additionally SVG has methods to check for supported features and if important, authors can prepare warnings as well or provide alternatives, in case such a problem is discovered for an older user-agent.
And indeed, currently warnings concerning not supported versions is not done by typical user-agents (for example for SVG tiny 1.2, if the user-agent does not manage this yet) - but this is not a problem of the format or version, but this is an accessibility problem of the user-agent, if they do not use available information to help users and get them informed about problems.

Assuming that UNO will not safe the world (of internet) and some subset of authors insist on wanting to use new features or alternative notations in (X)HTML, CSS, SVG innovations, there is a need for such 'leisure projects' 
with lots of bugs and gaps and discussion about it, including innovation and maybe just reinventing the wheel some time as well (if some authors prefer CSS notation instead of XML notation or vice versa for example).
But without more or less reliable recommendations authors just get frustrated by arbitrary rank growth - eternal drafts and proprietary implementations are simply frustrating for authors, as well as no progress at all.

>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>.

Several user-agents have already trouble in handling the already existing shadow tree for the use element properly...

The more advanced proposals cover already a larger amount of such structures, not only a specific type as for example the current elements line, rect, ellipse and circle. They are already much more flexible than polyline or polygon.

A declarative method to be even more flexible would be for example something like the RDML proposal:
http://purl.oclc.org/net/hoffmann/rdml/
or for some other features/issues the replicate proposal:
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm

But both was rejected for SVG2 (because they allow in a wide range to create new structures in a flexible way beyond the control of the working group), therefore we can focus on specific elements for each purpose and feature, if there is no acceptance for more flexible concepts.
And such specific elements have advantages as well, especially if they have sophisticated attributes useful especially for animation as already explained (to approximate animations with about 20 to 50 values per second is not really promising for authors and users, if they have to download documents of a size ~1GB, if they could have it for 10kB as well, if there would have been a specific element for this usable by the author. 

Or maybe there should be some extended XSLT (not for decoration, but for content) to cover such use cases.
But DOM features mainly mislead authors to create documents, which do not work, if script interpretation is not available, therefore if there is a need for it all all, such DOM features should not reflect more as can be done with declarative methods, to enable authors to create accessible content and not just purely decorative extensions to empty documents. 


Olaf

Received on Monday, 14 April 2014 03:58:52 UTC