New post formatting

status-bydesign

The amount of whitespace between lines of text (line-height) has changed. I don't know if this is intentional, but I liked the old one better. Was there a good reason for changing it, or can we have it back? I for one liked the old one better, because the new one makes letters 'dance' a bit more for me, it just doesn't read as nicely.

Old:

New:

Related:

• Please revert the line-height change!
• Request for a possibility to adjust the spacing between lines for those with poor eyesight
• Userscript to get the old line height back
• Was there an update with a change of the line spacing?

OK, here are two suggestions.

First, please go back to the original line spacing. I find this one hard to read.

Second, please send out a message to everyone about this instead of relying on the Meta sidebar to announce it. I actually thought my browser had screwed up or I changed an option somewhere. I tried different browsers, rebooted my machine, etc. and then decided to search Stack Overflow. All because I could not imagine that something like this would occur without a major announcement. Doing this will prevent others from wasting their time troubleshooting.

bug status-completed

Links in spoilers are only clickable with middle-click

Example:

This link is not clickable with left-click, but only with middle-click — it opens in a new tab then and there’s no way to click it directly.

On mobile, in order to open the link, you have to tap and hold until the link menu appears where you can choose the “Open link in new tab” option.

Also, hovering over the link always reveals the link URL in the status bar, but that’s a minor issue.

I think the best solution would be to not propagate clicks onto the spoiler if some interactive element is being clicked, but only if the spoiler is already revealed. If the spoiler is not revealed yet, a left-click anywhere inside the spoiler should first reveal the spoiler.¹ I don’t want to navigate away by clicking an invisible link.

I’ve also tested GitHub oneboxes (10k link) which exhibit the same problem. This would incidentally also fix stack snippets in spoilers.

Sure, the latter two are edge cases, and regular links are the more common case, but that would kill three birds with one stone.

¹User 41686d6564 pointed out that middle-click and right-click should not reveal the spoiler. While this comment arose from ambiguous phrasing, I myself am actually not sure how to handle middle-clicks or right-clicks on hidden spoilers. Ignoring them (i.e. not revealing the spoiler, but still allowing default browser features, e.g. context menu) is probably a good option.

bug status-completed

Trying to drag and select spoiler text results in it being rehidden

Seems like unintended behavior.

bug

