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.