Closed Bug 442228 Opened 16 years ago Closed 14 years ago

Implement CSS property to control element resizability

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a4

People

(Reporter: cjcypoi02, Assigned: enndeakin)

References

(Depends on 2 open bugs, Blocks 2 open bugs, )

Details

(Keywords: css3, dev-doc-complete)

Attachments

(3 files, 4 obsolete files)

CSS3 'resize' property:
http://www.w3.org/TR/2004/CR-css3-ui-20040511/#resizing
The document is in "Candidate Recommendation" state.

I add Bug 410988 and Bug 167951 as dependent from this bug, because if resize property will be implemented probably the behaviour described in those bugs should be off by default.
Flags: wanted1.9.1?
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Bug 167951 just got blocking1.9.2+, it would be great if this bug would be fixed, it would automagically fix bug 167951 and bug 410988 too.
Flags: blocking1.9.2?
Isn't it easier and more convenient way to add firstly the textarea resizer itself (bug 167951) and to attach then the CSS property to control it?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
No longer blocks: 167951
This implements the resize, but it may be better as -moz-resize, as this implementation uses a <resizer> which just adjusts the style.width and style.height on the element when it's resized. The spec says that the resize should adjust an internal scaling factor instead.

Some things still remain:

- I couldn't get the minimum width/height to work for html elements (so that the resize can't adjust below the resizer's size), so I just set a min-width/min-height on the textarea. This isn't ideal.
- there aren't any images provided for the horizontal or vertical only resizers.
Blocks: 167951
One weird thing I noticed, go to http://jsbeautifier.org/ and drag the resizer all the way to the left, the text in the box shifts all the way to the right weirdly even though the actual textbox doesn't change...
Natch, If you look at it in the DOM inspector it's actually <fieldset><div><textarea/></div></fieldset> plus some funky CSS. So the textbox is actually changing width but what you are seeing are the borders of the containing <div>.

The same behaviour occurs with an un-patched build and the Resize Text Area extension.
Decided to just -moz-resize property due to differences.
Assignee: nobody → enndeakin
Attachment #419124 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #425495 - Flags: superreview?
Attachment #425495 - Flags: review?(dbaron)
Attachment #419126 - Attachment is obsolete: true
Attachment #425499 - Flags: superreview?(dbaron)
Attachment #425499 - Flags: review?(roc)
Attached patch nsResizerFrame.cpp changes (obsolete) — Splinter Review
This patch makes several fixes:
 - use the dir attribute for all resizes
 - don't allow a resize smaller than the <resizer> size
 - skip over native anonymous nodes when looking for a parent to resize
Attachment #425502 - Flags: review?(neil)
Comment on attachment 425495 [details] [diff] [review]
implement -moz-resize property

It's not intuitively clear to me that the dynamic change handling requires frame reconstruction rather than just reflow, although I certainly don't object to it requiring frame reconstruction if that makes the implementation simpler.

r=dbaron
Attachment #425495 - Flags: review?(dbaron) → review+
Comment on attachment 425502 [details] [diff] [review]
nsResizerFrame.cpp changes

