Re: [css-values] [css-color] XSL-FO and CSS - expression languages compared

While we're at it, sqrt() is useful in a variety of use cases. The expression could be invalid at computed value time if the parameter is negative, since I imagine complex and imaginary numbers are not that useful in CSS :)

Lea Verou ✿ http://lea.verou.me ✿ @leaverou










> On 5Dec, 2016, at 20:33, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Mon, Dec 5, 2016 at 5:03 PM, Liam R. E. Quin <liam@w3.org <mailto:liam@w3.org>> wrote:
>> On Mon, 2016-12-05 at 15:48 -0800, Tab Atkins Jr. wrote:
>>> 
>> On Wed, Nov 16, 2016 at 9:05 PM, Florian Rivoal <florian@rivoal.net>
>>> wrote:
>>>> It's been a while since I last though seriously about that, but I
>>>> seem to remember that
>>>> as long as we had something which was continuous, piece-wise
>>>> linear, and strictly monotonic, we were good,
>>>> and that breaking any of the three could mean complications.
>>>> 
>>>> mod is piecewise linear, but not continuous or monotonic
>>>> abs is piecewise linear and continuous, but not monotonic
>>>> floor, ceiling, min and max are piecewise linear and continuous,
>>>> and monotonic but not strictly monotonic
>>>> round is piecewise linear but not continuous, and monotonic but not
>>>> strictly monotonic
>>>> 
>>>> I may be misremembering the criteria, and they may not all be of
>>>> equal difficulty, though. I seem to remember this discussion being
>>>> raised by dbaron, so maybe he remembers better.
>>> 
>>> I think you got it right. Point is that it needs to be invertible to
>>> be usable in several spots in CSS, which those criteria satisfy.
>> 
>> Invertible in the sense of f¯¹ ? Is that true of calc()? in general no
>> because you could multiply by zero in an expression.
> 
> Multiplying by zero is the same as just providing a raw 0 - it's fine.
> (So "strictly monotonic" isn't actually quite right, as
> constant-value, at least, is allowed.  I think you might need strict
> monotonic if the function is piecewise with >1 pieces, tho.
> 
>> sin(), cos(), sqrt() are probaby OK if defined over a percentage of a
>> circle, but not tan().
>> 
>> But is the inverse function what's actually needed, or just a
>> dependency graph?
> 
> Some aspects of table sizing, and perhaps intrinsic sizing, depend on
> inverting the sizing function.  Before calc the only function was %,
> which satisfies all the criteria; current calc()'s feature set also
> works.
> 
> ~TJ