- From: Brian Manthos <brianman@microsoft.com>
- Date: Fri, 19 Aug 2011 20:54:35 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>
That seems like the tail wagging the dog to me. An individual edge case motivating making all uses of a reasonable syntax invalid seems wrong. I'd prefer defining what the calc expression should do with the division by zero (the edge case) rather than reject all the valid cases. Getting to your example... When the "calc(5px / (10px - 10%) )" resolves to "calc(5px / 0)", mapping that to a known value (like 0) seems reasonable. The constraint you're trying to preserve implies that all current and future CSS properties that accept percentage values must resolve those percentage values against a <length> rather than a <number>. Otherwise, division by zero at expression resolution time is still a potential concern. Let's take another example... div { width: calc( 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002px / 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001); } Should "really precise" applications treat this as valid at parse time with a resolved value of "2px" and "not so precise" applications treat this at parse time as invalid? -----Original Message----- From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] Sent: Friday, August 19, 2011 12:50 PM To: Brian Manthos Cc: www-style@w3.org Subject: Re: [CSS3 Values] referencing width or height explicitly On Fri, Aug 19, 2011 at 12:44 PM, Brian Manthos <brianman@microsoft.com> wrote: > #3.At "/": > # check: right side is "number" > # return: the type of the left side > > This seems arbitrary to me. > > Why should "calc(5px * (8px / 4px))" get rejected at parse time rather than evaluate to 10px? So we can detect division by zero at parse-time. Otherwise, something like: calc( 5px / (10px - 10%) ) ...is valid or not based on the element's current width. ~TJ
Received on Friday, 19 August 2011 20:55:13 UTC