Update 3

It took me longer than I wanted, but I’ve got some updates for you on our s-prose component. You can see the pull request with my thinking over at our design system’s repo. It does the following:

  1. Spreads s-prose headers out from paragraphs for better grouping.
  2. Tightens up s-prose paragraphs a bit, and made sure spacing under headings are more consistent.
  3. Replaces all s-prose margins internal to the component with a CSS variable var(--s-prose-spacing) so our users can more easily tinker with it in their browsers and user scripts.
  4. Kills trailing margins in s-prose

You can see some examples of content at our Stacks documentation.

Update 2

I’ve split the difference between the original 1.3 line-height and the proposed 1.6 line-height. We’re now at 1.5, with additional refinements to spacing between elements. I’ve also reduced line height within code blocks back to near the original value.

Update 1

This is now live.

We’re doing a bit of refactoring on our post formatting. Currently, we apply a single class with both layout and styling called .post-text. Our first goal is to separate layout from our text styles. Simple enough!

However, our current post styling has a few missing spots and areas for improvements. Using our design system as a sandbox, we’ve beefed up our styling and created a new component called .s-prose. It’s designed to offer styling for everything the CommonMark spec allows. This should allow us to add Stack Overflow-flavored styling anywhere we need to consume Markdown—questions and answers, of course, but also things like user profiles.

Our .s-prose component adds:

  1. Proper formatting for definition lists

  2. Further header support and better spacing there

  3. Additional blockquote refinements.

  4. Refinements for revealing spoilers. 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. We also now add a badge to the top right corner. You can see how these work on our design system documentation. It looks something like this:

    This is a spoiler
    It has two lines

  5. General refinements to spacing including nested lists, images within lists

  6. Sizing variations for different contexts. We offer xs, sm, and md variations of the .s-prose component.

As with everything, our prose component is a work in progress. We think we’ve got a heck of a start to a reusable component. We plan on going live with the new component network wide on Thursday, August 27, 2020. We’ll edit this post if that changes.

If you see something funky, let us know. Some things are intended but might feel like regressions—images have a slightly different baseline—but others may have slipped through the cracks.

  • 23
    Question - what site(s) will this be tested on? – Aibobot Aug 25 '20 at 17:45
  • 21
    @Aibobot We can't toggle this changeset on and off per site, so it'll go live across the network once the PR is merged and deployed. We did do extensive internal testing, so fingers crossed y'all shouldn't see any actual bugs. – Adam Lear ModStaff Aug 25 '20 at 18:59
  • 8
    @SonictheMaskedWerehog Yep, that should be fixed by this new component. – Aaron Shekey ModStaff Aug 25 '20 at 20:41
  • 5
    @AdamLear Thanks! Also, user profiles seem to use an outdated version of SE CSS which doesn't contain many of the changes made to posts, e.g. links aren't underlined yet, and spoilers don't show permanently when clicked. Will those inconsistencies also be fixed by this update? – Sonic the Anonymous Hedgehog Aug 25 '20 at 21:10
  • 10
    Also, I don't see underlines on links in your design document. Is that being reverted? – Michael Aug 25 '20 at 21:11
  • 57
    Did the line-height of SO just change? – j08691 Aug 27 '20 at 14:46
  • 9
    I'm not deleting comments but if you have an ask or a bug, please put it as an answer, not a comment. Comments are not a great place to build an argument and make a point - you can't get specific feedback and the comments can only be upvoted, leaving an unbalanced view of the suggestion. For all of these reasons, please, write a thought-out explanatory answer. – Catija ModStaff Aug 27 '20 at 15:24
  • 65
    Can you turn this into a preference? I prefer what we had before – Paolo Aug 27 '20 at 15:27
  • 4
    I am not sure of the impact of this change, but IMNSHO the CORRECT spacing between numbered list items is 0. If I think items need extra space I would insert it myself. The current layout is difficult enough on a small screen without even MORE wasted space. – Milliways Aug 28 '20 at 11:47
  • 10
    The spacing looks excessive on my Android device. Lots of scrolling for nothing. – henning Aug 28 '20 at 12:00
  • 39
    "We’re doing a bit of refactoring on our post formatting." Please don't overload the term refactoring like this. You're making behavior changing refinements, which is great. Refactoring means making behavior preserving refinements to the source. Having the distinction in our jargon is useful, but we're going to lose it if we're not careful. Thanks! – Adrian McCarthy Aug 28 '20 at 13:42
  • 4
    @WeatherVane There were no changes to the bounty link in this update. – Adam Lear ModStaff Aug 28 '20 at 19:20
  • 22
    What evidence is there that such wider spacing is relevant in technical writing & in code with their high information density & slower comprehension, which is the situation in SO/SE? There is an enormous difference between such writing & normal prose. – philipxy Aug 30 '20 at 1:09
  • 7
    please keep the increased spacing, it makes it easier to read for people with less than perfect vision (eyesight). which is a very welcome change, an accessibility improvement. – Will Ness Aug 30 '20 at 22:27
  • 4
    The line-height change just hit SO -- and it is horrible. No more than 1.1 please, or make this an option to be set in the user-profile. The new line-height is quite hideous. – David C. Rankin Sep 1 '20 at 1:48

