Note that this is not a duplicate of this question.
I reviewed it before asking the question and the accepted answer is stated as unacceptable in the "Solutions that won't work" section below.
My blog is responsive so the same page is served up no matter what device or screen size is requesting it, and page styles change the look/feel based on the width of the viewport. Currently I get an undesirable horizontal scrollbar if there happens to be some code that is very long and doesn't break.
One of the code examples that causes this issue (see the page):
element.onContextMenu.listen((MouseEvent e) => e.preventDefault());
The line will not break until after the
MouseEvent. This is what it looks like on a Galaxy Nexus:
Note that the code cuts through the padding of the page before going off the page, this isn't desireable
I'd be very interested to hear what people think the best way(s) to approach this problem would be. Here are some ideas that I've come up with:
word-wrap: break-wordto break words like this that are too long to fit horizontally. The obvious problem with this is that it potentially messes with the meaning of the code by breaking half way through a keyword like in the below example.
Color the background of the code panels white so the text is readable but the horizontal scroll bar still exists.
One problem with this approach is due to the way that because of the way it's implemented, under certain circumstances it could be jagged which isn't very attractive. This can be demonstrated on this example by making the screen width even smaller.
Wrap the code as in option 1 but present an option to see the unaltered code. This could be extended to use the
white-space: nowrapCSS property so you could see code without any breaks at all, this would even be useful on the "full" desktop version of the blog.
My problem with this method is that I can't think of a way that could communicate effectively to both users using both mouse and touch inputs (ie. no tooltips), in the cleanest manner possible
Solutions that won't work
Note that a lot of solutions to these problems may not be possible without the use of client side scripting. This is highly undesirable as the script would have to be run attached to the resize event which I'd rather not do. I'd also prefer to have absolutely all presentation related implementation in the CSS where it belongs.
Crafting the code in such a way that this will never happen. Attractive and meaningful code may require a lengthy chunk of code. This would also be a burden when writing the code for my blog.
A newline marker or auto-indenting like on some text editors with word wrap turned on. This likely can't happen due to limitations with doing it in pure CSS.