I would like these features to be standardised to hands-off-my-fricking-scrollbars.
I’m fed up with impossible-to-grab 1px-wide scrollbars because “everyone has trackpads”. No, they don’t.
If you're uncomfortable with the user realizing the game is a browser game, why did you make it in a browser?
Customising UI elements is a usability antipattern.
Per [1], predictability and familiarity are key in creating usable interfaces. Making things look nice "because you can" doesn't necessarily mean you should.
> When designing your interface, try to be consistent and predictable in your choice of interface elements. Whether they are aware of it or not, users have become familiar with elements acting in a certain way, so choosing to adopt those elements when appropriate will help with task completion, efficiency, and satisfaction.
[1] https://www.usability.gov/how-to-and-tools/methods/user-inte...
Sadly the world has gone the other way and basically ditched the whole concept of native widgets and consistent look and feel.
> Does this principal apply to X for y?
In a vacuum, yes it's a principal.
In reality, while it's an antipattern it doesn't mean you should be afraid let alone disallowed the ability to exercise good judgement and make a call.
Full window, emersive games are the perfect example of UI elements like buttons that should probably be reskinned - wisely. I say wisely because you can still reskin buttons in a way that affords familiarity you can also reskin them in a way that makes them abhorrent.
A converse example is windows based skinnable hardware interface software like MSI afterburner and the like. That sort of thing is absolute unthought, untested garbage.
For website buttons I think the ship has sailed and the default elements actually look alien.
In fact a lot of CSS frameworks improve net usability from defaults anyway.
Now, is it an antipattern to use them? In essence yes, but considering everything no. Caution, many css frameworks have UX issues and you need to make a judgement in your evaluation about which features to use. I like to see how their autocomplete / dropdown features work it's usually a good litmus test because those things are basically impossible to do right.
And this why we have UX people.
It is the marriage and trade off of usability/hci and designers to create a usability experience that delights.
Though things still tend to lean toward design first approaches. Which aren't incorrect approaches but do tend to lack emphasis on circling back to fix usability later.
I think website internals are widely debatable but do have norms you must consider.
I draw the line at breaking out of the window sandbox and altering browser UI. It assumes all browsers work the same and creates a dependency on the browser for a shared experience.
An inconsequential example: setting browser ui color on mobile version of Chrome. Now your whole website design feels very native and is reasoned about with that native feel. That can them lead to inconsistent design assumptions being made on the desktop. Maybe your color selection clashes badly with the desktop grey.
Like I said, inconsequential, but might illustrate why messing with it might be a bad idea.
The other big reason I throw down at the browser window line is accessibility. Messing with things like button sizing / scrollbar sizing and things wrecks absolute havoc on these users. They also make English centric assumptions about designs that are almost always wrong eventually.
Castle of the Winds, Windows 3.11.
I remember having a lot of fun playing Stars! as a child: https://www.mobygames.com/game/stars
One thing I like about the Firefox (Gtk?) scrollbar is that it finally removed (a few version ago already) the "Click on it somewhere, but it doesn't move there but just acts like PgDown/Up", i.e. the non-warping to the exact click position but just inching towards it. This is completely unnecessary in the time of wheels and touchpads and I already miss it everywhere else.
It is completely necessary for me to have “move one page up on click.”
Definitely no: If I have a hand on the mouse I surely don't want to lift it and hunt for the PgUp or PgDown just to move one page up or down. And no, I don't want to go "there" if it's actually "somewhere" in the middle of whatever, if I just want to see the previous or the next page. Going "there" is much less frequent operation than moving to the next or the previous page.
"Most"? Where did you get that idea? "Most gaming mice" or what? Most of the users aren't gamers.
> that means a PgDown button (I guess it is mostly that direction) on the mouse is missing.
Of course is missing: "normal" (as in the most common) mice have only 2 buttons and the scroll wheel.
The scroll wheel never moves one page up (or down), but just some small number of lines, so the most common operation is then impossible for the most of the users just because a developer (who probably even "lives" in his terminal for most of the time, never lifting the both hands from the middle of the keyboard) thinks that everybody has exactly the gear that he has.
- left click - page up/down
- middle click - go directly to this point.
Moving one of these to the other is confusing and a loss of useful functionality. Reminds me of "chesterton's fence."
For most longer texts, I hate "click to here" on the scrollbars. It's impossible to get it right. Them working as pgup/down makes much more sense.
A handful of people love it, most think it's a bug. It's particularly bad if you're using a trackpad.
I would theorize that it's not a well known complaint because most people move on quickly and just assume their computer is buggy.
Don't most mice have scrolling as well? It's not about trackpads.
Long story short, stop fscking with accessibility. If your js code or libraries handles ANY input events, you'd better watch yourself because you're venturing into specialized-interface-by-and-for-assholes-land.
Imagine you cmd + F a phrase and there are 200 responses separated into like 4 chunks of a document. It can be useful to scroll to the start of each chunk to get the context of them.
I realize the benefits of the Overlay Scroll Bar to the majority of users who have scroll-wheels. But it sure would be nice if there was an easy way to revert back to the Normal Scroll Bar ("Classic" scroll bar?). You know, the wide bar that scrolls down exactly one page-length if you click outside of the bar? I've spent plenty of time Googling and in "about:config" and exporting environment variables like GTK_OVERLAY_SCROLLING=0 to no avail.
But not all.
A browser-wide scrollbar styling system, able to be opted into by use of particular CSS, doesn’t imply anything about whether we are talking about just one scroll bar or all of them.
I also disagree about native controls not always being the best solution when it comes to scrolling. We all know how annoying it is when a page jacks scrolling; it’s a usability nightmare that makes pages’ scroll behaviour harder to predict. We don’t need to add to the usability issues by letting one of the most fundamental pieces of chrome in a web browser get jacked even further than the already impermissible state.
The work around was to use JavaScript, just to make it work on Firefox.
It can now be implemented in CSS, which makes it really easy for you to disable or change your preference as well putting the responsibility of style on CSS and not some annoying JavaScript.