# Re: Modulus operator & division by values

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 25 Jun 2013 10:20:56 -0700
Message-ID: <CAAWBYDDxWuj7w81sCYKsYBf3S9WnFWbkCtkAeGzYAPT7kebo9Q@mail.gmail.com>
To: Maël Nison <nison.mael@gmail.com>
Cc: www-style list <www-style@w3.org>
```On Tue, Jun 25, 2013 at 6:58 AM, Maël Nison <nison.mael@gmail.com> wrote:
> Thanks. However, I still don't understand something :
>
> We disallowed division by units at this level, so we can determine
> whether the math expression is valid at parse-time, since all
> divisions have only pure-numeric expressions for their right operand.
>
> Why can't we have a division by units and a parse-time validation of the
> expression ? For example, "100px/(43px - 43px)" is invalid and can as easily
> be detected as such than "100px/(43 - 43)" (since both of them are
> absolute). It seems to me that the main problem is about relative units such
> as percentages or em ("100px / 100%" could be invalid at runtime), or
> expression derivating from one of those units ("100px / (100px - 100%)").

You don't even have to go as far as percentages.  Is calc(100px /
(32px - 2em)) invalid or not?  You can't tell until computed-value
time.  That's just a length minus a length.

At this level, we're not willing to deal with calc() expressions that
might be invalid later than parse-time.

> Also, why should the two operands have the same unit ? Can't the right
> operand be coerced into the left operand unit ?

By "unit" I mean the same thing as the current limitations for the
other operations - "length", not "px".

~TJ
```
Received on Tuesday, 25 June 2013 17:21:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC