Closed Bug 17639 Opened 25 years ago Closed 22 years ago

Mouseover effects should be optional for XPFE widgets

Categories

(SeaMonkey :: General, enhancement, P3)

Product:
SeaMonkey
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: mpt, Assigned: mpt)

References

(
URL
)

Details

Some people like widgets (such as toolbar buttons) to change their appearance when moused over, but others detest it on usability grounds. Because opinions on this are so polarized, I suggest that Mozilla, like Opera, provide a user preference for disabling all UI mouseovers. The preference would take the form of a checkbox in the Appearance prefs category: [*] Highlight buttons and other controls when the pointer moves over them If this checkbox was unchecked, widgets would always look as if the mouse pointer was over them, with the exception that button text would not be underlined. Note: Bug 6582 deals with disabling mouseovers for inactive windows, so it may or may not be useful to share some code with the fix for this bug.
Would this apply to web pages?
Summary: Mouseovers should be optional → Mouseover effects should be optional for XPFE widgets
Just to XPFE widgets in general. So it would apply to form elements in Web pages, but not to other mouseovers in Web pages. Ignoring mouseovers in Web pages is a separate issue, and would (if implemented) probably be in a JavaScript preferences category, not the Appearance category. [Changing the summary to remove the confusion]
Assignee: shuang → german
re-assign it to german to look into.
Status: NEW → ASSIGNED
Target Milestone: M16
I think it is part of that look and feel (skin). Other skins can be later swapped in that do not have this behavior. Keep in mind we are moving quickly to a world where the difference between chrome and content, between dialogs and web forms and between apps and net based services becomes negligible. Traditional GUIs never accounted for this.
I don't think any decent skin would suddenly stop making sense if its mouseovers were disabled. This is something that should be skin-independent -- providing two separate skins for each design, one with and one without mouseovers, would seem to me to be a bit silly. Just as providing multiple variants of skins for those who like their toolbars as text/pictures/both would be a bit silly. And all the warm fuzzies about local and Web interfaces merging is, IMO, irrelevant. As I've already said, my suggestion applies to Web form widgets just as much as it does to the local Mozilla chrome. Some people, myself included, detest the idea of *any* widget changing appearance when it hasn't changed state. But other people think it's kewl. Hence the request for a preference.
Blocks: 18054
I absolutely agree this should be skin independent. See the master tracking bug #18054 for other instances of this argument.
Try explaining "[] Show Mouseover effects for XPFE widgets" to a non-geek web user and you will get blank stares :-) I don't think we should stuff everything into prefs. They are already too crowded as they are. <off topic> we may need a way for tweaker-type people to access all prefs in prefs.js in sort of a tabular format like a properties editor, so that we do not have to stuff everything into the standard prefs UI which should stay accessible to the general public</off topic>
Did you miss my original suggestion for the wording of the checkbox, German? I don't think `Highlight buttons and other controls when the pointer moves over them' is that difficult to understand. And it would fit in nicely on the same prefs pane used for selecting chrome. I'm working on a way to simplify prefs, and here's the relevant snippet: || Category General - Appearance :::::::::::::::::::::: || || +-------------------+ || || |= General =========| +-Chrome-------------+-[*] Preview--------+ || || | > Appearance < | |[Chromes :^]|+------------------+| || || | Startup | |+----------------+-+||? /L' J\' 'V\ /\|| || || | Connection | || System |'|||: \F 7/ ._/ |H|| || || | Temporary files | ||>Communicator-4<|V|||:Back Fwrd Rld Hom|| || || | Media types | |+----------------+-+|+------------------+| || || | System | +--------------------+--------------------+ || || |= Display =========| Show toolbars as [ pictures and text :^] || || |= Navigator =======| [*] Show tooltips (pop-up button captions) || || |= Messenger =======| [ ] Highlight buttons and other controls || || |= Composer ========| when the pointer moves over them || || | | || || +-------------------+ ::::::::::::::::::::::::::::::::::::::::::: || |`-------------------------------------------------------------------'| And as for the tabular advanced prefs UI you suggest, that's already been filed as bug 17199.
I like "suppress all browser effects while moving the mouse pointer over areas of the browser". I think this would be valuable as a main preference, since this is something a novice user will likely want to use, whereas there are plenty of things already there that novice users won't. The smart scrolling preference ( bug #16277 ) would be cool here too.
The problem with `suppress all browser effects while moving the mouse pointer over areas of the browser' is that it associates turning a checkbox ON with turning a feature OFF. Which is, well, a little confusing.
Yep. It was an attempt to convey the fact it won't necessarily happen. It you say "highlight ..." and the user has it on, they'll wonder why it doesn't work if they're using a skin that doesn't do it. The appropriate word, therefore, is probably "allow".
Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
I would really like mouse over effects to be optional. This should include menu-navigation, menus should not open on mouseover, only if a button is held down or clicked. (perhaps 2 different options).
Blocks: 29137
Blocks: 29103
Blocks: 29105
We are still playing with the widget borders for the current widgets. Right now to see what it would look like Ben put on black borders around most of the widgets. I think those border are too high contrast and actually take away some of the 3-D'ish affordance that was built into the spec. It seems really it adds a lot of visual noise without much usability gain. What we will try out as a compromise: Having a 1px permanent border around the widget (in order to address the fact that widget still has to be visble when on a white background), but not as high contrast as black, instead we would use something like a #666666 border. To have the mouseover highlight we switch to a #000000 border.
Target Milestone: M16 → M20
My request in this bug was that *whatever* the particular skin author (whether that be Netscape, Mozilla.org, or anyone else) decides to do with regard to mouseovers, any mouseovers which are in the skin should be overridable by the user.
Keywords: softui
No longer blocks: 18054
I think this should still be skin specific, it's completely up to the author whether to make use of mouse over effects or not. By swapping skins the user gets different looks and behaviors. Setting to future to keep discussion open
Target Milestone: M20 → Future
It would seem a bit bogus to have to develop and maintain a completely separate set of files, just to remove the mouseover effects from what is otherwise a perfectly-good skin (Classic, for instance), especially when such a preference could be handled quite simply by Mozilla instead. That would be like having to have different skins for hiding and showing each toolbar.
This is not as easily done as you might think. The mouseover is specified completely through style, how do we tell gecko to not mouse over on a subset of XUL widgets?
It's an all or nothing preference, no? So if the pref is set to disable mouse-over effects then simply don't pass them on to chrome widgets. Or maybe I'm thinking that things are easier than they really are.
No, this is a hack. I won't allow it. Make a new skin if you want a different look.
This bug should be resolved invalid.
See, now I would contend that doing it in the skin is a hack. Dave, perhaps you could explain why you think the other way?
Or use the user.css file to override what you want.
Also, if we get into a world full of prefs that clash with established style rules, we create a world in which skin design is completely confusing. The skin writer ends up writing a skin that won't necessarily behave as expected.
It's none of the skin writer's business what the user makes their skin look like. That's why CSS has user-important rules. Doing it in the user stylesheet for skins sounds like a reasonable implementation (and raises issues of user stylesheet UI), but is it easily possible to do this in CSS1/2?
We already have `prefs that clash with established style rules' -- namely, the platform fonts and colors used in the Classic skin. Does the Classic skin break as a result? No. No self-respecting skin should be chronically dependent on something as minor as mouseovers -- just as Web pages shouldn't break if you have `Always use my colors' turned on (for example). Telling the user to go hack user.css is, uh, Not A Very Good Attitude to take towards what will likely be end users' most-desired modification to any given skin.
I think we can probably resolve this issue through a simple user stylesheet generator, and that's what I meant (and indeed see bug #17533). It would both provide the functionality and be a clean solution. Indeed, as MPT says, there are already some settings that constitute this, although I don't know whether any go into the user stylesheet at the moment. The only question I have is whether it can easily be done in CSS. For example, I can see that you could probably override CSS mouseover for everything, but what about DOM event mouseover?
I think mpt was mainly referring to things like toolbar buttons etc, which all have their mouseover effect applied using :hover. There are certain mouseover events that one would still want to receive style change for, e.g. menus.
Based on a lot of feedback and to keep the skin development effort simpler we removed the mouseover effects from modern. This bug will be closed now as its no longer valid.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Where in this report is "Modern" mentioned. I thought you could install third-party skins into Mozilla ... But one thing I will say is this sort of thing might be better off using some sort of skin parameterisation, so the parameters would not bother the user if they didn't apply, like this won't now to Modern.
Even though this does not say in the bug, the original intent of the bug applied to modern only. Any other skin is at the authors discretion, as safe skins are not allowed to actually alter the UI (required for doing something like you mention)
I'd be suprised to hear if that was mpt's original intention. What I proposed as parameterisation would be through XUL extensions, not anything that would change the UI through currently available methods. But I realise now there is no need in this case anyway, since this is not a skin-specific thing, you could merely pop up this pref under the theme (or wherever) if it had mouseovers.
I'm sorry to be a nuisance, but I'm reopening this bug because the reasons given for its resolution didn't make any sense. > Based on a lot of feedback I suspect any feedback you solicited was from skin designers, rather than users -- the same sort of designers who snivel about the possibility that users might override their font and color choices in HTML. > and to keep the skin development effort simpler This option would not not affect the effort required to produce a skin one iota. > we > removed the mouseover effects from modern. No you didn't, as a simple mouse traversal of the Modern toolbar will demonstrate. > This bug will be closed now as its > no longer valid. Bugzilla convention is that a coherent RFE cannot be resolved invalid. You can resolve it wontfix, but if you do then please explain why. > Even though this does not say in the bug, the original intent of the bug > applied to modern only. ------- Additional Comments From mpt@mailandnews.com 2000-04-28 08:14 ------- My request in this bug was that *whatever* the particular skin author (whether that be Netscape, Mozilla.org, or anyone else) decides to do with regard to mouseovers, any mouseovers which are in the skin should be overridable by the user.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
mass-moving UI:Design Feedback bugs to hangas
Assignee: german → hangas
Status: REOPENED → NEW
oops meant to say reassign not new
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: claudius → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Hyatt was right, German was right (except for comment 31), and I was wrong. I was very, very young at the time ... Marking invalid since this would not be an enhancement.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → INVALID
Oh no, the dark side got him ...
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.