Last Comment Bug 448704 - Eliminate <gripper> as an independent element
: Eliminate <gripper> as an independent element
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: Widget: Win32 (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: mozilla1.9.1a2
Assigned To: Kai Liu
:
Mentors:
Depends on: 502292
Blocks: 424694
  Show dependency treegraph
 
Reported: 2008-07-31 16:32 PDT by Kai Liu
Modified: 2009-08-16 18:45 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (11.64 KB, patch)
2008-07-31 16:32 PDT, Kai Liu
vladimir: review+
dbaron: review+
enndeakin: review+
Details | Diff | Splinter Review

Description Kai Liu 2008-07-31 16:32:45 PDT
Created attachment 331877 [details] [diff] [review]
patch

Currently, scrollbar thumbs are structured such that there is a <gripper> element (which draws the small set of decorative lines) residing within the <thumb>.  I would like to get rid of <gripper> and have the gripper be drawn as a part of <thumb> instead of as a separate independent element.  I can't really see a reason for it to exist as a separate element.

1) Mac scrollbars have no grippers, and on GTK, the native theme rendering draws the gripper as a part of the thumb, and the separate <gripper> element is unused.  Windows is the only place where the gripper is handled as a separate element.  I would like to see the three platforms be consistent here, and we can do that by getting rid of <gripper> as an independent element.

2) This will allow us to properly fix bug 424694, and it would've prevented bug 439274.

3) This will make the Windows behavior more native, where the thumb can shrink below a certain size and the grip will disappear--doing that before this would not have been very feasible.

4) If a third-party theme wants the ability to customize the gripper (how many themes even bother with doing that?), they can still do so with a background image applied to the thumb.

(Vlad, you can review toolkit changes, right?  You're listed as a toolkit peer...)
Comment 1 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2008-08-05 12:46:12 PDT
Comment on attachment 331877 [details] [diff] [review]
patch

This looks fine to me, so r=dbaron.

But I think you should get Neil Deakin, or some other XUL owner/peer, to review this as well.
Comment 2 Vladimir Vukicevic [:vlad] [:vladv] 2008-08-05 13:50:13 PDT
Comment on attachment 331877 [details] [diff] [review]
patch

Looks fine to me as well, but I think you need a XUL sr since you're removing a XUL element..
Comment 3 Kai Liu 2008-08-05 16:22:10 PDT
Comment on attachment 331877 [details] [diff] [review]
patch

Ah, my apologies; I am not familiar with who is in charge of what.
Comment 4 Neil Deakin (away until Oct 3) 2008-08-06 08:48:06 PDT
Comment on attachment 331877 [details] [diff] [review]
patch

Looks OK
Comment 5 Kai Liu 2008-08-06 19:14:11 PDT
I need to remember to document this in the things-affecting-theme-developers page for 3.1 if/when this lands.
Comment 6 neil@parkwaycc.co.uk 2008-08-07 16:12:37 PDT
(In reply to comment #0)
>4) If a third-party theme wants the ability to customize the gripper (how many
>themes even bother with doing that?), they can still do so with a background
>image applied to the thumb.
Since this was only implemented to support native theming, third-party themes would probably already be using a background image applied to the thumb.

(From update of attachment 331877 [details] [diff] [review])
>+  <binding id="thumb" extends="xul:button" />
Why the extra space before the /> ?
Comment 8 Kai Liu 2008-08-22 18:18:57 PDT
Sorry; I haven't been around the past few weeks, so I'm just doing some catch-up right now...

(In reply to comment #6)
> Since this was only implemented to support native theming, third-party themes
> would probably already be using a background image applied to the thumb.
> 
That's a good point.  I haven't had a chance to do a complete survey of third-party themes, but after taking a random sampling, I noticed that the gripper is almost never used by third party theme authors.  The one theme that I sampled that did use the gripper did not use a textured thumb element and only used borders for the styling of the thumb.  I personally think that it's still a worthwhile tradeoff, but if people feel strongly otherwise, we could back this out.

> Why the extra space before the /> ?
> 
There is no particular reason for the space; I did not think to check what the prevalent style was with respect to a spaces before />, so mea culpa.  I do not have hg access, so if someone would like to do a spacing nit fix for this, that'd be great.

Note You need to log in before you can comment on or make changes to this bug.