I've been staying quiet about several UX problems in the new vertical scrolling improvements, but with the upcoming release, I can't stay quiet if I hope to have these fixed before that release.

1. What's with the gray bar to the right of posts that scroll vertically? It appeared a week or so ago, and I assumed it was a buglet that would get squished quickly, but... At minimum, it should be made invisible in CSS, but if we can make it go away entirely, reclaiming that real estate, that'd be better.

2. I'm not super-happy with the new feature to make reading on a phone easier by allowing post collapse/expand. I thought the whole point of this was to prevent secondary vertical scrollbars, but they still occur. This is especially annoying on mobile, since the interpretation of a vertical swipe depends on where you start swiping.

   Shouldn't this feature set overflow-y to "clip" so that you must press the new "⇣ ⇣ ⇣" button to see the rest, if you want? That would make vertical scrolling nicer on all platforms, since there would be only one vertical scrollbar. If you want to see the rest of the post, expand it.

3. The 1px black border on that button doesn't blend with the default skin very well. (Ditto /fileedit and /wikiedit.) It's fine as a default, but I thought we'd at least make these blend into the default skin, if not go and edit all of the other stock skins. Are we just waiting for people to make commits here, or are we waiting for a UX designer to appear, or...?

What's with the gray bar to the right of posts that scroll vertically?

In short, it's to allow someone to collapse a post when they're halfway scrolled through it (and might be hundreds or thousands of lines away from either the top or bottom). That was previously done using double-tap on the post, but that interferes with browser-side selection of text.

Shouldn't this feature set overflow-y to "clip" so that you must press the new "⇣ ⇣ ⇣" button to see the rest, if you want? That would make vertical scrolling nicer on all platforms, since there would be only one vertical scrollbar. If you want to see the rest of the post, expand it.

That's a very interesting idea - i hadn't considered that but will give it a try that out after the dog walk.

The 1px black border on that button doesn't blend with the default skin very well.

The border color is not set by that component - it's inherited:

.forum-post-collapser {
  font-size: 0.8em;
  margin: 0.2em 0 0 0;
  padding: 0;
  height: 1.75em;
  line-height: 1.75em;
  border-width: 1px;
  border-style: solid;
  border-radius: 0.25em;
  opacity: 0.8;
  cursor: pointer;
  display: flex;
  flex-direction: row;
  justify-content: space-between;
}

The skin on this site does not set that, so it's being inherited from the browser default.

The collapser code is careful not to assign any colors due to potential skin clashes, with the necessary exception of the "tap bar" along the right (which we try to "unclash" by making it mostly translucent).

Edit:

1. ... Are we just waiting for people to make commits here, or are we waiting for a UX designer to appear, or...?

It's just been awaiting feedback, but a UX designer who could make such changes would not hurt. The black doesn't seem to clash to me - it's the same border style used by the "original post" block in this editor (and in that case it is explicitly set to black).

Shouldn't this feature set overflow-y to "clip" so that you must press the new "⇣ ⇣ ⇣" button to see the rest, if you want?

Please try this out and let me know what you think:

Index: src/default.css
==================================================================
--- src/default.css
+++ src/default.css
@@ -809,10 +809,13 @@
 }
 div.forumPostBody.with-expander {
   display: flex;
   flex-direction: row;
   overflow: auto;
+}
+div.forumPostBody.with-expander:not(.expanded) > :first-child {
+  overflow-y: hidden;
 }
 div.forumPostBody.with-expander > *:first-child {
   /* Main content DIV */
   overflow: auto;
 }

i'm currently torn on whether or not it's an improvement, but also don't currently have a strong opinion one way or the other. It's an interesting approach, in any case, but only practice will tell me whether or not i like it better.

it's to allow someone to collapse a post

How is that discoverable?

I mean, yes, obviously, click it and you find out, but it's brand-new design language. Who is trained to try this and expect the result when they see it?

As styled, it looks like an HTML layout bug. I'm not trying to be mean, just telling you what I perceive.

If we're keeping this feature, the box has to have some sort of content that communicates "You can click this, and it will toggle the expanded state of the post." A few vertical ellipses, perhaps:︙