The background of code blocks (<pre>s) is lighter now, making it harder to distinguish from the white background at a glance (everywhere but on Stack Overflow's dark mode).

Previously, with background-color: var(--black-050);, or #EFF0F1 on white:

Now, with background-color: var(--highlight-bg);, or #F6F6F6 on white:

With the earlier version, it was absolutely clear at a glance where the borders of the code block are. Now, I have better eyes than most, but even to me on my monitor, the borders look uncomfortably indistinct.

Another example code block

(Using the background color of inline <code> would be fine too IMO.)

I noticed the text color itself on blockquotes is now too light. It is hard to read for me, and I have decent eyesight.

The current style is .s-prose blockquote {color:var(--black-600)}. Deleting it altogether darkens blockquote text and makes it readable again.

This text is too light. Please darken it.

bug status-bydesign The scroll buttons are invisible in scrollable code windows

Not sure if this affects vertical scroll bar as well, but horizontally scrollable code windows don't show the actual scroll buttons anymore. They are still there and clickable, just... no caret or anything to indicate it is a directional scroll button.

(these scroll windows are scrolled left as far as possible):

and light mode:

bug

The background of inline code is different from the background of code blocks.

This makes them look like "different things" when in fact they are all just code, and should be formatted the same way.

Live examples (On SO dark mode the difference is much more significant):

Inline code: this is inline code

A code block:

this is a code block

status-completed

Is there a public place/page/site where this is enabled already, where I can test it (for my own curiosity or potentially to report an issue), before it goes live everywhere?

You wrote, "If you see something funky, let us know." -- where can I look?

I'd like to know what this looks like:

• List item

  List para

• List item

  List para

  • Subitem
  • Subitem

  List para

You mentioned "General refinements to spacing including nested lists" so I'm curious to know whether you fixed this -- i.e. that IMO there ought to be vertical whitespace between the last subitem and the next list paragraph.

There's currently something funky about the first list paragraph too: 15px margin after the first list item before the list paragraph, and only 7.5px margin after the list paragraph before the second list item.

The examples on your https://stackoverflow.design/product/components/prose/ suggests you fixed the second of these -- the margin is now 7.5px everywhere -- but I don't see a test/example of the first scenario above.

bug status-completed

When asking a question with a spoiler in it, I can click on the new 'Reveal spoiler' badge as often as I want, but it does not reveal anything.

It does work when you're writing an answer:

bug status-review

Links with inline code formatting look weird.

Screenshot using Firefox 68.11.0esr (64-bit) in Debian:

When hovering, the slightly lighter blue isn't noticeable compared to a normal link.

At least the blue link underline is below the regular underscore.

Screenshot using Firefox 73.0.1 (64-Bit) in Windows 10:

Actual example: __index__

bug status-completed

Italics don't render on mobile web. No apparent issues with bold Markdown. Android 5.1.1, Chrome 84.0. Screenshot of this Formatting Sandbox answer:

*This should be rendered as italics (asterisks).*  
_That, as well (underscores)._  
**This is bold text.**  
__Also bold text.__

It was working fine this morning, before the change went live.

bug status-completed

On mobile (specifically on the view accessed by clicking on the “full site” button, on an iPhone), at least on RPG.SE and Puzzling.SE, the body text in questions and answers has shrunk. Comments, titles, and headers don’t seem to have shrunk at all, in comparison.

I wear glasses for nearsightedness, and I use SE daily. On my phone I now must hold it within 6 inches of my eyes to be able to see it well. I used to be able to see best from about a foot away. This is something I find unhelpful as if I increase the page zoom, everything else grows too, which isn’t necessary.

Can you make the text bigger on mobile?

I want to draw readers' attention, particularly that of @AaronShekey, to the fact that the W3C does not actually recommend setting the line height to 1.5 or higher.

The relevant recommendations seem to be WCAG criteria 1.4.12 (Text Spacing) and 1.4.8 (Visual Presentation).

Criterion 1.4.12 regarding text spacing reads:

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• (etc.)

So this isn't a requirement, or a recommendation, for the line height setting - it's a requirement that if the lines are set to be more spaced-out, the site/webpage not become unusable or dysfunctional, and no content becomes invisible/inaccessible.

The W3C document entitled "Understanding Success Criterion 1.4.12: Text Spacing" reiterates this (emphasis mine):

The intent of this Success Criterion (SC) is to ensure that people can override author specified text spacing to improve their reading experience.

The recommendation is to support overriding of settings to cater to the needs of some readers - not to change the default settings.

WCAG criterion 1.4.8 regarding Visual presentation reads (emphasis mine):

For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)

... snip ...

Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

So, not the default, but achieveability through some mechanism.

@MaxD linked to a "techniques" document regarding criterion 1.4.8 which mentions the importance of providing line spacing between 1.5 and 2, but:

• That document is not the official WCAG.
• "Providing" doesn't mean "having that be the default". The actual WCAG clarifies that the intent is providing the mechanism for making that setting. For example, a site-level per-user setting to that effect.
• Criterion 1.4.8 regards AAA-level conformance. That level is not intended (according to the WCAG document itself) for general use, but for more accessibility-specialized sites.

_{Due disclosure: I have posted this as a reply on this related discussion as well.}

Let us re-hide spoilers

feature-request

This seems to have slipped in with a workaround to block re-hiding so links can be clicked and text dragged, see this comment on the matter.

This has been fixed. No more ghost clicks of underlying links. Spoilers reveal on any left click anywhere within the spoiler. Clicking again does not re-hide the spoiler (but rather lets its contents handle their own clicks) – Ben Kelly♦

Given that this is introduced to help minimise accidental revealing of text we should let users also hide the text again. Accidental clicks are still going to happen and even if they're not we should still give users the chance to re-hide content that they don't want to see.

We now reveal this on click / tap for a more consistent experience across devices—fewer accidental reveals as well, since it’s no longer a :hover interaction. Clicking again does not hide the spoiler.

It seems this functionality was removed for a workaround to fix the issue rather than anything else. It should be possible to be able to click links/select text though and re-hide a spoiler. Most places give both options and if I remember correctly the old spoiler formatting used to give that option as well. This seems like a step in the wrong direction.

Let's do what we do best as programmers ;)

⭐Revert Stack Exchange Formatting⭐

• Google Chrome Extension (customizable)
• Greasemonkey / Tampermonkey script | (only line-height)
• Stylish theme (+ Stylus) --| [Dark mode]

PLEASE UPDATE SCRIPTS!: updated to fix new changes to code blocks (Sep 24, 2020)

Mobile:

• Limited solution: per-page click-activated Javascript (iOS, Android)
• Kiwi Browser (Android) -- install the Chrome extension above (not tested)

