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 Saturday, 12 April 2014 14:17:54 UTC