2

AskUbuntu help recommend to style pre-formatted text and console output with

#four spaces

But sometimes it results in scrolling text. See this question as an example. The problematic line (as formatted by David Foerster) with console output:

'Ubuntu 18.04 LTS _Bionic Beaver_ - Release amd64 (20180426)' in the drive '/media/cdrom/' and press [Enter]

On my non-customized browsers - tested Chromium 66.0.3359.181, Firefox ESR 52.9, SeaMonkey 2.49.3, Chrome 67.0.3396.99 this text is scrollable:

Preformatted text is scrollable

I found that scrolling gets enabled after I enter the 82nd symbol.

Possible workaround is to use backticks:

'Ubuntu 18.04 LTS _Bionic Beaver_ - Release amd64 (20180426)' in the drive '/media/cdrom/' and press [Enter]

but some users do not like this method.

Other solution from David Foerster is to use custom user-side CSS:

custom CSS for code-formattin

(the result looks similar as in narrow terminal with width of ≅80 characters )

Note: terminal does not have horizontal scrolling, only vertical.

Should we avoid scrolling? Do you plan to customize this server-side?

Below in comments @PerlDuck wrote:

I'd like it best if there was something like the <!-- language: lang-js --> thingy, e.g. <!-- render: no-scroll --> or whatever so the author can decide. Sometimes scrolling is OK, sometimes it isn't.

So it would be great if user can choose the needed formatting.

9
  • 11
    Why shouldn’t it be scrollable? It’s code, and a newline can make a difference – code blocks should definitely not break lines automatically IMO!
    – dessert
    Commented Jul 15, 2018 at 12:35
  • I think we need to invite @DavidFoerster here for the discussion. This problem started with styling of console output - I preferred backticks to get non-scrollable output, but David likes four-spaces and got non-scrollable variant by custom user-side CSS.
    – N0rbert
    Commented Jul 15, 2018 at 12:51
  • 2
    I'd like it best if there was something like the <!-- language: lang-js --> thingy, e.g. <!-- render: no-scroll --> or whatever so the author can decide. Sometimes scrolling is OK, sometimes it isn't.
    – PerlDuck
    Commented Jul 15, 2018 at 13:07
  • @PerlDuck Please write a feature request here on meta and tag it accordingly!
    – dessert
    Commented Jul 15, 2018 at 13:59
  • 5
    FYI you can't ping someone who hasn't commented on or edited a post and isn't its owner, so David won't see that until he happens to read meta. FWIW, I also (strongly) prefer code blocks for code on its own line, even if it triggers scrolling, but I introduce line breaks into command output to avoid scrolling where possible
    – Zanna Mod
    Commented Jul 15, 2018 at 16:11
  • 1
    I have no strong opinion either way. Ideally there would be a simple and intuitive way to enable or disable line breaks in long lines inside pre-formatted listings as needed but imho the majority of people doesn't think or care enough about this issue to warrant such a solution. I can tell you that web browsers will not insert line break characters at “soft” line breaks when one copies and pastes code listings with the white-space: pre-wrap CSS declaration (which my browser injects as user style for all <pre> elements).
    – David Foerster
    Commented Jul 18, 2018 at 21:02
  • 4
    This may seem a bit off-topic at first: I've developed an app for Android that requires running a few ADB commands to get working. I have them listed in the app to just fit the width of the display instead of scrolling sideways, and I can tell you it does not work well. People miss spaces, think each is 2 commands, etc. Granted, when I had it the other way, people didn't know it scrolled, but that wasn't as much of a problem.
    – TheWanderer
    Commented Jul 18, 2018 at 21:06
  • 1
    I think quote formatting (>) should be considered for the “code” containing a single error message only. Moreover, the error message in the linked question seems to be incomplete.
    – Melebius
    Commented Jul 19, 2018 at 10:10
  • 3
    If the output appears in a terminal, no matter how short it is, I feel it needs code formatting, not blockquote, because once you format short errors that way, you make people think it's OK to format any errors that way and it makes anything longer than one line really hard to read. The error should look as similar to the way it does when encountered as possible, so that people can recognise it
    – Zanna Mod
    Commented Jul 19, 2018 at 17:42

0

Reset to default

You must log in to answer this question.