Contribute:

GitHub repository -- help me revert it faithfully!

status-completed

The Help Center article Markdown Editing Help needs some love:

Spoilers

To hide a certain piece of text and have it only be visible when a user moves the mouse over it, use the blockquote syntax with an additional exclamation point:

At the end of episode five, it turns out that
>! he's actually his father.

The part I bolded should be updated to reflect the new situation.

feature-request

Additional blockquote refinements.

This refinement sounds like de-emphasizing the quote!

Instead of de-emphasizing the blockquote, I suggest to differentiate blockquote with normal text by using proper background. I would like to inform about the consensus of users for blockquote formatting by citing:

(124 net upvotes) Please revert the quote background from white to yellow

The present blockquote formatting needs a fix as soon as possible. I hope this would be considered.

Considering the comments against it - I actually find the new spacing easier to read.

I'm dyslexic - and one of the 'adaptations' I make (and it's not a positive one) is I block read. Since I'm taking less things at once, and slowing down, it's less straining on me.

I didn't really realise this was an option or if it would even help, but it seems to have, and pretty dramatically.

As someone who is described as "a minor fraction as your overall audience", thank you for fixing something I never realised was broken, and seems to be a great quality of life change for me.

I do see the arguments for having less space between lines of code (Monica has a few here, though in her case I understand her mentioning on Twitter rather than here, and I hope she forgives me for reproducing it here).

Larger, fixed line spacing (w/o regard to font face), almost double-spaced, so it's harder to track when reading a paragraph & harder to see para breaks. For code blocks, now less fits on the screen; code isn't read only sequentially like prose. Can't zoom out b/c size unchanged.

I'm personally not seeing an issue telling my paragraphs apart, and I use a lot of them in breaking up my walls of text, but others might. I'm afraid I'll have to leave it to them to post an answer explaining how it doesn't work.

bug status-completed

The new spoiler display isn't working correctly on tag wikis, e.g. the one about spoilers. The 'Reveal spoiler' badge is shown:

but the content is already visible upon hovering over it (which is the old behaviour).

I fail to see why a refactoring of the post styling code is applied along with significant changes to that formatting. In my experience it is common wisdom that you refactor your infrastructure first without changing user-facing behavior (as much as this is possible of course), then make behavior changes while resting stably on the new infrastructure.

I am also disappointed to see that the unfortunate spacing-out of lines went live, given that:

• There has been massive negative feedback from users.
• There has not been much/any positive feedback.
• The argument for increasing the line spacing, even when taken at face value, regards a small minority of people in general (some people with certain disabilities), and likely an even smaller minority of the site's user base; for which it would make more sense to introduce an option.
• There have not been any complaints from users about the line spacing being too small, nor any user group studies which have reached this conclusion; at least, not that we know of.
• There has been no assessment if the supposed difficulty for some users tracking lines at a spacing of 1.3 does actually manifest.
• There has been no assessment of the opposite effect: The difficulty of tracking lines when they are spaced too far apart. Also, of clearly observing the distinction between paragraphs.
• No consideration was made of monospaced textual-art before the change went live across the network.
• (edited: See my separate answer regarding what the W3C does and does not actually recommend.)

The response of "splitting the difference", and still going ahead, while better than ignoring the complaint, is not the appropriate course of action. Once it is recognized that there's a problem - the intended change should be delayed and further looked into, rather than hastily "resolved".

status-review

Another user claims that the text has shrunk, while I find the change within acceptable limits on Firefox Android; but on Chrome Android the text is too large compared to how it was previously:

As you can see with Chrome, the difference between the size of the post's fonts and (for example) the right column "Linked" list fonts is significant. The view on Chrome used to look similar to the view on Firefox (which is also now different, but not terrible).

With Chrome's post's new larger font size very little text fits on each line, basically 50% as much information is being presented in the same amount of screen area.

I understand that I can adjust the size of the fonts in my browser, but I don't want some to be too tiny or have to readjust to visit other websites - everything was OK before the changes.

[Note: I upvoted the announcement when I viewed it on Firefox, thanks for the improvement, but now seeing it on Chrome (and all the other complaints) I feel it unworthy of my previous support.]

I found a way to show which CSS is being used for various elements, the Android Kiwi Browser (77.0.3865.92) is Chrome based and allows extensions - here is what the "CSS Peeper" extension says about the webpages: Comment font size seems large, H2 is font-size 34.3 and H3 is 33.3 (almost the same), question hyperlinks look normal at 13 px, while regular text is 29.8 px and assigned to P.