And the gray has to go. It could be boxed like with the horizontal companion feature at the bottom of the post, which would communicate "This thing is kinda like the other one down there."

it's inherited:

Fine, but it can be overridden. I'm thinking about a 5-10% opacity black overlay to make it blend into either the white or the blue post background, possibly with a slightly darker border.

Better would be a gradient with a very slightly darker border, as with the default skin's main button bar.

The default skin also uses roundrects in preference to regular rectangles, so the corners of these boxes should be radiused to match.

it's the same border style used by the "original post" block in this editor

It would be nice of those were pale gray roundrects as well.

The collapse button is worse because it's a box-within-a-box, so it emphasizes the lines. It's exactly analogous to a handwritten note with a word that's underlined once vs being underlined twice: the human brain interprets it as emphasis.

i'm currently torn on whether or not it's an improvement

Use it to browse any long thread on a phone, and you'll see that it's a massive improvement. Vertical swipe always does the right thing now. It's what I expected this feature to do from the start.

How is that discoverable?

By accident :/. If you have a suggestion for how to quickly "escape" from the middle of a long post, i'm all ears. i'm not at all happy with having to have that widget, but a better solution has yet to be proposed (and having to scroll arbitrarily far down/up to find an exit point is a usability nightmare).

As styled, it looks like an HTML layout bug. I'm not trying to be mean, just telling you what I perceive.

Style improvements are always welcomed - that has never been a forte of mine.

If we're keeping this feature, the box has to have some sort of content that communicates "You can click this, and it will toggle the expanded state of the post." A few vertical ellipses, perhaps:︙

Agreed. The problem is figuring out how many "a few" is: that line can be 60em or 15000em tall. If we have a fixed number, say 3, they're only on-screen on small fractions of long posts. i'll see if i can reasonably calculate how many to stick in there, and space the same way the up/down arrows are done (with flexbox layout).

Fine, but it can be overridden. I'm thinking about a 5-10% opacity black overlay to make it blend into either the white or the blue post background, possibly with a slightly darker border.

That element has an opacity already, but if it's too light then the arrows won't be legible. If you mean adding another, same-sized element on top of it, with no content but an opacity, that sounds like major overkill for a minor style preference. If the border bugs you that much then remove it or recolor it rather than bury it under yet more DOM bits. (Just note that almost any explicit color is likely to clash with some skin or other, thus my strong preference for inheriting all colors.)

The default skin also uses roundrects in preference to regular rectangles, so the corners of these boxes should be radiused to match.

i don't see any rounded corners in the forum, with this skin, except for that specific element (with 0.25em corners).

it's the same border style used by the "original post" block in this editor

It would be nice of those were pale gray roundrects as well.

That's a skin-level/default.css-level decision. i'm not at all against seeing it changed, but am not going to make arbitrary style changes, in the context of the collapser, which affect other parts of the page, for the simple reasons that (A) there's no accounting for UI tastes and (B) i have no UI taste.

