This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16062 - Behavior for out-of-range values needs to be defined
Summary: Behavior for out-of-range values needs to be defined
Status: RESOLVED FIXED
Alias: None
Product: CSS
Classification: Unclassified
Component: Transitions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Dean Jackson
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-21 17:15 UTC by Aryeh Gregor
Modified: 2015-02-10 22:19 UTC (History)
4 users (show)

See Also:


Attachments

Description Aryeh Gregor 2012-02-21 17:15:44 UTC
This is currently issue 7 in the spec, but I'm filing a bug so I can get notified when it's fixed:

"""
Issue: Need to describe handling of out-of-range values that can result from cubic-bezier(). Clamping values to the allowed range is probably the best solution.
"""

For example, if you have something like cubic-bezier(0.25, -2, 0.75, 1), on a property like border-bottom-width that doesn't accept negative values, the computed value should be clamped to 0px at points where it would be negative.

Gecko seems to do this correctly.  WebKit seems not to clamp anything, and instead either allows the negative value, or has a large positive value like 134217660px, or falls back to a default value like "normal".  IE and Opera clamp some properties correctly but not others.

(I hit this issue while porting Gecko's test_transitions_per_property.html.  Non-Gecko browsers fail a lot of the clamping tests, but the spec isn't clear that Gecko is right.)
Comment 1 Simon Fraser 2012-02-21 17:42:55 UTC
Dup of bug 14607?
Comment 2 Aryeh Gregor 2012-02-21 18:28:50 UTC
Nope.  The current spec explicitly allows the y-coordinates of cubic-bezier() (i.e., second and fourth arguments) to be out of the range [0, 1].  This allows property values to "bounce" beyond the start/end values.  Try this:

data:text/html,<!doctype html>
<div style="text-indent:0px;
-ms-transition:2s cubic-bezier(0.25, -0.5, 0.75, 1);
-moz-transition:2s cubic-bezier(0.25, -0.5, 0.75, 1);
-webkit-transition:2s cubic-bezier(0.25, -0.5, 0.75, 1);
-o-transition:2s cubic-bezier(0.25, -0.5, 0.75, 1);">
Some text</div>
<script>
setTimeout(function(){document.querySelector("div").style.textIndent = "100px";}, 1000);
</script>

This causes the indentation to become briefly negative before it rises to 100px.  This is good, and we want to allow it.  But for properties where negative values are prohibited, it has to be clamped.  I'm seeing getComputedStyle().fontSize == "-67px" in WebKit right now, for instance.  This also needs to apply to the upper end, for properties that are clamped from above (like opacity).
Comment 3 L. David Baron (Mozilla) 2015-02-10 22:19:05 UTC
I fixed this a while ago, with the text:

http://dev.w3.org/csswg/css-transitions/#animatable-types

 However, if this value (Vres) is outside the allowed range of values for the property, then it is clamped to that range. This can occur if p is outside of the range 0 to 1, which can occur if a timing function is specified with a y1 or y2 that is outside the range 0 to 1.