Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the "town hall" (meta-discussion site) for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on Mobile style voting buttons to match post width to preview width and reduce horizontal scrolling

Post

Mobile style voting buttons to match post width to preview width and reduce horizontal scrolling

+0
−0

On mobile, where width is limited, the voting buttons are above a post rather than to the left. This adds very little additional vertical scrolling but saves a considerable amount of horizontal space being lost, particularly on long posts.

Question with title followed by voting buttons followed by body, arranged vertically on mobile

On desktop the horizontal space wasted by voting buttons to the left is not as important, as the screen is usually in landscape format with plenty of width to spare.

Question with title followed by voting buttons to the left of the body on desktop

However, I would still prefer the voting buttons to be above, to reclaim that full width for the post. My main reason for this is that the edit preview would then match the width of a post (on desktop - it already does on mobile).

If I add a code block to a post, I try to make sure that no horizontal scroll bars are required, splitting long lines if necessary to avoid this. Currently, I need to check what width to aim for in an existing post, because the preview of a post being drafted is a few characters wider. Even if I make code lines short enough to avoid horizontal scrollbars in the preview, they are still long enough to lead to horizontal scrollbars in the saved post.

The difference can be seen by viewing a post with horizontal scroll bars on a code block, such as Setting custom HTTP status code messages in nginx. Note where the paragraph wraps and where the first code line cuts off:

Paragraph in a post followed by a code block with 72 characters visible horizontally

Contrast this with the preview seen when editing that post:

Paragraph in edit preview followed by a code block with 76 characters visible horizontally

The paragraph wrapping one word later really doesn't matter, but the code block preview suggests an additional 4 characters will be visible without scrolling, when they will not.

Apart from preferring consistency between the preview and the post, I'd also appreciate having 76 characters of code width in a post rather than the current 72. This would reduce the number of posts that happen to have horizontal scroll bars in the code blocks, and would make it easier for people who want to adjust their code to avoid horizontal scroll bars.

History

2 comment threads

A separate request for 80 characters of code block width (1 comment)
> My main reason for this is that the edit preview would then match the width of a post (on desktop -... (3 comments)
> My main reason for this is that the edit preview would then match the width of a post (on desktop -...
Moshi‭ wrote 8 months ago

My main reason for this is that the edit preview would then match the width of a post (on desktop - it already does on mobile).

IMO this shouldn't really be a consideration - After all, different devices viewing the post after it is posted will be different widths, so there is no way to 'optimize' your post for the view width except for your own device.

Though there is incentive to move it at least to the bottom of the post for ease of voting

trichoplax‭ wrote 8 months ago

I understand that mobile devices will be much narrower, but I would expect most desktop or laptop screens to show the same standard width. Even if I zoom in there is no narrowing of the column of text until it reaches the edges of the screen. Zooming beyond that will require horizontal scrolling of code but I don't see a need to avoid it in the extreme case, just for the general case.

On a phone horizontal scrolling is just a swipe, not requiring finding a scrollbar (or switching control methods). On desktop horizontal scrolling requires using the mouse for most users, which is awkward for keyboard users and tedious even if already using the mouse.

trichoplax‭ wrote 8 months ago

For me, zooms between 50% and 150% have identical width (display the same amount of text horizontally) despite taking up very different amounts of the total screen width.