- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 8 Jul 2013 14:16:22 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: Cameron McCormack <cam@mcc.id.au>, "www-svg@w3.org" <www-svg@w3.org>
On Mon, Jul 8, 2013 at 1:11 PM, Doug Schepers <schepers@w3.org> wrote: > On 7/8/13 3:57 PM, Tab Atkins Jr. wrote: >> On Sun, Jul 7, 2013 at 6:55 PM, Cameron McCormack wrote: >>> textLength="" is defined to be invalid if the length is negative. What >>> should happen when textLength="0"? It seems Chrome and IE ignore it, >>> while >>> old Opera disables rendering of the element. I slightly lean towards >>> disabling rendering, as it would behave better when animating >>> textLength="" >>> to 0 and back. >> >> Is textLength an integer, or a number? If a number, I disagree with >> this - adding discontinuities that are sensitive to implementation >> precision and rounding behavior is a bad thing. > > I don't understand your concern. Can you expand on that? If something is a number - that is, it accepts decimal quantities, rather than just integers - you should make sure that all of your ranges are closed, rather than open. For example, behavior can be defined for values "0 and up", but not "above 0", because that's an open range - in includes every value greater than zero, but not zero itself. This is bad, because the exact precision of the implementation is unknown and purposely undefined. If I set something to .0001, does that round to zero, or is it preserved as greater-than-zero? This behavior is very important if you have different behavior for "is zero" and "is greater than zero". What about .000000001? We have a general policy in CSS of never doing open ranges, for this reason. There are only a few unfortunate exceptions, like the effect of border-radius on box-shadow's spread (zero border-radius makes the shadow keep sharp corners, while >0 border-radius makes it round as the spread grows, similar to a blur). (Technically, "0 and up" implies an open range, in that "less than 0" is another range which has some defined behavior. This is fine in the common case, when negative values are invalid, because you can detect and reject negative values at parse time, before any rounding has a chance of occurring. It would not be fine if negative numbers were valid; in that case, you shouldn't have a change in behavior at all. Instead, just make sure the behavior smoothly changes as you move from positive to negative.) ~TJ
Received on Monday, 8 July 2013 21:17:09 UTC