Skip to content

[css-values] when should values inside mix() be clamped?  #8158

Closed

Description

@graouts

CSS Values and Units Level 4 introduces the mix() function. It's not clear to me reading the spec at what point clamping should be applied for this example:

<div style="font-size: 40px; line-height: mix(0.5, 40px, calc(40px - 3em))"></div>

The spec has this to say in the Range Checking section for calc():

Parse-time range-checking of values is not performed within math functions, and therefore out-of-range values do not cause the declaration to become invalid. However, the value resulting from an expression must be clamped to the range allowed in the target context.

I'm not sure what "resulting from an expression" means here. I think the above mix() value could resolve to either:

  1. 20px where we clamp the output of the calc() expression and mix between 40px and 0px,
  2. 0px where we only clamp the output of the entire mix() expression and mix between 40px and -80px, clamping the result -20px to 0px

Assuming that "resulting from an expression" refers to any math function then it would clearly be the first result since mix() is not a math function.

This is somewhat related to #8157 where I raised the issue of what would happen when interpolating between the same two values in the context of an animation.

Activity

  1. Loirooriol commented on Nov 30, 2022

    @Loirooriol
    Contributor

    I would say (1). mix() uses the grammar of the property to interpolate the expressions, e.g.

    order: mix(50%; 1; 9); /* (1+9)/2 = 5 */
    aspect-ratio: mix(50%; 1; 9); /* sqrt(1*9) = 3 */

    so interpolating a negative length if the property doesn't understand negative lengths kinda seems wrong.

    But an interp() function from #6697 that would basically be syntax sugar for calc() then would behave as (2).

  2. tabatkins commented on Apr 6, 2023

    @tabatkins
    Member

    Yes, it's (1) in this case: each of mix()'s arguments are clamped to allowed range of the context (non-negative). By "expression" I really mean "top-level calculation" and should use that term (and linkify it) instead.

    But an interp() function from #6697 that would basically be syntax sugar for calc() then would behave as (2).

    Right, if we stayed purely within math functions the clamping wouldn't happen until the end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions