Threaded View: Why Does the Font Size Decrease?

[mwolfenstein]

Hello Discussions Redesign Team and Fellow Community Members,

First, I'm thrilled that the threaded view is finally available. I would have preferred much clearer communication on when it was going to be available, but now that it's here I can actually let my faculty know that this tool is a viable option for them.

One immediate concern I have with the threaded view is the font size in replies. For some reason, the font size for replies is .875 rem. The smaller size is definitely not necessary to indicate that the reply has a parent comment since the indentation makes that abundantly evident, and I'm very concerned about the readability of the smaller font for users who don't have great vision.

What exactly was the design justification for making the reply font smaller, and has this been thoroughly tested with an array of users with different visual acuity to make sure that there is not a problem for users with lower acuity or a visual impairment?

Best,
-Moses

[venitk]

As a middle aged person who has not yet transitioned to reading glasses, I also found the diminished font size to be a problem. 

[Shar]

Hi Moses! @mwolfenstein 

Yeah, tiny font is a problem for me too. I did some CSS tweaks to increase the font and border the replies. Also, the replies do not continue to indent endlessly (yay!) but stop at 2 levels from the initial reply post.

Here's the screenshot result of my CSS. code below.

Threaded discussions redesigned

I think that this code will be stable and I have in use on a live course right now. But we'll see when enforcement date rolls around. I only added this code to the main CSS and not the mobile.

I decided to style the reply borders in the same way the light grey border around the discussion prompt is styled. The initial reply is darkcyan and thread replies are darkorchid. By default, when the discussion loads it will show all the darkcyan replies.

/** Discussion redesign - Jan 2024 **/
/* border on first reply in thread */
.css-8rac1c-view-flexItem {
	border-bottom-left-radius: 0.25rem;
	border-width: 0.0625rem;
	border-radius: 0.25rem;
	border-style: solid;
	border-color: darkcyan;
}

/* border on thread reply text */
.css-1hatz2-view-flexItem	{
	border-width: 0.0625rem;
	border-radius: 0.25rem;
	border-style: solid;
	border-color: darkorchid;
}

/* font size on thread reply text */
.css-138gh4t-view .user_content {
	font-size: 1rem;
}

And for me the font is the biggest improvement. My hope is that when Discussions Redesign is enforced that these little wrinkles will be all ironed out and my CSS alterations will not be needed.

Happy new year!
Cheers - Shar ⭐

[ahosmer]

Thanks for posting this CSS! Our institution used the CSS posted about in Jeff's thread: https://community.canvaslms.com/t5/Discussions-Announcements/CSS-Tweaks-for-Discussion-Redesign/m-p/.... Because our faculty were accustomed to a stronger graphic representation of initial posts and follow-up replies, the Discussions Redesign really seemed like a step backward. We'll wait on the enforcement date updates to see if this will still be necessary, but it's good to know we have an option to alleviate some of the issues.

[canvas_admin]

Hi @Shar , it looks like with a recent update, the borders of replies now touch the border of the original post (as well as any additional reply).  Do you perhaps have a tweak for your code that would add some space between an original post and any replies to it?

[Shar]

Hi @canvas_admin (Mark James),

Oh Canvas did change the ID selectors and my cool color-differentiated initial & thread replies code no longer works. But @cesbrandt code using DOM selectors still works! 😎 See Border/Padding solution and scroll down and load more replies from that one and there's even code to take out the HR post separator because it's looks odd with the borders around the replies now.

I'm going to be switching over to that code, again hoping that it will stay stable for a while yet to come. And I see what you mean about the borders touching, so I'll add some margin at the bottom so the full code now looks like:

[data-testid="discussion-root-entry-container"] [data-testid="notHighlighted"] > * > [class*="css-"][class*="-view--flex-flex"]:first-of-type > [class*="css-"][class*="-view-flexItem"]:first-of-type:has([class*="css-"][class*="-view-flexItem"]),
[data-testid="discussions-split-screen-view-content"] [data-testid="notHighlighted"] > [class*="css-"][class*="-view--flex-flex"]:first-of-type > [class*="css-"][class*="-view-flexItem"]:first-of-type:has([class*="css-"][class*="-view-flexItem"]) {
    border: 1px solid #c7cdd1;
    border-radius: .25rem;
    padding-top: .75rem;
    margin-bottom: 0.5rem;
}
[data-testid="post-separator"] {
	display: none;
}

Hope this helps,
Cheers - Shar ⭐

[canvas_admin]

Brilliant!  I am in your debt and appreciate your help immensely.

[cesbrandt]

Yeah...I wouldn't hold my breathe for that. Now that it's been enforced for everyone, those who avoided it are flooding Instructure with tickets. I am surprised/grateful that my version hasn't been too affected thus far. The only variation from the block @Shar made is that we went with `0.75rem` for our `margin-bottom`:

[data-testid="discussion-root-entry-container"] [data-testid="notHighlighted"] > * > [class*="css-"][class*="-view--flex-flex"]:first-of-type > [class*="css-"][class*="-view-flexItem"]:first-of-type:has([class*="css-"][class*="-view-flexItem"]), [data-testid="discussions-split-screen-view-content"] [data-testid="notHighlighted"] > [class*="css-"][class*="-view--flex-flex"]:first-of-type > [class*="css-"][class*="-view-flexItem"]:first-of-type:has([class*="css-"][class*="-view-flexItem"]) {
	border: 1px solid #c7cdd1;
	border-radius: 0.25rem;
	padding: 0.75rem;
	margin-bottom: 0.75rem;
}

[data-testid="post-separator"] {
	display: none;
}

I was so annoyed last week to find the padding/margin so broken. At least is wasn't the selectors! xD

[Shar]

Yes, @cesbrandt and @canvas_admin 

I was so happy for the Discussion Summaries that I didn't even notice when the borders slipped off. Anyway, I couldn't leave well enough alone and got really use to having first thread reply a different color border. So I tinkered again, using the selector path to put a color on that first post of a thread. I know it will break when they clean up the code (because right now it uses inline CSS to indent the reply posts).

[data-testid="discussion-root-entry-container"] [data-testid="notHighlighted"] > * > [class*="css-"][class*="-view--flex-flex"]:first-of-type > [class*="css-"][class*="-view-flexItem"]:first-of-type:has([class*="css-"][class*="-view-flexItem"]),
[data-testid="discussions-split-screen-view-content"] [data-testid="notHighlighted"] > [class*="css-"][class*="-view--flex-flex"]:first-of-type > [class*="css-"][class*="-view-flexItem"]:first-of-type:has([class*="css-"][class*="-view-flexItem"]) {
    border: 1px solid var(--ic-brand-button--secondary-bgd);	/* Subaccount purple */
    border-radius: .25rem;
    padding-top: .75rem;
    margin-bottom: 0.5rem;
}

[data-testid="post-separator"] {
	display: none;
}

/* Border for first reply post of a thread */
#content > div > div > div > div > span > div.css-pnbk90-view > div > div > div > span > span {
    border-color: darkcyan;
}

I like the darkcyan over my account's var(--ic-brand-primary) because this primary color blue and that's just too much of that blue on the page around those first post threads.

Here's the result:

Borders around reply posts

Here's hoping it lasts for the month,
Cheers - Shar ⭐

[canvas_admin]

Hi @Shar

I notice from your screenshot that you have a little scrollbar after your pill identifier. I have those on mine as well and I'm wondering how I can get rid of that.  I've tried setting the overflow to just "hidden" or just "visible" (in other words, trying to remove the additional "auto" in that css field), but that doesn't seem to be working.

@cesbrandt I don't know if you may have some thoughts on that also?

[cesbrandt]

Are you referring to the double scrollbar issue? If so, that's actually an issue caused by the improper sizing of the course navbar. It's sized for `100vh`, but it should account for the top breadcrumb bar. The redesign does have a flawed height value, too, being set to `90vh` it doesn't take up the full height of the main area. This should fix both:

#sticky-container, #sticky-container, #content .discussion-redesign-layout [class*="css-"][class*="-drawerLayout"] > [class*="css-"][class*="-drawerLayout__content"] > [class*="css-"][class*="-view--block"] {
	height: calc(100vh - 4.5rem);
}

[canvas_admin]

Hello,

Here's the scrollbar to which I am referring. It only seems to happen on posts where there is an identifying pill (Teacher, TA, Designer, etc.)

[cesbrandt]

For that, and I make NO promises this won't affect something else (I don't think it will, since nothing else in the redesign appears to have scrollbars), try:

.discussion-redesign-layout [class*="css-"][class*="-view--flex-flex"] {
	overflow: hidden;
}

It'd be easier to do this stuff more safely if the redesign had been block indicators, not just this painful generic classes that will be changed every time the CSS is recompiled...

[canvas_admin]

Many thanks for that!   After applying your code, I noticed the border around "reply" was partially cut off at the bottom when expanding to see the reply.

So I added the below to add some slight padding to that row to restore the bottom of that border in its fullness.  It may not be the best way but I'm still rather a novice at these things.

.discussion-redesign-layout [class*="css-"][class*="-view--block"] {
	padding-bottom: .30rem;
}