Great idea, updated.
Well, now my post looks stupid. 
Thank you!
2 Likes
I get tripped quite often by the fact that code samples are limited in vertical size but show no scrollbar when there is more to see.
Assuming I’m not the only one, would it be possible to either display a scrollbar or not limit the vertical size? After all, we do not limit the vertical size of other texts.
I’m going to hazard a guess here that you use MacOS, have left your Scrollbar settings on default, and are using a trackpad.
Under those circumstances, MacOS hides scroll bars, which is a bit of a pet peeve of mine. It’s possible to force the issue using CSS, I think, but from my vague memory of the same issue int he docs, there are other downsides to this. Not giving them a max-height, might be the better idea.
A lack of a max-height might make reading some threads a bit cumbersome. We also wouldn’t be able to unset max-width because of the UI elements it would either collide with or push off the screen.
Limiting width is not an issue for readability as far as I’m concerned; it’s usually very obvious when something gets cut mid-line. It’s not always so obvious that there are more lines though, so limiting height is annoying.
1 Like
Fair point, made the change, let me know what you think.
Thanks!
1 Like
These were great ideas, I just went through the entire thread, well done Team.
I wanted to ask about line-wrap, I’ve noticed that in the preview pane while composing a post, a line will soft-wrap at the end of the viewing UI, yet when you [Reply], it publishes with a horrendous (In my mind) left justified wrap. Which will often give you a wrap of 3 complete lines, then a single word on the 4th line, which is uncool styling IMHO.
Is it possible to text-align: justify on the non-code text?
Thanks for the suggestion. I’m partial to left-justifying text and it’s the most common layout I encounter but if there’s strong support for fully justifying it then we can definitely consider it.
1 Like
Justified text is better for readability when you have a good word-splitting algorithm. It can be a bit clunky when you don’t, yielding distracting spacing patterns in some texts. It’s worth a try, but generally speaking browsers don’t do a very good job of it unfortunately.
2 Likes
I’m gonna try it out on my experimental theme and report back after a week
I see what you mean. Right now it’s just adding some longer spaces without filling up the last line.
Is definitely a balance, since the non-code UI elements seem to be far narrow than the left, viewable UI panel
| ----------------------------------------------------- | ← UI panel
| --------------------------------------| ← non-code elements
| ----------------------------------------------------- | ← Code elements
… as Gary said, with the browsers not supporting this correctly, maybe you are never going to get a good solution.
As a tip, when hacking around CSS elements that position by absolute, overlay or auto, I assign all the relevant elements, a different background colour.
Makes it so much faster to “see” the differences.
1 Like
On a post I just made today, the line-wrap is horrendous:
The UI Element for the code extends far past the UI Element for non-code text. I’ll wait to see what @anthony can magically fix.
1 Like
Anecdotally, adding these to the CSS seems to make things marginally better:
.regular.contents div.cooked p {
text-align:justify;
max-width: 100%;
}
.regular.contents div.cooked ul {
text-align: justify
}
.regular.contents div.cooked pre {
font-size: 95%;
}
2 Likes
Hard to know what it may or may not break elsewhere, though.
A CSS rule walks into a bar. In another bar, a stool falls over.
2 Likes
/me rofl 
1 Like
This is what I’m afraid of. May adapt a bit, iffy about scaling font sizes.