Samsung S9+ with Firefox Android 80.0.1-beta.2 (Build #2015758611) and Chrome 85.0.4183.81

By adding support for more heading sizes, h1 looks too big now and breaks some older posts:

_{Post: https://stackoverflow.com/a/38025376/3705191}

The old h1 size (or # in MD) was closer to the current h2 font size, and the author of the post screenshotted above likely intended it as an h2 heading due to its size. The increase in size changes the intended meaning, and thus the intended formatting of the author. What looked like a coherent sub-heading before, now looks like a separate article heading.

I'd like old answers to be preserved as much as possible with their original intended formatting.

bug

Single-line lists (without <p>) have a large amount of spacing:

• Hello
• World
• Test

Markdown:

- Hello
- World
- Test

This looks exactly the same as lists with paragraphs:

• Hello

• World

• Test

Markdown:

- Hello

- Hello

- World

Lists without blank lines between the items shouldn't get rendered as a paragraph (and they don't, no <p> tag), and it probably shouldn't look like a paragraph either. This has been a feature since the original Markdown, and is also in CommonMark.

One place where this looks really funky is on my profile.

This is set by the below CSS, and removing that makes it look okay:

.s-prose ol li, .s-prose ul li {
    margin-bottom: .7em;
}

support

Revealing spoilers requires third-party JavaScript

... which new users and the paranoid (should) have blocked by default; a bad experience results.

bug status-completed

There's no way to reveal the spoiler on a user profile.

Also, when I hover the mouse on the spoiler's Markdown content while editing the profile, the "Reveal Spoiler" option disappears.

This is what I have while editing the profile:

And this is when I hover the mouse on the Markdown content:

Given that the design system documentation explicitly mentions small text, is there a chance of finally getting the <small> tag as allowed HTML in Markdown posts? The case for <small> has been made many times and, most saliently, people liberally abuse <sup>/<sub>_/^both as a workaround, so all the arguments against introducing the tag already apply to the status quo (except worse).

Links around code don't show up on the mobile site

See the screenshot of an answer of mine (as it appears on both Firefox and Chrome on Android):

Note that I refer to "documentation I have linked" yet don't appear to have linked anything.

In reality I've actually inserted a link around the function name as follows:

... use [`PyArray_ZEROS`](http://example.com) ...

... use PyArray_ZEROS ...

This looks like regular code with no indication that it is clickable. (On desktop it has a blue underline so is marginally more obvious.)

feature-request

Firstly, the difference between 1.3 and 1.6 for the new line-height changes is actually 1.45, not 1.5. Second, I would like to have the line-heights added as options in preferences, which would be a real accessibility improvement.

"... with additional refinements to spacing between elements"

You may know already, I've read some designer recommend an inter-paragraph margin equal to the line-height -- so that there's exactly one empty line between paragraphs -- the "grid" of lines on the page is perfectly regular, and the inter-paragraph margin is perfectly obvious, arguably neither too big nor too small.

IMO having a half a line-height between (and within) list items, as you have now, is a very good idea too (to make a list more compact and cohesive).

I see you currently have ...

• 15px font-size
• 1.5 line-height

... and so the line-height is 22.5px.

And you currently have:

• 21px inter-paragraph margin
• 10.5px margin within lists

Note that 21px is very close to 22.5px -- which is why it looks just about right, IMO -- not exactly.

IMO a 21px margin would be perfectly suited to a 1.4 line-height (15px * 1.4 = 21px).

So, if you want or must have a line-height of 1.5, I suggest you might therefore experiment with an inter-paragraph margin of 22.5px instead of 21px -- see how that looks, whether it works in practice as well as in theory -- and 11.25px within list items.

Also just FYI, an additional refinement that I've liked elsewhere:

• Zero internal margins (i.e. only the line-heights) separating list items, if it's only a "simple" list (i.e. when all the list items contain nothing but text, no sub-lists or paragraphs) -- that makes these lists more compact and cohesive.

  I don't know whether you can implement that though, given the HTML that you have to work.

  I think I remember Discourse doing this -- the inter-list-item margin becomes spacious if you edit the markdown to make any item complex.

• A simple list this, with no internal vertical margins, might do with a half a line of margin between itself and the preceding paragraph which introduces it (so it sticks to or flows from the previous paragraph).

  I think that to implement this your CSS might need to be defining margin-top for everything instead of margin-bottom.