Code blocks should show 80 characters without wrapping

Can't we just add overflow-x: scroll to .codeblock and white-space: nowrap; to code itself? I saw that solution on a number of sites and I think it's very handy. In most cases we will still get code block without scrollbar as we follow 80 characters per line rule.

Maybe a good candidate for the Novice tag?

Can't we just add …

Sure, with testing.

Would be great.

I attached patch which can be used as an entry point.

Thanks, I went ahead and applied this to the lax1-drupal.redesign.devdrupal.org dev site.

Now I see it doesn't look perfect on webkit browsers. List item marker is invisible if first child is block with overflow: hidden/scroll value. That is webkit bug but we need cross-browser workaround.

Check https://lax1-drupal.redesign.devdrupal.org/node/2472323#comment-9898921

Since Code Filter on d.o has been updated to version 1.2, with support for prismjs, >80 characters is no longer an issue. Unfortunately something I've mentioned in #11 would now become a problem for all codeblocks in bullet or numbered lists (ex. #2472323: Move modal / dialog to query parameters)

Codefilter has an optional feature which allows expansion on hover (at present via some Javascript, though I guess it could be probably be refactored to CSS). It's an option in the filter settings. Could be worth a try?

@cam8001 that expand js feature would need some touch up for mobile because it truncates due to the lack of hover. That's currently why we turned it off.

What about something like this? I just tested it on my Mac Chrome 49.0.2623 and my IOS 9 Safari and it seems to work well on both:

https://codepen.io/cam8001/pen/PNjQpJ

That's a pretty creative trick.

Try scrolling a few times right off the bat on iOS phone, it gets a bit finicky and likes to jump back to start. At least on my phone anyway, iPhone 5s:(

Does work for the most part though.

May need touch detection though I believe, no?

Yes, a pure-CSS solution would be great. We can probably even animate it now if we want. And there's CSS media queries if necessary.

Good next steps would be:

• Simplifying Drupal.org’s Prism theme to remove the regressions.
• Merge the more-structural styles with http://cgit.drupalcode.org/bluecheese/tree/sass/partials/common/_basic-e..., so we have the relevant styles in one place.
• Try out and test expanding when possible, otherwise scrolling.

Forgot to paste the link to Drupal.org's Prism theme: https://bitbucket.org/drupalorg-infrastructure/drupal.org-sites-common/s...

Bumping this to major since the loss of the numbers is not good.

Long lines should wrap. Requiring scrolling to read the code is so much worse than any visual awkwardness caused by wrapping. For the prism.js highlighter, that can be fixed like so:

.codeblock code {
  white-space: pre-wrap !important;
}

!important included for use in user stylesheets, but obviously not a requirement if this is set in the actual prism theme stylesheet.

n.b. It looks to me as if this issue was originally about making sure that at least 80 columns are visible (where possible) -- so that wrapping doesn't occur earlier than that. I think that's a perfectly sensible goal, but one which requires nothing more than having sufficient horizontal space in the layout for a minimum of 80 monospace characters.

So this is an old issue that was started before we got the new prism syntax highlighter. It suddenly got a lot worse because with the prism highlighter the wrapping has been replaced with scrolling.

I also strongly believe the code SHOULD WRAP and SHOULD NOT SCROLL. The comment in #5 is totally invalid. If you want to post tabular data then you should use <table> instead of <code>.

80 characters is also not enough width, code can be much wider than that, but at least comments wouldn't wrap. If you want to get serious about displaying code on drupal.org then we need 120 characters.

I opened an issue for the 25,000 pixels wide expand: #2696085: Expand on hover is making codeblocks almost 25,000 pixels wide

@zaporylie re #12 That screenshot looks to be chrome specific, do you happen to know what is causing that output? FF seems fine to render that as expected.

I believe this is WebKit bug. See #11.

That's the reason (or at least one of the reasons) why this issue is still open.

We (the DA) will be reverting from scroll bars/hover to line wrap for now, after the feedback in this issue and the related issue: #2629046: Add syntax highlighting to Drupal.org

This is something we want to come back to, however.

Drupal.org is now back to last week’s code wrapping behavior.

So I don't think this should actually be part of the scope of this issue, but per #2629046-104: Add syntax highlighting to Drupal.org, reposting over here:

Ummm so this is still a huge usability and accessibility problem regardless of line wrapping. Currently the blocks expand to 24,600 (!) pixels wide on mouseover, regardless of line length, and does not re-collapse on mouseout. It permanently covers up any metadata in the issue sidebar until you reload the page, and if you don't carefully avoid moving your cursor over the blocks, you can basically not use the sidebar metadata for the issue.

Either #2629046: Add syntax highlighting to Drupal.org should be reverted, or the priority of one of these issues should be much higher, or there should be a separate at-least-major issue for the regression. These are not normal bugs; they represent a significant usability and accessibility regression for a minor feature.

Hopefully a pure-CSS version of this can avoid the browser bugs. Regardless, future work here should be tested in major browsers before getting close to deployment.

Looks like @Cameron Tod filed #2696085: Expand on hover is making codeblocks almost 25,000 pixels wide for that. Adding it to the related issues.

Unless codefilter ends up changing the various issues with the hover, I don't see drupal.org adopting it. Removing that related bug for now.

The block code line-wrap has been deployed. setting this issue back to active as this issue needs to be re-examined from the ground up.

Drupal.org is now back to last week’s code wrapping behavior.

Great news, thanks!!!

I have committed a fix for the hover width issue in codefilter. Next task is to refactor the hover expand to be CSS only.

This also affects documentation, see https://www.drupal.org/docs/develop/coding-standards/api-documentation-a...

The font size in the new design has increased, but the width of the page hasn't. Not only the code blocks are too narrow now, but the normal text paragraphs too. There is simply not enough space on a single line to fit enough characters. It is made even worse because the right sidebar eats up 1/3 of the available space. This looks OK on mobile, but not on desktop:

On longer pages it just looks like a narrow newspaper column that is lost on a sea of empty space. I think we need to increase the page width with like 30-50%, and also do not reserve the horizontal space of the sidebar all the way to the bottom of the page, it would be better if the text would flow around it to fill the full width of the container.

@pfrenssen though I generally agree that the width is a bit too narrow and having the text flow around the sidebar is an interesting area to experiment with. Though a word of caution, be careful not to over-steer this because a readable line-length should be considered as well. Whitespace isn't necessary wasted space and hope this doesn't go full width.

And for code blocks we need to make them have a decent fallback for mobile and smaller devices.

I'm not suggesting to use the full width, but to increase the width by 30-50%. Full width is madness on large screen. But it's way too narrow now, and the code blocks are practically unreadable now that they wrap again.

I think even increasing by only 5-10% would fix the wrapping, it looks like it's just short of 80 characters.

But to me the running text is also too narrow to read comfortably.

Probably we could just change grid base from 960px to 1200px?

With #2532114: Reduce font size of 'code' tag and the last commit, both the new styles in documentation and issue comments do not wrap at 80 characters.

Great! Thanks for following up on this!