>+    nsIContent* parent = mContent;
>+    // skip over native anonymous content
>+    while ((parent = parent->GetParent()) && parent->IsInNativeAnonymousSubtree());
>+    return parent;
Should this be using FindFirstNonNativeAnonymous?
Attachment #425502 - Flags: review?(neil) → review+
+    if (kid != mScrolledFrame &&
+        (!hasResizer || kid != mScrollCornerBox)) {

This would be a bit clearer if you wrote
    if (kid == mScrollCornerBox && hasResizer) {
      // skip, this will be drawn later on top of the scrolled content
      continue;
    }

+      case NS_STYLE_RESIZE_HORIZONTAL:
+        dir.AssignLiteral("right");
+        break;

This should probably be "left" if the vertical scrollbar is on the left?

Do we really need nsGfxScrollFrameInner::GetResizerSize? Can't we just assume that the resizer is exactly a square the width of a scrollbar?

+    if (aContentArea.x != aScrollArea.x || scrollbarOnLeft) {

Then we wouldn't need to change this, I guess...

+      // scrollbar (if any) on top
+      r.y = aContentArea.y;
+      r.height = PR_MAX(resizerSize.height, aScrollArea.y - aContentArea.y);
+      NS_ASSERTION(r.height >= 0, "Scroll area should be inside client rect");

We probably should just replace this with NS_ERROR since we never place the scrollbar on top.
(In reply to comment #13)
> +      case NS_STYLE_RESIZE_HORIZONTAL:
> +        dir.AssignLiteral("right");
> +        break;
> This should probably be "left" if the vertical scrollbar is on the left?
Better still, make resizers support "end" (c.f. RTL-aware "bottomend").
Attachment #425495 - Flags: superreview?
> Do we really need nsGfxScrollFrameInner::GetResizerSize? Can't we just assume
> that the resizer is exactly a square the width of a scrollbar?

I adjusted the code a bit. I could assume the width and height are equal but it only saves line of code, so I'm not sure it's worthwhile. 

> +    if (aContentArea.x != aScrollArea.x || scrollbarOnLeft) {
> 
> Then we wouldn't need to change this, I guess...

It's still needed in the case where a resizer is present but no scrollbar.
Attachment #425499 - Attachment is obsolete: true
Attachment #427391 - Flags: superreview?
Attachment #427391 - Flags: review?(roc)
Attachment #425499 - Flags: superreview?(dbaron)
Attachment #425499 - Flags: review?(roc)
Attachment #427391 - Flags: superreview? → superreview?(dbaron)
Attachment #425502 - Attachment is obsolete: true
Attachment #427392 - Flags: review+
Comment on attachment 427391 [details] [diff] [review]
updated scrollframe and tests patch

sr=dbaron.  Sorry for the delay getting to this.

(I'm actually not sure why this patch needs sr.)
Attachment #427391 - Flags: superreview?(dbaron) → superreview+
Shouldn't this be checked in?
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4
Keywords: dev-doc-needed
This isn't actually fixed. I haven't implemented the css3 resize property. But I've filed a new bug 553576 to cover that instead and will change this one into what has been implemented.
Blocks: 553576
Summary: Implement CSS3 'resize' property → Implement CSS property to control element resizability
If "-moz-resize" will be in a proper release, it will need some documentation at https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions.

Good work on getting this implemented!
Depends on: 553796
The "square" resizer on an empty textarea looks odd!

I was trying to update the Modern CSS to work with this. Obviously the first hurdle (which was readily resolved) was that it hasn't been updated for -moz-locale-dir. I then noticed that the size oddly changed when the textarea gained focus. I was able to work around this by specifying minimum dimensions for scrollbars. I did however have one final problem, and that is that resizers and scrollcorners have different background colours; in fact resizers are normally transparent, so how can I give them a background colour but only when they are in a textarea?
You should be able to use in resizer.css:

  html|textarea resizer { ... }
Can that use the '>' combinator instead?  Or is the resizer not a direct child of the textarea?
Yes, that what I had intended.
Blocks: 553937
Depends on: 553986
Oh goodness, can we get this on 1.9.2?
(In reply to comment #26)
> Oh goodness, can we get this on 1.9.2?

Since Firefox.next will bring major UI changes, it's would be wise to wait with it. Also, in my opinion, the resizer for Mac should be redesigned (same one as on Windows perhaps?). It looks good classic white forms/textareas, but as soon as you use any background colors, it looks really bad. It also seems to separate from the border of the form itself when certain CSS is applied. The native Mac resizer works great in the edges of windows, but not where it's mixed with a non-white background color.

I think the resizer should always try to blend in with it's background somehow, which can be achieved with opacity or half-transparent colors. This is already the case with the Windows-version (or at least it doesn't cover a whole square). I'd almost say we should not include this by default on Mac if the style isn't changed. I might file a separate bug on this, but, do you agree?
Depends on: 554810
This patch added a new reftest directory in layout/xul/base/reftest/ but didn't add those reftests to the toplevel manifest, so they were never run in our automated testing.  I just did that:
https://hg.mozilla.org/integration/mozilla-inbound/rev/139eed687d77
Depends on: 1186140
You need to log in before you can comment on or make changes to this bug.