Display glitch in sidebar width, even at tw-com and empty versions

#1

Months ago I assumed this problem was related to the resizer plugin, and I was just now typing up a followup nudge for @BurningTreeC before I decided to just try isolating the problem a bit more carefully…

Please see if you can reproduce this:

  • Using Chrome (I’m on Version 144.0.7559.59 but it’s not a new problem), open an empty version of the prerelease: https://tiddlywiki.com/prerelease/empty.html (I swear I have seen a version of this glitch in Safari, but can’t reproduce it reliably.)

  • Now open and close the control panel. Watch the sidebar resize itself slightly, toggling size each time you open and close the control panel.

If it doesn’t happen at your initial browser magnification and window width, try variations and see.

(For me, it happens in Chrome at the default 100% browser magnification, and my default browser window size, basically full-screen on my iMac. On some other sites of mine, I get the problem only at other browser magnifications, such as 80% 90% and 110%.)

The problem also shows up for me in 5.3.8 empty, IF I enable “fluid story, fixed sidebar” setting, then close and open the control panel.

Also! Normally we don’t see this glitch with tw-com main site. But close ALL tiddlers, and you may see the sidebar redraw itself at a different width. Opening certain tiddlers (and tiddlers that somehow transclude them) — but not just any old tiddler! — causes the sidebar width to recalculate…

You can also see a back-and-forth hiccup in sidebar width if you open a tiddler like Date Fields via permalink so it’s the only thing open — and toggle in and out of edit mode.

(It’s conceivable that this problem involves some further dependency, but it happens for me even in an incognito window in Chrome, where my usual toolkit of extensions is disabled, and as I say, I’ve intermittently noticed this glitch for months, so it’s persisting across routine google chrome updates.)

#2

Hi @Springer

I remember having seen something similar… does it have to do with the scrollbar appearing / disappearing?

1 Like
#3

It certainly looks as though it does.

If enough other tiddlers are open to cause a scrollbar, I see no jumps. Also, the same behavior happens if any tiddlers opening and closing cause the scrollbar to appear or disappear.

#4

This effect occurs when the StoryRiver content is longer than one screen, and thus requires a scrollbar on the right (in addition to the scrollbar for the sidebar) to scroll the StoryRiver.

For alternative scrollbar handling, you can try TiddlyTools/Stylesheet/TopBar which provides enhanced topbar handling and also moves the StoryRiver scrollbar to the left side of the StoryRiver. This avoids the “sidebar wiggle” effect that you observed.

TiddlyTools TopBar also provides the following page layout enhancements:

  • The topbar (or menubar) display has “pin” buttons (upper-left or upper-right corner of the window) that let you “unpin” the topbar so it is automatically hidden (slides up out ot the way).
  • While unpinned, the pin buttons are replaced by “up/down arrow” symbols.
  • Mouseover near the top of the window causes the unpinned topbar to slide back into view.
  • Click on either up/down arrow button to re-pin the topbar.
  • Ctrl-click on a topbar pin (or up/down arrow) button will show a popup for topbar configuration settings:
    • a checkbox to toggle “pin top bars” (same as clicking on a topbar pin button)
    • a checkbox for “scrollbar on left” (the default).
      • Clearing this checkbox places the scrollbar on the right side of the StoryRiver (NOT the right side of the window!). This also avoids the “sidebar wiggle” issue that you observed.
    • a “size=” input control. Enter a number (default=1) to scale the topbar contents. This can be particularly useful for people with vision issues or on very large screens.

enjoy,
-e

1 Like
#5

This is no glitch. That’s standard browser behaviour and has nothing to do with TiddlyWiki. If you use a browser that uses “invisible” scrollbars, the behaviour is different.

#6

Hello @BurningTreeC ! Thank you for this again. I have a different whish: Could the value be written to the $:/themes/tiddlywiki/vanilla/metrics/storyright parallely? It somehow is changed later on I would like to use the value simultanously for a font magnifier for the sidebar. (Making the sidebar bigger makes the font in a certain div in the sidebar bigger)

PS: I told you I wanted to use your resizer for an independent left sidebar. I managed to do this here: Multimenu — a style Test for TW

#7

Lol. It’s not a glitch with TiddlyWiki, I now realize.

However, it is a glitchy experience for the end-user!

Ultimately, I’d like to find a way to help TiddlyWiki load in such a way that the horizontal screen real-estate required for the scrollbar is always claimed, so that sidebar rendering doesn’t lurch back and forth depending on the length of what’s in the story river.

Or:

This sounds promising!

I’ll change the post category from “Developer” to “help-appreciated”…

Still, my vote would go to having the scrollbar render next to the thing that gets scrolled! Is that not, overall, the more logical approach?

#8

Small bit of feedback from a Mac user:

The ctrl key for configuring topbar items doesn’t work on a mac, since ctrl is the standard way to get the browser-level contextual menu, which gets higher priority than triggers determined within the active window. I got meta to work (metabeing how the browser hears what MacOS users think of as the “command” key — which is the natural thing Mac users expect for most local shortcuts). I got option and shift to work as well. All good for me, but a naive mac user may be flummoxed…

(And if they’ve installed CodeMirror6 by @BurningTreeC as I have, they won’t even see the checkboxes and edit-size input area within your topbar stylesheet tiddler itself because the stylesheet tag “helpfully” triggers codeblock rendering… Luckily, @EricShulman duplicated those config options within a control panel tab…, and entirely naive users probably aren’t using CodeMirror anyway. :wink: )

#9

Is this CSS enough?

body {overflow: scroll;}

It does what you requested by adding a scrollbar even when it’s not strictly necessary. Thus it claims the space, but for some users that scrollbar might itself be an issue.

This is clearly a matter of taste, as I prefer the “glitchy” behavior.

#10

Why yes it is!

:face_with_monocle: :open_mouth: :confused: :thinking: :upside_down_face: :wink:

I didn’t think that was possible!

Now I have to question my intuitions about … everything! And now when you visit my site, it will be more the way I like it (thanks to your help!) … and less the way you like it! :sweat_smile:

#11

ouch! I don’t use Mac, so I sometimes forget about these kinds of UI differences.

I’ve updated TiddlyTools TopBar to use SHIFT-click instead of CTRL-click for the “local shortcut” to show the settings popup… and, as you’ve noted, TiddlyTools TopBar also adds these same settings to $:/ControlPanel > Settings > TopBar which is the TWCore standard way to provide add-on configuration options.

I agree. It always seemed sort of odd to me that the TWCore default has the StoryRiver scrollbar on the far right next to the SideBar scrollbar, but that’s because the StoryRiver is actually scrolling the whole page (!) while the SideBar container (.tc-sidebar-scrollable) uses CSS position:fixed with overflow:auto; for independent scrolling.

TiddlyTools TopBar was initially created to prevent the StoryRiver content from scrolling behind the TopBar content. It does this by setting the .tc-story-river height to (100vh - barheight) and adding overflow:auto; for independent scrolling. This implictly places the StoryRiver scrollbar on the right edge of the StoryRiver. Then, I added handling to move the scrollbar to the left edge of the StoryRiver (because I think it looks nice there). Of course, I made this optional, so you can just clear the “[x] scrollbar on left” checkbox to turn off this extra handling.

Note that even with TiddlyTools TopBar, the overflow:auto; CSS still causes a “wiggle” when the scrollbar appears/disappears, but it is the StoryRiver content that shifts rather than the SideBar content and, given that this will occur only when a tiddler is being added/removed from the StoryRiver, it’s not very noticeable.

The only way to completely eliminate the “wiggle” is to force the scrollbars to always be displayed by using overflow:scroll (as @Scott_Sauyet has already suggested). If you are using TiddlyTools TopBar, this adjustment need to be made to the .tc-story-river rather than the body, like this:

.tc-story-river { overflow:scroll !important; }

edit: I’ve just updated TiddlyTools/Stylesheet/TopBar to include a configuration checkbox for “[x] always show scrollbar”, so a custom CSS stylesheet tiddler is no longer necessary.

enjoy,
-e

1 Like
#12

Well now that I see it on your site, I’m not so sure. The default was fine on the empty wiki. I tend to prefer it on websites in general, but TW is more dynamic than most pages. On your site, it seems more jittery than I’m used to, not the location of the sidebar but the scrollbar itself.

What I would really like is a setting that reserves the place for the scrollbar, but doesn’t show one at all until it’s necessary. I would use that for pages that change height often.

2 Likes
#13

Maybe you need a scrollbar-gutter: stable property

2 Likes
#14

I like this CSS attribute alot (!) and have just added it to TiddlyTools/Stylesheet/TopBar to completely eliminate the StoryRiver “wiggle”. Note that browser support for scrollbar-gutter:stable is relatively new (Dec 2024 for Chromium,FireFox,Safari), but it is just ignored if not supported (i.e., other/older browsers).

Also, for those who prefer to always show the StoryRiver scrollbar (even when not needed), I’ve added a new configuration checkbox for “[x] always show scrollbar”, so a custom CSS stylesheet tiddler is no longer necessary to set overflow:scroll !important.

Technical note: the reason “!important” is needed for “overflow:scroll !important” is to force an override of the hard-coded overflow:auto attribute used by the TWCore $scrollable widget to show the .tc-story-river.

-e

#15

Yes, that. That exactly. You know, there were many years when I kept up with all the CSS changes. I guess those days are gone!

@springer: would this work well for you too?

I would really love it if we could remove all such hard-coded CSS.

1 Like