31 Answers 31


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.


image showing whitespace between lines before change


image showing whitespace between lines after change


  • 59
    Totally agree. Posted a feature request a couple minutes ago: meta.stackexchange.com/q/353525 – MaxD Aug 27 '20 at 15:13
  • 135
    This new line spacing is awful. It's so similar to paragraph spacing that it basically turns every post into an airy wall of text. – 8bittree Aug 27 '20 at 15:15
  • 40
    @Aaron This is horrible. It might work better with different fonts (Helvetica instead of Arial, perhaps), but it doesn't work with Arial or Georgia, and it's still a little too much with Palatino. If line-height really must be increased it certainly doesn't need to be as much as it has been. – Andrew Leach Aug 27 '20 at 15:17
  • 71
    @AaronShekey Please revert this change. It's detrimental to the site. Obviously you didn't solicit any, or enough, user feedback on this particular change. – j08691 Aug 27 '20 at 15:20
  • 52
    @Tinkeringbell "I understand people may be disliking this a lot, and I'm curious to hear if they have any good reasons" Because it makes everything harder to read?? – j08691 Aug 27 '20 at 15:23
  • 31
    At least explain yourself if you're just gonna leave it at that! Given that every other reasonable change that would need 5 seconds of developer time needs to go through months of A\B testing just to be able to say "ah, not gonna be worth it", you don't get to make this linewidth change with sole explanation that, I don't know, because you can, to "disrupt the status quo" of proper line spacing? – Christian Rau Aug 27 '20 at 15:25
  • 50
    Tinkeringbell (and @Aaron) It's simply a poor design decision. It makes things a lot harder to read because each line is not connected enough to the next. And it's probably necessary to tweak it for different base fonts. I stand by "horrible". – Andrew Leach Aug 27 '20 at 15:27
  • 40
    @Tinkeringbell Harder to distinguish paragraphs, unnecessary waste of space. And it just feels disproportional to the size and shape of the font. | Also, doesn't match the spacing in comments and in the right side bar (fortunately). – Dan Mašek Aug 27 '20 at 15:27
  • 36
    @Aaron So you're going to increase the spacing between paragraphs as well? Aargh. I maintain you haven't tested this enough with the fonts in use. – Andrew Leach Aug 27 '20 at 15:35
  • 32
    Find myself repeatedly asking new posters on Stack Overflow not to double-space every line of code, and now the whole site kind of looks that way. ;-( – Tim Williams Aug 27 '20 at 15:45
  • 53
    @AaronShekey There are just as many people (if not more) who find the current spacing harder to read. A profile setting is probably needed here. – Sebastian Simon Aug 27 '20 at 15:55
  • 42
    @AaronShekey well, I have trouble tracking lines of text when each line looks like it's a paragraph of its own. And looking at comments and upvotes here, I'm not alone in this. – Kreiri Aug 27 '20 at 16:08
  • 36
    This is remarkably detrimental to readability, both in information density and in flow. – chrylis -cautiouslyoptimistic- Aug 27 '20 at 16:13
  • 49
    @AaronShekey This new line spacing is much more difficult to read for me. I am finding it quite distracting and it's negatively impacting my ability to think about what I'm reading. I don't know what cognitive impairments you're trying to address, but I suspect you're inducing far more of them! – Michael Hampton Aug 27 '20 at 16:13
  • 45
    @AaronShekey Did you do any user testing before implementing this change? – Illya Moskvin Aug 27 '20 at 16:20

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 and not rely 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.

  • 11
    I don’t know… if you know enough about Stack Exchange to notice a change in line spacing, shouldn’t you already know of the community bulletin where this post is featured? – Sebastian Simon Aug 27 '20 at 15:32
  • 75
    I didn't know it was a feature. It seems more like a bug so I checked other options. – WJS Aug 27 '20 at 15:34
  • 15
    @WJS It is a bug. – user1271772 Aug 28 '20 at 22:46
  • 7
    it's funny how specific I had refine my google search in order to find this relevant post. Had I not realized it was the line-height that had changed, I probably would've never found this official statement. – Prid Aug 28 '20 at 23:49
  • 2
    Yeah, I found it too eventually. But I usually assume that something like this was because I did something wrong. So I did numerous searches on how to fix it. It is irresponsible to introduce a major change like this without alerting everyone via a simple message. If the system can't handle doing that, then it has other problems that need correcting. – WJS Aug 29 '20 at 15:34
  • 1
    I thought I was going crazy all day... Turns out they've changed it. – Dimitar Dimitrov Aug 29 '20 at 21:25
  • 1
    Um, a few years ago they used the notification system to notify users of a post here on this site, but it led to a huge flood of off-topic questions here from people who hadn't realized they'd been directed to a different site. They learned not to do that again. – Sonic the Anonymous Hedgehog Aug 30 '20 at 8:33
  • 1
    Count me as one who actually prefers the new line spacing -- to the point where I will frequently open up developer tools on my browser to increase line spacing on wall-of-text websites to improve readability for me. – Tristan Sep 2 '20 at 16:22
  • @Tristan so it should be configurable. – WJS Sep 2 '20 at 16:25
  • 1
    @WJS If everything that people wanted configurable were configurable, the site would be an unusable mess of configuration settings. Personally, I'm fine with either, but I find wider line spacing easier to read. – Tristan Sep 2 '20 at 17:11

Links in spoilers are only clickable with middle-click


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.1 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.

1User 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.

  • 5
    Looking into it now. Thanks for the report – Ben Kelly ModStaff Aug 27 '20 at 14:56
  • 14
    That's how you should be opening all links anyway :-) – TylerH Aug 27 '20 at 15:05
  • 3
    @BenKelly I see potential for another bug when fixing this. Make sure that hidden spoilers don’t trigger clicks on invisible links. See my edits… – Sebastian Simon Aug 27 '20 at 15:23
  • 2
    @user289905 Good observation. I'll do a sanity check on that as well. Might be worth adding as a bug report answer if you notice anything off with it now. – Ben Kelly ModStaff Aug 27 '20 at 15:32
  • 1
    Yes, great observation indeed. But I disagree with "any click should first reveal the spoiler". I don't think middle and right clicks should reveal the spoiler. – 41686d6564 Aug 27 '20 at 16:26
  • @41686d6564 Right, I don’t mean any mouse button, but a left click in any position. I’ll edit to clarify. – Sebastian Simon Aug 27 '20 at 16:27
  • I'm on mobile, FF Android, I touched the spoiler once and it was revealed in-place. – Rob Aug 27 '20 at 16:58
  • @Rob Seems like expected behavior. Not sure what you’re trying to say… Are you referring to “On mobile, you have to tap and hold until the link menu appears where you can choose the “Open link in new tab” option.”? That just applies to links, not spoilers themselves. – Sebastian Simon Aug 27 '20 at 17:06
  • @Rob Well, I’ve edited the statement. Is it still ambiguous? Of course a single tap reveals and hides the spoiler on mobile. – Sebastian Simon Aug 27 '20 at 17:19
  • 3
    Thanks for the discussion all. I have a fix for this going out in the next build (soon™). Will update the question with changes and tag this answer at that time. – Ben Kelly ModStaff Aug 27 '20 at 18:32
  • 7
    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 ModStaff Aug 27 '20 at 20:42

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

Spolier box is shown. Mouse clicks on the box to reveal text. Text is shown being selected by dragging across with a mouse cursor. Upon release of the mouse button the spoiler rehides itself.

Seems like unintended behavior.

  • 2
    Looking into it now. Thanks for the report – Ben Kelly ModStaff Aug 27 '20 at 14:50
  • 1
    @BenKelly Perhaps solved by preventing re-hiding once revealed, or adding an embedded element (perhaps a thick right edge) which can be clicked to re-hide – ti7 Aug 27 '20 at 15:24
  • 3
    I have a fix for this going out in the next build (soon™). Will update the question with changes and tag this answer at that time. – Ben Kelly ModStaff Aug 27 '20 at 18:33
  • 7
    This has been fixed. After being revealed, spoilers do not re-hide on future clicks. This makes things like selecting text and clicking links have a consistent experience. – Ben Kelly ModStaff Aug 27 '20 at 20:44

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:

enter image description here

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

enter image description here

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)

  • This must be an issue with how your monitor is set up. Consider tweaking the contrast and brightness buttons. On my screen the new gray looks just fine. – Cris Luengo Aug 27 '20 at 19:57
  • 14
    @CrisLuengo The inline and block style don't match. They should at least match, regardless of which shade is chosen. I prefer the darker, currently used on the inline. – frеdsbend Aug 27 '20 at 20:47
  • 3
    @CrisLuengo I've looked at it on three different monitors and the new background for code blocks makes it harder to read code on all three. My main monitor is pretty carefully tuned to display everything correctly so I don't think it's a matter of tweaking its settings. – Ted Lyngmo Aug 28 '20 at 7:41
  • Setting pre { background-color: var(--black-050) !important; in a user-styles addon fixed this for me, FYI. That is the Stacks variable value it was set to before. Screenshot of this post with that color restored: i.stack.imgur.com/OQcqJ.png – TylerH Aug 28 '20 at 14:13
  • Use my Chrome extension to revert the bg-colors (and line-height): chrome.google.com/webstore/detail/revert-stackexchange-form/… – Prid Aug 28 '20 at 23:51

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.

  • 3
    It seems like an attempt to differentiate block quotes from normal text, which in my opinion is a good thing. Maybe this way is not the way to go, but some differentiation should be there. – Matt Samuel Aug 27 '20 at 21:32
  • 8
    @MattSamuel Is the line to the left of the block not enough? A lot of sites change the bg color. SE used to have a different bg color on blockquotes. – frеdsbend Aug 27 '20 at 22:34
  • 4
    @fredsbend I don't think so. You should be able to glance at the text and realize it's a quote. A background color like they had before would be preferable. – Matt Samuel Aug 27 '20 at 22:36
  • 9
    The contrast ratio is exactly 7:1, which makes it compliant with the WCAG AAA accessibility standard, but it's the bare minimum for that. I'd make it darker, though. – Sonic the Anonymous Hedgehog Aug 28 '20 at 1:37
  • 7
    Yes, this looks like de-emphasizing the quote! :( especially when people vote for something else – Pandya Aug 28 '20 at 6:24
  • 4
    I saw this on another SE site before coming to meta; it’s really noticeable, and quite ugly. Please change it back. – Fivesideddice Aug 28 '20 at 22:38
  • 3

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):

dark mode scrollable code window problem

and light mode:

light mode scrollable code window problem

  • 2
    This change isn't a part of this component. We've normalized scrollbars across our platforms. You can see how scrollbars are affected by our styling in our overflow classes stackoverflow.design/product/base/overflow – Aaron Shekey ModStaff Aug 27 '20 at 15:06
  • 57
    With all due respect, it's a horrible design decision to hide a clickable button that is still clickable. One of the prime directives of UX/UI design is "don't mess with scrolling". – TylerH Aug 27 '20 at 15:07
  • 9
    Ew. Gross......... – Boann Aug 27 '20 at 15:10
  • @AaronShekey I'm pretty sure this was not implemented until today; others in chat agree it wasn't like this before... so I guess you guys implemented multiple sets of changes today. Should I post this as a separate question? – TylerH Aug 27 '20 at 15:23
  • 8
    @TylerH These scrollbars have been around for months. ¯_(ツ)_/¯ – Aaron Shekey ModStaff Aug 27 '20 at 15:24
  • 11
    @AaronShekey Then I guess it has just been highlighted massively by today's change. Either way, the buttons ought to be made visible again like they were before; just checked, and February 10th is the last time the buttons had the right appearance. – TylerH Aug 27 '20 at 16:08
  • 6
    @TylerH It's also possible that you're running a userscript or custom CSS which disabled the change, where that userscript relied on the now defunct post-text class, or where the selector used in the override no longer has an equal or greater specificity. For example, I'd added the CSS pre { scrollbar-color: unset; } to my personal adjustments when the change was originally made. Now, it needs to be .s-prose pre:not(.s-code-block), pre { scrollbar-color: unset; }, which gives it equal specificity as the new SE rule. – Makyen Aug 27 '20 at 21:34
  • @Makyen I just nuke it with !important to avoid nasty surprises later. – TylerH Aug 27 '20 at 21:42
  • 5
    While that's certainly an option, I'm usually reluctant to use !important when not needed. However, my reluctance is probably something I should set aside for Stack Exchange, where the use of !important can be in upwards of 8 out of 9 rules. – Makyen Aug 27 '20 at 21:57
  • Am I being a numpty, because I'm trying it out and I don't see any buttons. And the scroll bar is different. – Peilonrayz Aug 28 '20 at 1:11
  • 2
    @Peilonrayz The site is apparently abusing non-standard properties to ruin things for Firefox; in Chrome, they use other prefixed properties for the scrollbar to make it horrible akin to macOS scrollbars – TylerH Aug 28 '20 at 13:40
  • 2
    @TylerH My picture is from Chromium, so it's worse than just breaking for Firefox. – Peilonrayz Aug 28 '20 at 13:52
  • 2
    I completely agree with this, and have posted a feature-reqeuest for it's reversal.. – Ollie Sep 20 '20 at 15:18
  • Ugh, typing with cold fingers. I meant request ;) – Ollie Sep 20 '20 at 21:26
  • 1
    @Ollie Yes, I use an add-on called Stylus in Firefox for this. Setting it to apply to "URLs on the domain" of stackoverflow.com and stackexchange.com will get meta sites for those two domains (and any meta sites for main sites which don't have custom URLs). So, for example, those two URL applications won't catch meta.superuser.com, but will catch meta.scifi.stackexchange.com. – TylerH Sep 23 '20 at 22:55

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

enter image description here

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
  • This has actually been very nice when reading posts that have put type names, variables and function names/signatures in code blocks. It's however not so nice with statements and expressions. It's worth mentioning I use the dark mode. It doesn't look nearly as good in light mode. Actually rather terrible. – Andreas detests censorship Aug 28 '20 at 9:53
  • 1
    @Andreas Type, variable and function names in code blocks? Why would you put those in code blocks? If it's just a short identifier, you would use inline code, no? – Sweeper Aug 28 '20 at 9:57
  • 2
    Yeah, I was a bit quick there. I meant inline code. ;) – Andreas detests censorship Aug 28 '20 at 10:04

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.

  • 3
    @user289905 The formatting I wanted to test isn't on that Design page. – ChrisW Aug 26 '20 at 7:04
  • 8
    @ChrisW Give it a try on Codepen: codepen.io/pen?template=VwvKygL. You can put whatever markup you want to test in a <div class="s-prose"></div>. – Adam Lear ModStaff Aug 26 '20 at 14:09
  • 7
    @ChrisW That's an excellent test case. I've whipped up a repro (codepen.io/bk-SO/pen/poyemwy) to see what it looks like myself. I'd say... less funky, but not entirely devoid of funkiness. I'll see if we can't get something done about this on the Stacks side either before or shortly after launch. – Ben Kelly ModStaff Aug 26 '20 at 14:12
  • @BenKelly Perhaps it would be OK if you just added a bottom margin to the sublist. Why switch off the bottom margin for :last-child? If would have guessed the margins (of the last child and its parent) ought to merge, harmlessly. Also FWIW you could have a look at how Discourse does this -- I think it renders correctly (on the screen) as far as I remember, though I don't know if it renders to HTML in the same way. – ChrisW Aug 26 '20 at 14:27
  • 4
    @BenKelly There’s a related feature request here: Better list spacing (nested lists and/or lists with multiple paragraphs). That should be marked with some status-* tag if you work on it or fix it. – Sebastian Simon Aug 26 '20 at 14:35
  • 2
  • 2
    Working on this over at the Stacks repo. github.com/StackExchange/Stacks/pull/531. We can also preview it at deploy-preview-531--stacks.netlify.app/product/components/prose – Aaron Shekey ModStaff Aug 26 '20 at 16:18
  • 1
    @AaronShekey The preview of this test case looks better, well done and thank you (and good luck with having changed it at the last minute :-p). – ChrisW Aug 26 '20 at 17:24
  • Looking at github.com/StackExchange/Stacks/blob/… the selectors on lines 125..139 or duplicated, I don't know why you didn't just *:last-child instead -- and like I said I don't know why you need that anyway because I would have guessed that a non-zero bottom margin of the last child would be OK because it should merge with the bottom margin of its parent (ditto lines 164..171) -- but I haven't tested this, so this is an ignorant comment you could ignore. – ChrisW Aug 26 '20 at 17:24
  • FYI I think that Discourse has zero margins between simple list items -- when all the list's list items only contain text, then the list is "compact" -- that looks nifty but perhaps they do it by emitting different HTML than yours, and it's not too important (as long as already you fixed this bug, I'm happier with it now). – ChrisW Aug 26 '20 at 17:28
  • 2
    I prefer being explicit to using a * selector, but you're absolutely right, there are opportunities to simplify this CSS. – Aaron Shekey ModStaff Aug 26 '20 at 17:29
  • 7
    Oof, extra unnecessary spacing between all lines. Why?? What led "making me scroll and move my eyes as much as possible" to be the new "in" thing in web design? – Asteroids With Wings Aug 27 '20 at 14:36
  • 9
    +1 for @AsteroidsWithWings What on earth has happened to line spacing? It was fine before. And it was the same ratio as comments. Now posts are stretched and comments look scrunched. What's with all the change for change's sake? Why are things fixed which ain't broke? – Andrew Leach Aug 27 '20 at 14:48
  • I just add my surprise about the huge lists nowadays. Seems like a general "don't use it" for all pages now. Due to "not being fully aware of all situations" I just add it as comment. – Shegit Brahm Sep 4 '20 at 6:55

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.

preview of a question with spoilers

It does work when you're writing an answer:

preview of an answer with spoilers

  • 8
    This is technically not a button, but a "badge" or "indicator" of sorts. I 100% agree that it should not be stopping the spoiler reveal on click though. Looking into it now – Ben Kelly ModStaff Aug 27 '20 at 15:08
  • 1
    Ah, I think this is actually due to the delay in the click attachments. Much like your other bug report, this is due to "tech debt" issues. For "reasons", we init these handlers at the same time we style the code in the preview/post. Does this work if you wait a bit? You can tell when that code kicks in by adding a code block to your post. I'll have a solution out later today, but I just wanted to make sure I wasn't barking up the wrong tree here. – Ben Kelly ModStaff Aug 27 '20 at 16:32
  • 1
    @BenKelly yes, if I add a code block and wait a bit, it works. – Glorfindel Mod Aug 27 '20 at 16:39
  • 2
    This has been fixed as of this morning's deploy. Thank you for your patience. – Ben Kelly ModStaff Aug 31 '20 at 18:13

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__

  • 1
    In my browser (Chrome on Windows), the blue link underline is above the underscore characters. – Andrew Leach Aug 27 '20 at 15:44
  • @mkrieger1 Wait, this bug is not related to spoilers? The blockquote formatting you used confused me… So the actual bug are the underscores intersecting with the underline? – Sebastian Simon Aug 27 '20 at 15:45
  • I didn't originally mean to say this is a bug. I just noticed that it looks different than before. – mkrieger1 Aug 27 '20 at 15:46
  • Newer Firefox versions have text-decoration-skip-ink: auto by default. There’s no intersection for me (Firefox Nightly 82.0a1). – Sebastian Simon Aug 27 '20 at 15:47
  • 1
    I think this is a bug, @mkrieger1. I added those tags, no worries. – Aaron Shekey ModStaff Aug 27 '20 at 15:54
  • 2
    @AaronShekey Even the second screenshot doesn't look right to me. The link text should be blue, not black. Currently this is inconsistent compared to comment style, where the links are blue. – HolyBlackCat Aug 27 '20 at 21:07
  • @AndrewLeach Same in Safari. Above the underscores. – Andreas detests censorship Aug 28 '20 at 9:57
  • 1

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.__

screenshot of unrendered italics

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

  • 1
    Now also reported here: No italics on mobile. – Sebastian Simon Aug 28 '20 at 4:06
  • 1
    On FF Android when "Desktop Site" is chosen italics are visible, when that is disabled so are italics. – Rob Aug 28 '20 at 4:55
  • 1
    @user289905 it's still a valid bug, they ought to fix both CSSs so the text is displayed correctly in either display mode. My prior comment was suggested as a workaround. I have Android 10, so the bug does occur with new equipment and software. – Rob Aug 28 '20 at 7:14
  • 5
    Not to derail the phone convo, but I found the issue. It was due to overly aggressive mobile css reset that preexisted these changes. The issue never showed before because we "fixed" the reset in the custom mobile post styles... which were dropped in favor of the new s-prose styles. Nice observation, this one is easy to miss. – Ben Kelly ModStaff Aug 28 '20 at 14:37
  • 2
    Its ok, both shog and rob should know better. And know where to find me :D – Journeyman Geek Mod Aug 28 '20 at 14:38
  • 1
    @JourneymanGeek No complaints here :P Just thought y'all might be interested in the fix – Ben Kelly ModStaff Aug 28 '20 at 14:46
  • Looks fixed, waiting for an SE employee to update the answer. – Jenayah Aug 31 '20 at 17:13
  • 2
    This has been fixed as of this morning's deploy. Thank you for your patience. – Ben Kelly ModStaff Aug 31 '20 at 18:14

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?

  • 5
    I agree, the font size on mobile is quite a bit smaller than it was before, and that's problematically small. – doppelgreener Aug 28 '20 at 13:23
  • 4
    Looks like this isn't an issue on the "mobile" views, but only on the "responsive" (full) views on mobile breakpoints. Taking a look into it to see if this is intentional and how it can be mitigated it not. Thanks for the report! – Ben Kelly ModStaff Aug 28 '20 at 14:32
  • 4
    The issue here is that the mobile views have a base font-size of 13px, while the responsive (mobile breakpoint) views have a base font-size of 11px. This bug is technically status-bydesign, but I've decided to bump the size of s-prose to match the mobile specific view sizing. There's a larger discussion to be had here about bumping the font-size globally for mobile breakpoints, but one fix at a time for now ;) – Ben Kelly ModStaff Aug 28 '20 at 16:30
  • 3
    This has been fixed as of this morning's deploy. Thank you for your patience. – Ben Kelly ModStaff Aug 31 '20 at 18:15
  • 1
    Thank you, @BenKelly, especially for getting it done so fast! I can actually read it now. – Bardic Wizard Aug 31 '20 at 22:45

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.

  • 9
    Wow. If this is true (I don't trust myself to understand WCAG specs), this completely undermines the whole rationale for the change. So, it's not "thou shalt use at least 1.5 line-spacing", it's "thou shalt not fall apart if thy user uses 1.5 line-spacing". – Steve Bennett Sep 5 '20 at 11:39
  • @SteveBennett: I am not a WCAG expert myself (hence my first answer above), but this supposed requirement sounded a bit onerous, so I "used the force and read the source", so to speak. – einpoklum Sep 5 '20 at 13:53
  • 2
    Just so people don't misinterpret SC 1.4.12: (1) WCAG does not contain a recommendation for a specific or even a minimum line height. (2) There is no requirement that websites provide a mechanism to change the line height. (3) The SC's goal is to make sure that if users change the line height in their browser (through browser settings or a user style sheet), then no content or functionality is lost, e.g. because of overlaps with other content. (Should anyone wonder, yes, I am an accessibility expert.) – Tsundoku Sep 7 '20 at 13:52
  • 2
    @Tsundoku: Indeed. The requirement-of-mechanism is for AAA sites and in 1.4.8. The question is what got into StackExchange people's minds to make them think they were supposed to set the line height to 1.5x ? – einpoklum Sep 7 '20 at 16:01
  • It's also pretty basic stuff that web devs have been dealing with just fine for some twenty or thirty years... 🤦‍♂️ – Asteroids With Wings Sep 7 '20 at 19:13
  • 2
    @AsteroidsWithWings: That's a weaker claim. Maybe the have and maybe they could do better. The point is that this particular change is another weird 'diktat', which reminds me a bit too much of the code-of-conduct business and the approach we saw there. – einpoklum Sep 7 '20 at 21:30
  • @einpoklum To be honest I think the community's reasonable expectation of control of and/or veto power over things stops way short of design changes that the company wants to make (basically, this has nothing to do with governance so it wouldn't ever be our place to insist upon a say), but I hear your broader point. – Asteroids With Wings Sep 7 '20 at 21:38
  • @AsteroidsWithWings: It's not as though this design change is something that the company investors or the board of directors needed done. This is supposedly something that caters to user's needs - and yet is done without consulting users and ascertaining what would actually serve their needs. Mind you, I didn't even say "asking permission", I said "consulting" and "ascertaining". – einpoklum Sep 7 '20 at 21:50
  • @einpoklum No disagreement that some consultation/testing would have been helpful at least – Asteroids With Wings Sep 8 '20 at 9:59
  • Or even just the web developers understanding what those web development standards are actually saying. – Christian Rau Sep 9 '20 at 15:04

