rustdoc: add a handle that makes sidebar resizing more obvious #139562
Conversation
|
rustbot has assigned @GuillaumeGomez. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred in HTML/CSS/JS. cc @GuillaumeGomez, @jsha Some changes occurred in GUI tests. |
This comment has been minimized.
This comment has been minimized.
This change is based on some discussion on [lolbinarycat's idea], but with a more "traditional" design. Specifically, this is the closest thing I could find to a consensus across many systems I looked at for inspiration: - In Jira, resizable sidebars have a stack of four dots. - In The GIMP, resizable sidebars have a stack of three dots. - In [old Windows], "panes" are defined to have the same border style as a window, which has a raised appearance. - In [NeXT], a drag point usually had an innie, whether the line in a slider or the circle in a scroller; I can also hide and show the favorites bar in Workspace by dragging on a circular "grip spot" - In [old Mac], drag handles for things usually had a "grip track" of parallel lines. - [OSX] kept that, but the "Source List" part of the Finder still had the circle grip for a time the same way Workspace did [lolbinarycat's idea]: rust-lang#139420 [old Windows]: https://archive.org/details/windowsinterface00micr/page/n9/mode/2up [old Mac]: https://archive.org/details/apple-hig/1996_Human_Interface_Guidelines_for_Mac_OS_8_%28WWDC_Release%29/page/16/mode/2up [NeXT]: https://archive.org/details/apple-hig/1993%20NeXTSTEP%20User%20Interface%20Guidelines%20-%20Release%203/page/145/mode/2up [OSX]: https://dn721903.ca.archive.org/0/items/apple-hig/MacOSX_HIG_2005_09_08.pdf#page=267
notriddle
force-pushed
the
notriddle/ew-resize
branch
from
036eee8 to
8780d5f
Compare
| @@ -1,4 +1,6 @@ | |||
| /* When static files are updated, their suffixes need to be updated. | |||
| /* | |||
| // ignore-tidy-filelength | |||
There was a problem hiding this comment.
You're sure you want to put this comment here? ^^'
There was a problem hiding this comment.
Can't put it at the top of the file. CSS doesn't have single-line comments.
I have to put it in there, because the file is over 3000 lines.
There was a problem hiding this comment.
Ok I see. I thought non-inline comments were supported. I'm gonna send a PR to support it.
There was a problem hiding this comment.
It's not a missing feature in the minifier. The CSS standard doesn't have // comments, and I don't want to require a compile step for our stylesheet.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_syntax/Comments
There was a problem hiding this comment.
/* ignore-tidy-filelength */ is supported already.
|
Can you host a page with this change please? |
|
Struggling to see the handle as anything other than 4 pokéballs.
|
|
here's an attempt using a radial gradient: |
|
I'm also not a big fan. What about no gradient, just plain dots? Also: I like how gimp implemented it, but it requires to have a right border, not sure if it's a good idea or not... |
Three dots stacked like that is an ellipses, and could be misinterpreted as a menu button.
I would like to avoid using unsubtle Aqua/Aero-ish gradients. They look out of place in Rustdoc, and there's plenty of good cel shading examples to pull from instead. A radial gradient isn't a bad idea, though. Maybe something like this?
|
|
The problem I have with the cell shading version is it leads to some pretty bad aliasing on low-resolution screens. part of why i'm tempted to use a text-based solution is because text rendering is already optimized for looking good at low resolutions. we would of course need to put in a bit of effort to make sure it doesn't mess too much with screen readers. |
|
I can usually address pixel aliasing by making it lower contrast and also making it bigger. It's important to do both, otherwise things get hard to see. I don't like making it much bigger, because this feature isn't important enough to make it so prominent, but I could make it bigger without actually making it bigger if I just went with the NeXT/OSX approach and called it good. I could use one spot instead of four.
|
|
what about a handle based on the double-stroke convention?
|
|
Yes, that's a good idea. |
|
BTW, i finally found a solid inspiration for my original arrow-based design: blender
in this case it's the faint upward pointing chevron. (at least i assume that's a resize handle, i haven't used blender in a while, and right now I can't check because it isn't launching) |
It's by far my preferred solution too. :) |
This aims to make the resizable sidebars more obvious
Preview: https://notriddle.com/rustdoc-html-demo-12/sidebar-resize-handle/std/index.html
This change is based on some discussion on lolbinarycat's idea, but with a more "traditional" design. Specifically, while very few systems use exactly this design, most of them use a skeumorph of "grip notching":
In Jira, resizable sidebars have a stack of four dots.
In The GIMP, resizable sidebars have a stack of three dots.
In old Windows, "panes" are defined to have the same border style as a window, which has a raised appearance. To evoke this, the PR adds a lightweight "shadow" border, darker than the sidebar itself
In NeXT, a drag point usually had an innie, whether the line in a slider or the circle in a scroller; I can also hide and show the favorites bar in Workspace by dragging on a circular "grip spot"
In old Mac, drag handles for things usually had a "grip track" of parallel lines.
This design is far closer to old Mac than anything else, though they've put it in the bottom corner instead of the middle.
OSX kept that, but the "Source List" part of the Finder still had the circle grip for a time the same way Workspace did (resulting in an odd mishmash, if you compare the source list sidebar with the other grip tracks embedded in the scrollbars).