553576 - Implement css resize property behaviour

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Neil Deakin]

Currently, in bug 442228, we implement -moz-resize which allows elements to be resizable. However, this is implemented just by changing the width/height style or attributes. The css 'resize' property requires that some internal scaling factor be used instead.

Comment 2

[Neil Deakin]

So it looks like Safari is just setting style.width and style.height as we do, but using the 'resize' property. (as well as, oddly, all four margin properties) Maybe we should just use 'resize' instead of '-moz-resize' anyway and just make changing style.width and style.height the right way.

Comment 3

[(no longer active)]

Reading the spec, the only place where our implementation is against it is that we don't reset the resize factor to 1.0 when the resize property is changed.  Here is an eample:

data:text/html,<textarea></textarea><script>setTimeout(function(){document.querySelector("textarea").style.MozResize="none";},5000);</script>

I think we can rename the property once we solve this.  We don't actually need to store a resize factor, we can just store the original computed width and height and then reset the dimensions when the resize property changes.

That said, I tested this in Chrome, and it has the same bug.

Comment 4

[d]

Sounds good to me. One thing that that struck me is that having a function to automatically switch back to the original size would be useful, as it might break the layout if it's resized in any way (and finding the original size manually, might be hard). We have a few options if we want to do that, that I can think of:

1. As soon as the resizer is used to change the size, a new option appears in the right-click menu of the form, or perhaps only the resizer itself.
2. Doubleclicking the resizer-grip restores the original size.

Out of these two, I prefer the second one, if only one had to be chosen, but a right-click menu option would be good to complete it.

No matter what, though, it probably belongs in a new bug. What do you think?

Comment 5

[Robert Sayre]

I think this blocks 1.9.3 because resizable text boxes need resize: none on lots of sites. See facebook.com and twitter.com, for example.

Comment 6

[d]

I found bug 555482 just now, and has posted my last comment in there, instead.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #5)
> I think this blocks 1.9.3 because resizable text boxes need resize: none on
> lots of sites. See facebook.com and twitter.com, for example.

How does switching the mechanism we use for the resizing away from changing style.width and height affect these sites?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So if we're confident we're compatible with Safari, and Safari uses 'resize' rather than something prefixed, then I think it's fine for us to drop the prefix as well, since it's not spoiling any ability that the working group has to change the spec.

Comment 9

[Damon Sicore (:damons)]

Bumping this to beta2 per beta re-triage with dbaron and sayre.  If this should indeed block beta1, please re-nom.

Comment 10

[Neil Deakin]

Attachment: change -moz-resize to resize

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 455740 [details] [diff] [review]
change -moz-resize to resize

r=dbaron

Comment 12

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/c1bb84d2470d

Comment 13

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Updated
<https://developer.mozilla.org/en/HTML/Element/textarea>
<https://developer.mozilla.org/en/Firefox_4_for_developers>
<https://developer.mozilla.org/en/Mozilla_CSS_support_chart>
<https://developer.mozilla.org/en/CSS/resize>
<https://developer.mozilla.org/en/CSS/-moz-resize>

Comment 15

[salvador.mazza33]

When I re-size the field that says: "What 's on Your mind?" in it, placed near the top of the page in Facebook.com, a large part of the page appears in blank and if I re-size the field to the left, the drag indicator gets to the middle of It. Is this bug about the one reported in here?