- From: 向雅 <fyaoxy@gmail.com>
- Date: Sat, 12 May 2012 00:40:41 +0800
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- Cc: www-svg@w3.org
Indeed, there already have implicit conclusion: In normal use cases, the empty path not a necessary. Seems, at this point, both agree:) now we are talk about it's necessary in non-normal uses. >From common programming view, if there is an empty thing, so the iteration loop must do checking out if something is special or null like, yes? But in a graphics context, this kind of verification will eat some machine time. so value at where? But:) I must admit, I not really do some kind of animation framework. and I think my animation part processing about to begin. Maybe after some additional experiments, I have more qualification to talk about that from animation applying view.:) 致敬 向雅 2012/5/11 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>: > With declarative animation one can have a values list in > SVG tiny 1.2 and 1.1.2 for the d attribute with different > numbers of path segments to get a discrete animation. > If an author sometimes needs no path as one value - > why not? If this results in no display, there is no need > for an additional synchonised animation of another > property or attribute to get the intended effect. > > Obviously one can use the use element with > a declarative animation of the reference to different > (path) elements - there is often more than one way > to get the intended effect - this is no reason to panic, > just an indication for many options to get similar effects > in an advanced language. > If you don't need empty d elements, simply do not > use them ;o) > > In SVG 1.1.2 and SVG tiny 1.2 there can be seen > several efforts to avoid error messages, replacing them sometimes > with 'disables rendering', sometimes with other meaningful > behaviour, representing effectively a new feature - do you think, > it is more useful to have an error message for such obvious > things instead of the a display of the document? > Of course, for some errors a message is more useful, > but if the defined behaviour just describes, what one can > expect, as here to render nothing, if d is empty, why not? > Indeed there are already a few cases, where > superfluous 'disables rendering' definitions prevent > meaninful use cases, but here I cannot see an advantage > in an error message or a more useful behaviour in case > of an empty d. > > Olaf
Received on Friday, 11 May 2012 16:41:30 UTC