Ticket #11604 (closed feature: fixed)
Switch $(elem).width(-val) from no-op to $(elem).width(0)
| Reported by: | dmethvin | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.8 |
| Component: | dimensions | Version: | 1.7.2 |
| Keywords: | Cc: | ||
| Blocking: | Blocked by: |
Description
The fix in #1599 changed .width(-val) to be a no-op because it throws an error in IE. Later that same lifetime, we decided to make negative values equal 0 for animations in #10294 and #11415.
To simplify things and make them more consistent, it would be nice to have .css() limit any values to 0 that can't go negative, so it doesn't have to be handled different ways in two places.
This is a change in behavior and something with a unit test in dimensions, but since negative values are actually outside the range of valid inputs I think it's within our rights to change this. Our main goal was to avoid an error in IE (for example in animations that undershoot), and the proposed change still does that.
Change History
comment:1 Changed 14 months ago by dmethvin
- Priority changed from undecided to low
- Status changed from new to open
- Version changed from 1.7.1 to 1.7.2
- Component changed from unfiled to dimensions
- Milestone changed from None to 1.8
comment:3 Changed 14 months ago by gnarf
Just to mention - the natural behavior of elem.style.width = "-1px" is that elem.style.width remains unchanged. http://cl.ly/2J230E0y1j2O0D3u1R1t -- more thoughts?
comment:4 Changed 14 months ago by gnarf
My personal opinion is that the intent of someone setting one of these values to a negative number is to set it UNDER zero. The closest we can get them to that intent is to set it to zero
comment:5 Changed 14 months ago by mikesherov
I'm fine either way, but either way, animate should have the same behavior.
My personal pref is set to 0.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.