Let us re-hide spoilers

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.

  • I've seen a post on one site that used spoilers to make a "matching" game, which highly depended on being able to re-hide spoilers, and that would be broken by these changes. – Sonic the Anonymous Hedgehog Aug 30 '20 at 8:41
  • I agree, re-hiding is important. A new badge could be added to the revealed spoiler to let it get back to the hidden state. – bracco23 Sep 1 '20 at 15:05

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

⭐Revert Stack Exchange Formatting⭐

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



GitHub repository -- help me revert it faithfully!

  • 1
    Thank you for this. The Stylish theme seems to introduce a small indentation of the first line of code blocks: i.stack.imgur.com/QGh31.png – Andre Aug 31 '20 at 15:08
  • 1
    @Andre: thanks for reporting! Just fixed it. Go to the Stylish website again and update the style :) the updated Chrome extension should go live in 1-2 days. – Prid Sep 1 '20 at 6:21
  • 2
    Thumbs-up for the can-do attitude! Now just need mobile Firefox to stop being a jerk about extensions (Chrome too, but that's probably a lost cause). – Shog9 Sep 2 '20 at 1:06
  • @Prid the usercss doesn't work well with dark mode on SO (code has light bg and becomes unreadable) – ThiefMaster Oct 18 '20 at 9:33
  • @ThiefMaster: are you using the Chrome Extension? If so, hit the icon to view options, and turn off Additional Reversions. – Prid Oct 18 '20 at 14:18
  • No, I'm using the stylus usercss in firefox – ThiefMaster Oct 18 '20 at 14:31
  • 1
    @ThiefMaster: added a new Stylus usercss [Dark mode] where I've removed the bg colors for light version. It should use the original dark mode bg colors now. Check the post for link. – Prid Oct 18 '20 at 15:18

The Help Center article Markdown Editing Help needs some love:


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.

  • 3
    Ah, nice catch. Will update today. – Ben Kelly ModStaff Aug 27 '20 at 15:18
  • This has been fixed as of this morning's deploy. Thank you for your patience. – Ben Kelly ModStaff Aug 31 '20 at 18:16
  • I'm currently seeing the text: To hide a certain piece of text and have it only be visible when a user clicks it... on meta.stackexchange.com/editing-help/#spoilers. It might be a caching thing, or possibly we're looking at different pieces of text. Wouldn't be the first time I've done that :P – Ben Kelly ModStaff Aug 31 '20 at 18:21
  • 1
    @BenKelly I'm seeing it too now. Thanks! – Glorfindel Mod Aug 31 '20 at 18:22

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:

(118 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.

  • 5
    Given when you wrote this, you may have only seen the change after the first round of re-adjustments. Prior to that re-adjustment, paragraphs were significantly harder to differentiate. The re-adjustment decreased the line-height somewhat (from 1.6 to 1.5) and increased paragraph spacing (from 1em to 1.4em). The combination of those makes it considerably easier to differentiate paragraphs than with the original change. Now, the overall change is usable, which the original change wasn't. If the current values were initially used, I expect there would have been dramatically less objection. – Makyen Aug 28 '20 at 11:58
  • This is possible. I literally was offline almost the entire day, only logging in to keep my streaks, on account of being sick. I miss all the fun :D. But it certainly is a surprising quality of life difference for me I have never considered... – Journeyman Geek Mod Aug 28 '20 at 11:59
  • 5
    Maybe there can be an option for people that need such large spacing between lines to read with optimal efficiency, and the default can be what the other 99% prefer. – user1271772 Aug 28 '20 at 22:50
  • (just a thanks to speak out what I usually forget to take into account when talking about design.) – Shegit Brahm Sep 7 '20 at 14:49

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

partially hidden spoiler in tag wiki

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

  • 3
    This is "intended", due to some tech debt in the way that we attach the click handlers to non-post items. Leaving here as a bug since it definitely needs fixed (and will very likely happen today). – Ben Kelly ModStaff Aug 27 '20 at 15:07
  • This has been fixed as of this morning's deploy. Thank you for your patience. – Ben Kelly ModStaff Aug 31 '20 at 18:16
  • @BenKelly: Thanks for all the quick fixes and clarifications! – V2Blast Aug 31 '20 at 20:43

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".


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:

Screenshots of Chrome and Firefox

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

  • 1
    Can I ask what device you're using this on? Looks like it might be a tablet-sized device from your screenshots. My mobile (Pixel 3) chrome/ff on Android look good, so I'm guessing it's an issue on the tablet breakpoints. Taking some time today to look into this further. – Ben Kelly ModStaff Aug 28 '20 at 14:19
  • @Rob To confirm, also on this device or in general? Looks as expected on desktop for me, but I'd rather check than assume. – Ben Kelly ModStaff Aug 28 '20 at 16:47
  • @BenKelly I've updated this answer. – Rob Aug 28 '20 at 21:13
  • I'm on Samsung S8 phone and the text appears smaller... very interesting. – mindstormsboi Aug 29 '20 at 6:25
  • 1
    @mindstormsboi Part of the problem with newer phones is the manner in which the screen size is reported, according to BrowserSpy my screen is only 360 pixels wide and 740 pixels high. Another site howbigismybrowser.com reports 980x1666 with different results at: helpx.adobe.com/ca/analytics/kb/… --- it comes from not multiplying the indicated by the density - it's the 'Retina Display problem'. --- I'd offer better research if I used the browser with the problem as my daily, known problem. – Rob Aug 30 '20 at 3:32
  • On chrome on android, with the responsiveness enabled, the text sometimes runs outside of the blue box in close notices. – Matt Samuel Sep 6 '20 at 21:32

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

enter image description here

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.

  • 1
    What in your image is "undesired formatting effects"? – Catija ModStaff Sep 1 '20 at 2:24
  • @Catija: h1 (or # in MD) clearly never had the correct font-size, so its usage was more akin to a sub-heading rather than denoting an enitrely new section. With the increase in size, the intended meaning is lost and the new bigger size gives off a different connotation. In the left image h1 works as a sub-heading that coherently fits the full answer, while in the right image the new h1 size makes the sub-sections feel disjointed and like separate articles. The author might've been using it incorrectly, but the change in size is too big and disproportionate to the paragraph font size. – Prid Sep 1 '20 at 2:48
  • @Prid I kinda see your point, but I also don't see the problem. It's actually more helpful to have bigger headers, rather than small ones. – 10 Rep Sep 1 '20 at 2:49
  • @10Repisn'tactiveonMSE: oh, no problem at all in having more diversity :) i'm merely pointing out older posts being affected by this in that their intended purpose may get lost. The old h1 size was closer to the current h2, and the author 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. I'd like old answers to be preserved as much as possible with their original intended formatting. – Prid Sep 1 '20 at 3:03
  • 1
    Semantically, answers shouldn’t even have an <h1>, because that’s reserved for the title of the page, which is the question title. That at least is the opinion of me and MDN. – Sebastian Simon Sep 1 '20 at 8:17
  • @user289905: the formatting syntax is in Markdown, so it's hard to realize that # = h1. I guess they should change # to h2 instead :) – Prid Sep 1 '20 at 8:38
  • 1
    @Prid Please put explanations like that in your actual answer, not in the comments - I know you're responding to me but the important thing is that the argument you're making is in your actual post. Telling us "this is bad" without suggesting what to do instead or even explaining why it's a problem leaves us with no next steps. Help us out by giving us whatever guidance you recommend - we may not do it the way you suggest but it gives us somewhere to start. – Catija ModStaff Sep 1 '20 at 12:49
  • @Catija: thanks for the heads up, makes perfect sense :) – Prid Sep 1 '20 at 16:17
  • 3
    I'm with @user289905 on this: H1 usage should be very rare, as every question page already has one at the top; regardless of how it's rendered, semantically you're creating a new top-level section which... Rarely makes sense in questions and never makes sense in answers. The, heh, BIGGER issue here is that it makes the question title bigger - longer - and causes some titles to wrap that previously didn't. – Shog9 Sep 2 '20 at 1:04
  • 1
    Yeah, I noticed this just recently, too. Now all my carefully crafted one-liners are literally and metaphorically broken. And I was almost about to laud them for putting back a bit more sanity into the line spacing when I noticed those monstrous headings. And I don't particularly care if it was called "h1", "h2", or "squagglegobbles", it was a sub heading inside the answer. If I, and everybody else, used it "wrong" for the last 10 years, that's not quite a good reason to just break all those old posts to "teach a lesson" or whatever. Then make # h2 rather than h1. – Christian Rau Sep 2 '20 at 8:53
  • @ChristianRau Making # result in <h2> has at least two problems: it requires rerendering all posts again, which potentially breaks posts that couldn’t be migrated to CommonMark, so it may not be worth it for this “incorrect” use-case; and I used these headings correctly, so I’d have to edit every single answer of mine that uses headings to fix them manually. I could agree with decreasnig the font size in CSS by one heading level. – Sebastian Simon Sep 2 '20 at 9:10
  • Well, of course, just using the old font sizes from the last 10 years would solve it. But...that'd be the solution for this whole "new" formatting afterall. ;-) – Christian Rau Sep 2 '20 at 9:27

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

No way to reveal the spoiler

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:

While editing the profile

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

No longer have that option

  • 3
    This has been fixed as of this morning's deploy. Thank you for your patience. – Ben Kelly ModStaff Aug 31 '20 at 18:22

Revealing spoilers requires third-party Javascript

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


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

  • Hello
  • World
  • Test


- Hello
- World
- Test

This looks exactly the same as lists with paragraphs:

  • Hello

  • World

  • Test


- 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;

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).

  • In the interest of accessibility, I would argue against markup that creates hard-to-read text. SE has enough accessibility issues as it is, without adding new ones. – Tsundoku Sep 9 '20 at 16:59
  • 1
    @Tsundoku I understand the point but the accessibility issue already exists because people already use small text, via hacks. And in fact this change would improve accessibility by making correct semantic markup available (this is my main motivation for requesting this feature!). And as far as small font readability is concerned this is trivially (and canonically) fixable by (a) increasing zoom level or (b) using a custom stylesheet. – Konrad Rudolph Sep 9 '20 at 19:10

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):

image of some text

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)


"... 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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .