- From: nandini <Nandini.Ramani@Sun.COM>
- Date: Tue, 25 Jul 2006 13:46:46 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: www-svg@w3.org
Hi Bjoern, >> http://lists.w3.org/Archives/Public/www-svg/2006Mar/0032.html >> >> On looking into this further, JavaScript does return NaN, >> ( my earlier response was with reference to Java). In cases where NaN is >> returned, it will be treated as any other unsupported value. >> > > I do not understand your response. I want to know whether there is any > case in which code like x.getFloatTrait(y) would return something that > is not equivalent to a real number. The answer depends on what > > if requested trait's computed value cannot be converted to a float > > For a property, when you getTrait, it already has the computed value, so the WG resolved to modify the above sentence to "if requested trait's value cannot be converted to a float". > means. I do not understand what it means that such a value cannot be > converted to a float (I also do not understand what a trait's computed > value might be). It is unclear to me why this is listed as "The comment > There are instances where a value may not have a float equivalent, eg. percentages, or keywords (like auto). In these cases, an exception will be thrown. For eg., If width = "100%" and you did a getFloatTrait on it, it will raise a TYPE_MISMATCH_ERR. > resulted in some discussion, but no change seemed to be asked for", I > would have thought "... please change the draft ..." is clear enough. > This was discussed within the working group and several implementors agreed that there are cases where getFloatTrait method will raise an exception for non-float values and hence we do not see the need to change the specification. I hope this clarifies your questions. Thanks -Nandini
Received on Tuesday, 25 July 2006 20:48:53 UTC