Closed ericscheid closed 2 months ago
Adding as an issue for ease of finding in the future.
(All PRs really should start from an issue, fwiw)
The base CSS change has been applied and merged now.
Making note of this exchange about having the scrollbar auto-hide, so it doesn't get lost:
On MacOS, I have the option of having scroll bars auto-hide, but this css has the thumb always visible. Blech.
It would likely need a onScroll event on the brewRenderer to change the opacity of the scroll bar (with a fade transition to make it smooth).
Right. I don't think there is a CSS-only way to detect the scrolling state. It is possible with Javascript. Found this example that uses event listeners:
const scrollableDiv = document.getElementById("scrollable"); let scrollingTimeout; scrollableDiv.addEventListener("scroll", () => { clearTimeout(scrollingTimeout); scrollableDiv.style.setProperty("--scrollbar-thumb-color", "black"); scrollingTimeout = setTimeout(() => { scrollableDiv.style.setProperty("--scrollbar-thumb-color", "rgba(90, 90, 90, 0.5)"); }, 300); // Adjust the delay as needed });
A minor layout issue with the new scrollbar - the page numbers appear under the scroll bar.
I know this is merged already, and there was an opportunity to comment before it was, so this is sort of pissing in the wind--- but I'm not a huge fan of this change.
.CodeMirror-sizer {
padding-right: 0 !important;
So instead of this:
there is this:
I do think there is something to be said for auto-hiding the scrollbar, but I also know that doing so can illicit some strong feelings from internet denizens, and is also less accessible.
There are also some more technical issues with the current merged change. It seems like in order to get a custom 'width' of the scroll bar thumb, the background
property of the thumb uses a linear-gradient
with a sharp cut to transparent at 15px (so the thumb is only 15px wide). This works on vertical scrollbars, but doesn't work well with horizontal bars. Here is an example of what the scrollbar looks like on the live site, followed by an example of what the same scrollbar looks like with the merged changes:
live:
with changes:
The thumb bit only shows a 15 x 15 square, but it is actually the same width as the thumb in the original. Which means that I can only move the visible part of the thumb a fraction of the width of the page. This made me think it was broken until I took a few closer looks. The furthest right I can move the thumb:
All adressed in #3388
For clarifying, i don't think we want to auto-hide the scrollbar at all, it is less accessible. But if you Really want it, i will implement it.
auto-hiding the scrollbar
I agree, there isn't much value to this.
There is an annoying white square in the bottom right of the preview pane,
I see that it isn't there anymore, using &-corner
and setting it to hidden. It still looks odd to me in the way the default scrollbars don't. Have a track color + a matching corner color feels better, to me. Somehow, more solid, something that the thumb 'bumps' into. I made an example below. I added a border to the track, only to the top edge of the horizontal scroll and the left edge of the vertical scroll. I also set the corner color to something slightly darker than the thumb. And I reduced the width to 15px. And I temporarily removed the '.pageInfo' div so it shows better:
Speaking of .pageInfo
div....this would be more work, but I think the solution that I would be most enthused about is to get the page info box into the bottom right corner, and become a sort of 'toolbar' in the future. This would supplant the need for a "corner box", since it would become a permanent corner box. The trick is that the scroll bars might need to be custom JS thing, since their width wouldn't be the true width of the scrolled element (in this case, the scroll bar wouldn't be the same width as the pane).
Moving on, I'm not sure if it's intentional to have this little bit of color change in the scroll thumb? It's because the height/width of the scrollbar tracks are set to 20px, and the thumb gradient steps are at 15px. I would suggest not using a gradient at all, and using a flat color since the rest of the UI just uses flat design.
The reason for the gradient on itself is to visually separate the scrollbar from the window border, that is the only CSS way i have found to do so.
I love your idea for the js scrollbar to incorporate pageinfo, looks cool, but don't think i have the time to make it. Also that might just be our lowest priority.
About the corner, am i the only one who prefers scrollbars without tracks? when the track is obviously the page entire size, it looks very antiquated to me. If it were up to me, i would leave it as overlay without tracks.
I personally just like the normal scrollbars because they are so common and basically 'disappear' from my vision even if they don't actually disappear. Anything that draws my attention to them is bad. So my first preference is to leave them untouched.
I do like a track, as it provides a hard edge for the document (since I also don't like to have my scrollbar overlapping what i'm reading/writing).
And I prefer a narrow scrollbar rather than wider, for screen real estate reasons-- but honestly it's likely the "what I am used to" factor too.
In short, I don't think any change to the scrollbars is necessary or desired. But I also am just one person and don't want to squash dreams. Mostly I'm just raising these points so that there is some record of possible objections, rather than just a "no one commented, so it must be good" process.
It seems like it might be possible to get a shorter scrollbar that only spans a fraction of the scrolled element, but I'm still researching it. There are webkit-only solutions (like most of the scrollbar styling options), as seen in this fiddle, but it's not perfect and i hesitate to reach for chrome-only things when it comes to simple UI choices.
It's a scrollbar, not a dream. We could revert to the original and forget about this headache.
Can the scrollbars be reverted, and such a change be left for users styles (via Stylish extension or similar)?
Found another issue tonight: the CodeMirror lines don't stretch to the edge of the pane. I assume there is some hardcoded width for these lines that is somewhere in CM, but I'm not sure where.
Can the scrollbars be reverted, and such a change be left for users styles (via Stylish extension or similar)?
Found another issue tonight: the CodeMirror lines don't stretch to the edge of the pane. I assume there is some hardcoded width for these lines that is somewhere in CM, but I'm not sure where.
John? you asked for this specifically a few weeks ago https://github.com/naturalcrit/homebrewery/issues/3355#issuecomment-2026655526
Yeah I suppose in a way I did, but I don't think this is exactly a reversal of my earlier position, just an addendum.
A solid spanning decoration like the page break line highlight seems odd if it stops just short of the "visual edge" of the editor. I know earlier that I didn't want to have a scrollbar overlapping my text content but I think this is something different than "my content". Covering my written text, which I may be actively reading or even editing, is visually intrusive. Covering an editor decoration, on the other hand, doesn't seem as big of a problem. Regarding covering the page number text...eh, not in love with it, but I still think stretching the page line break to the "visual edge" is higher priority.
So my preference would be:
Native scrollbars achieve both-- nothing covers content, and the visible track edges provide a different "visual edge" to the editor to which the full width line highlights can span and connect to.
Native scrollbars are obviously my preference, but in the interest of being open to different options, maybe the below will help with the current implementation:
Change the line highlight for the page breaks to have a width of 110% or similar.
It'd be here: https://github.com/NaturalCrit/homebrewery/blob/master/client/homebrew/editor/editor.less#L8
Your idea:
5e-Cleric writes..