(FWIW, i almost always prefer rounded rects, but don't want to impose that personal preference site-wide in default.css.)

The collapse button is worse because it's a box-within-a-box, so it emphasizes the lines. It's exactly analogous to a handwritten note with a word that's underlined once vs being underlined twice: the human brain interprets it as emphasis.

That's unintentional but it kinda is an emphasis: "tap here to keep to see the rest."

Feel free to make all the style tweaks you want on those bits. My only style-related recommendation is to avoid setting any colors at all, when possible, to avoid clashes with arbitrary skins. Currently the only color this CSS sets it the right collapse bar, and translucent grey was chosen because it seems the least likely to either clash horribly or be outright invisible in any given skin.

Just a sketch, but it should communicate the idea:

That's all implemented now, and looks nicer. It'll be checked in soon - still working through my email/post backlog.

Related: i tried a gradient but it made the tap zone stick out like a sore thumb. It didn't fit at all, visually.

For some reason the "content" styles aren't working, but from your recent experience, you should be able to debug it.

Indeed - i recently chased that very same thing down and it turns out that content only works with :before and :after selectors. (And just this moment learned that :before and ::before are the same thing, but the former is CSS2 and the latter CSS3.)

There should be some CSS-fu that says "top, middle, and bottom", analogously to the way you currently place the arrows on the collapser.

Yes and no. There is an easy solution using flexbox layout but the problem is how many such markers to place. It turns out that that value has to be dynamically determined when the post is set up, expanded, and collapsed. That's solved now but not yet checked in. It places an up or down arrow (the same arrow as on the collapse button) every so often, spanning the whole current height of the widget.

I'm talking only about the opacity of the background and borders. The opacity of the content is a separate matter.

Trivia: opacities is, incidentally, German for "grandfather cities".

i'm not at all happy with having to have that widget, but a better solution has yet to be proposed

This is a shot in the dark, but isn't there a possibility to show the collapse button with position fixed right above (or on) the first currently visible line of expanded post? I don't know if it's doable in current CSS, but maybe?

That's all implemented now, and looks nicer. It'll be checked in soon - still working through my email/post backlog.

Warren's suggestions have been implemented and checked in, along with one other: collapsing a post and scrolling it to the top of the page now happens relatively smoothly, instead of in 1 single flash:

contentElem.parentElement.scrollIntoView({
  /* This is non-standard, but !(MSIE, Safari) supposedly support it:
     https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView#Browser_compatibility
  */
  behavior: 'smooth'
});

Can we please get a Safari (desktop or mobile) user to confirm that collapsing a post (with the latest trunk) does not cause the browser to implode?

Ideally Safari will simply treat that object argument to scrollIntoView() as "truthy", or ignore it outright, as opposed to throwing a JS exception. If it instead throws an exception then that visual improvement will have to be removed.

This is a shot in the dark, but isn't there a possibility to show the collapse button with position fixed right above (or on) the first currently visible line of expanded post? I don't know if it's doable in current CSS, but maybe?

That could hypothetically be done with JS (not CSS), but it turns into a can of worms if multiple collapsible posts are on-screen at once. That case wouldn't generally happen, since such posts are, by definition, quite large, but it is indeed possible to have the bottom of one collapsible post and the top of another on the screen at once.

Warren's suggestions have been implemented and checked in

There's a regression relative to my version: the collapser and expander have different background colors. I think they should both shade the underlying background slightly so it's clear they aren't content. The border alone is helpful, but the shaded background helps.

Safari (desktop or mobile) user to confirm...

It seems to behave reasonably on both, modulo the next point.

...scrollIntoView()

Is that what's getting called on page load to bring the linked post to the top of the window? It doesn't always put the top of the post at the top of the screen.

This isn't Safari-specific: I'm seeing it on desktop Firefox right now as well.

It looks like maybe it's trying to center the post in the viewport, but if the post is longer than the viewport, it fails?

Part of this might be due to when it's called: if it's called too early, the layout hasn't settled, so a target Y value on the scroll bar will shift after the event handler is called.

There's a regression relative to my version: the collapser and expander have different background colors. I think they should both shade the underlying background slightly so it's clear they aren't content. The border alone is helpful, but the shaded background helps.

That's fixed now, and those two styles have been consolidated under a single class, so the two will remain consistent.

Is that what's getting called on page load to bring the linked post to the top of the window? It doesn't always put the top of the post at the top of the screen.

It can't do so if the page is not long enough - you're "probably" viewing a post very near the bottom of the page?

It looks like maybe it's trying to center the post in the viewport, but if the post is longer than the viewport, it fails?

It should ideally move the post to the top. Can you please try both of these (currently line 19 of fossil.page.forumpost.js) and commit whichever one works best for you:

          contentElem.parentElement.scrollIntoView({
            /* This is non-standard, but !(MSIE, Safari) supposedly support it:
               https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView#Browser_compatibility
            */
            behavior: 'smooth',
            block: 'start',
            inline: 'nearest'
          });

or (fallback): simply remove the argument to scrollIntoView(). That was the behaviour before this change.

Could the collapse/expand button be made sticky within the div div class="forumPostBody with-expander" that holds a message?

This way it would scroll down with the message sticking to the top of the viewport when the message top scrolls off the screen. Then it will scroll away when the next message displays.

https://dev.caniuse.com/css-sticky looks like IE and Opera mini are problems, but edge, ff, chrome and safari (with vendor prefix) work.

https://alligator.io/css/position-sticky/

https://dev.caniuse.com/css-sticky looks like IE and Opera mini are problems, but edge, ff, chrome and safari (with vendor prefix) work.

i have a pedantic personal hangup against using any vendor prefixes at all. When it comes to HTML, CSS, and JS, if it's not in a standard, or hasn't at least been widely used for 5+ years, i'm extremely hesitant to use it.

After adding Warren's tweaks to the right-side bar, i'm quite happy with how that one is looking, and the new arrows on it either indicate what it does or at least may entice the user to tap on it to find out, whereas before it was just a blank space (more like an Easter egg than a feature).

There are several problems here:

1. Despite what MDN says, you need the alignToTop: true option to get the behavior you expect. Maybe you like what it does instead, but since you say it should scroll to the top...

2. This isn't what I was talking about up-thread anyway, which is the case where there's a post ID in the URL, so it's selected and needs to scroll into view after the page loads. That hasn't been working right since all of this collapse/expand stuff started to go in, weeks ago.

3. There's another call in src/scroll.js that you should probably change to match, for consistent behavior across Fossil UI.

Index: src/forum.js
==================================================================
--- src/forum.js
+++ src/forum.js
@@ -12,8 +12,8 @@
   if(x[0]){
     var w = window.innerHeight;
     var h = x[0].scrollHeight;
     var y = absoluteY(x[0]);
     if( w>h ) y = y + (h-w)/2;
-    if( y>0 ) window.scrollTo(0, y);
+    if( y>0 ) x[0].scrollIntoView({ alignToTop: true, behavior: 'smooth' });
   }
 })();

Index: src/fossil.page.forumpost.js
==================================================================
--- src/fossil.page.forumpost.js
+++ src/fossil.page.forumpost.js
@@ -16,11 +16,13 @@
         if(wasExpanded){
           contentElem.classList.add('shrunken');
           contentElem.parentElement.scrollIntoView({
             /* This is non-standard, but !(MSIE, Safari) supposedly support it:
                https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView#Browser_compatibility
-            */ behavior: 'smooth'
+            */
+            alignToTop: true,
+            behavior: 'smooth'
           });
         }else{
           contentElem.classList.remove('shrunken');
         }
         return false;

Index: src/scroll.js
==================================================================
--- src/scroll.js
+++ src/scroll.js
@@ -1,2 +1,2 @@
 /* Cause the page to scroll so that the #scrollToMe is visible */
-document.getElementById('scrollToMe').scrollIntoView(true);
+document.getElementById('scrollToMe').scrollIntoView({ alignToTop: true, behavior: 'smooth' });

I could commit this, but I think it should be consolidated to a single implementation first, which is more your wheelhouse, Stephan.

...and there's another window.scrollTo() call in graph.js.

If you're going to make a single version for all users, it should call it, too.

I could commit this, but I think it should be consolidated to a single implementation first, which is more your wheelhouse, Stephan.

i will be glad to do that but don't want to touch the trunk for non-critical fixes now, else Richard will need to rebuild. Once the release is cut (probably the next few days) i'll consolidate those.

The jump in the line number output is intentionally (legacy behavior) not right at the first highlighted code section: when the page is generated, if the highlighting is more than 15-ish lines from the top then the jump-point is added approximately 15 lines above the first highlight block, presumably to improve the level of code context for the viewer. (Edit: sorry, different context. That was another thread.)

Use it to browse any long thread on a phone, and you'll see that it's a massive improvement. Vertical swipe always does the right thing now. It's what I expected this feature to do from the start.

i'm still getting used to it - my mouse-scroll finger still tries to scroll down unexpanded posts - but i'm coming around to it. i haven't yet, since this change, used the forum on my phone, but certainly understand the discomfort the inner-scrolling of posts causes/caused there.