Update: I've just enabled this feature network-wide. All sites across Stack Exchange are now able to use tables. Thanks for all the feedback. We'll keep monitoring this question and we'll continue to iron out some of the rough edges.

No waffling, right to the point:

What? When? Where?
Table support 2020-11-23 Meta Stack Exchange & DBA Meta
More table support week of 2020-11-30 DBA Stack Exchange
Even more table support week of 2020-12-07 Network-wide launch (if no major issues found)

That's right. It's finally time to support table syntax in our Markdown dialect. This has been a long-requested feature and we're happy that we can finally do something about it. Starting today you can include tables in your posts using the GitHub-flavored Markdown table syntax.

In the past, we've been hesitant to introduce table syntax to our Markdown dialect. One reason was the lack of a good standard. There are various formats floating around the web but there hasn't been a well-defined standard for a long time. CommonMark still doesn't specify tables in version 0.29.

Another major reason was that tables are hard to pull off. If done poorly, there's a risk that rogue tables ruin the entire page layout for our users. And turning a bunch of markdown into proper tables has always been a scary task when we still maintained our own markdown renderers.

A lot of time has passed and it's time to re-evaluate our concerns.

Switching to CommonMark is paying its dividends: The newly introduced open source Markdown renderers support table syntax and we can rely on them to handle this tricky task incredibly well.

The uncertainty around a well-specified table syntax hasn't completely gone away. Ideally, we'd use the official CommonMark syntax, if only there was one. However, we think that GitHub-flavored markdown offers a table syntax that's stable and usable enough to serve our purpose.

And finally, this is another case where we can happily promote a Stack Overflow for Teams feature to be used by all our network sites. When building Articles for Teams our Teams users let us know that table support is crucial for their documentation purposes. This request was one of the major triggers behind the whole CommonMark migration and supporting table syntax today.

Note: our usual holiday build freeze starts end of day Tuesday, November 24th. We want to start collecting feedback early but we won’t be able to address any issues until Monday Nov 30th, after Thanksgiving. If something’s going horribly wrong, we will disable the feature again (but let’s hope for the best!).


Okay, so how do you use tables? We've updated our formatting help to give you some guidance. But here's an overview for you.

A simple table looks like this:

| A header | Another header |
| -------- | -------------- |
| First    | row            |
| Second   | row            |

The result:

A header Another header
First row
Second row

The rules

  • You always need a header row

  • Cells are separated by a pipe (|) symbol

  • You can include leading and trailing pipes but don't have to

  • A header row has to be followed by a separator row with the same amount of cells

    (that's the |---|---| line)

  • The amount of space and - characters in a cell don't have to line up (but it sure looks nice if it does)

  • You can set the alignment of a table column by including a : in the corresponding cell of the separator line. A : on the left will make a column left-aligned (this is the default). A : on the right will make it right-aligned. Both, left and right :s will produce a center-aligned column.

    | left | center | right |
    |:---- |:------:| -----:|
    | One  | Two    | Three |
    left center right
    One Two Three


Markdown tables come with a set of limitations. They don't support everything you can do with HTML tables, and that's on purpose. Each cell can only include inline content (text, images, links, inline code).

You can't merge cells or rows.

Block content like multiple paragraphs, lists, code blocks, sub-tables and other complex stuff does not work. If you're trying to mix a Markdown table with inline HTML, you might be up for a wild ride.

You can't manually determine the width of a column. Your browser will decide what's a good width for any given column based on the content in your table.

If you need more details, I recommend taking a peek at the GitHub-flavored Markdown specification for tables.

Roll-out plan

Teams users have been able to use tables in their posts for a few weeks now, so nothing's changing over there.

Starting 2020-11-23 we're going to enable table support for Meta Stack Exchange and our table-loving friends over at DBA Meta Stack Exchange so you can start playing around with the feature, get familiar with the syntax and help us weed out some issues we have missed.

The plan is to enable tables on DBA Stack Exchange the week of 2020-11-30 if there's no feedback or concerns suggesting this was a bad idea.

After that, we're letting the feature sink in for a bit and gather more feedback before rolling it out network-wide to all sites across the Stack Exchange network. We're hoping to roll it out the week of 2020-12-07.


I found a bug. What should I do?

This is great! We know that table support can still have some rough edges. Please add an answer to this announcement that reproduces the issue you've found (if possible) and we'll investigate.

What took you so long?

The amount of effort to build and maintain our own renderer when we still built our own Markdown renderers made this change prohibitively expensive. Teams customers asking for this feature allowed us to spent time on fundamentally revamping our Markdown rendering functionality and to get all the foundations in place to finally support tables.

What happens if CommonMark adopts an official table syntax in the future?

We're trying to be as CommonMark compliant as we can be, so chances are we're going to support the CommonMark syntax if that ever happened. Our Markdown renderers (markdown-it and Markdig) both comply to the CommonMark specification. Most likely, it would be a matter of time until they adopted an official CommonMark table syntax. If they did, we could update both libraries to introduce the same syntax on the Stack Exchange network. If we ever get to that point, we'll know more details and can think through all the details.

Why did you choose the GitHub-flavored syntax over <my favorite syntax>?

GitHub-flavored Markdown's ("GFM") table syntax has a reasonable specification. It's working for other significant sites on the web. Our Markdown renderers support GFM-style tables out of the box. It was the most pragmatic choice from our point of view.

Will tables show up properly in the live preview?

Yes. Our live preview below the editor will render the tables as you type.

We've got some more refinements around inserting and editing tables lined up that we'll release in the next few weeks.

  • 86
    Is there a plan to add a table button (wizard, csv converter, something?) to the editor for those... less fluent in md? – Nick Nov 23 '20 at 17:22
  • 13
    Timely advice to readers, the easiest way is writing your tables in a spreadsheet and exporting in one of the markdown supported formats. – bad_coder Nov 23 '20 at 18:03
  • 5
    @Ollie Clearly, we're so excited about them, we don't want to let you hide them! :P (My guess, they're both not CommonMark, so they don't play well together) Feel free to post as an answer – Catija Nov 23 '20 at 18:11
  • 3
    There are a few table posts now in the Formatting Sandbox, e.g. this one highlighting a few differences between preview and finished post — and of course the usual sandbox weirdness. – Sebastian Simon Nov 23 '20 at 18:23
  • 5
    "Holiday build freeze on november 24th". Can I also get 5 weeks of christmas holidays please? – Luuklag Nov 23 '20 at 18:56
  • 2
    @Luuklag It's just until Monday the 30th of November. – Catija Nov 23 '20 at 19:02
  • 32
    @Nick yes, we're going to include buttons for inserting and editing tables in the new editor that we're going to present soon. Tables are complicated so we'll likely need a few iterations to get this right but I think this will be a step in the right direction. – Ham Vocke Nov 23 '20 at 19:07
  • 4
    @Catija, too bad. I guess there is another Americanocentric holiday the world has to suffer ;) – Luuklag Nov 23 '20 at 19:20
  • 4
    Thanks for implementing this. It might be quite handy in some situations. "Teams customers asking for this ..." That made me realize that this community here should have stronger ties to the Teams user community. That way whenever we want something we should tell Teams users how wonderful that would be for Teams first. :) – Trilarion Nov 24 '20 at 14:58
  • 5
    What holiday is this? My Google search for "November 24 holiday" only found the National Sardines Day. Is this for real? – Emil Jeřábek Nov 24 '20 at 16:05
  • 7
    @EmilJeřábek US - Thanksgiving. It's on Thursday the 26th. It's also not on a specific date, but the fourth Thursday of November. – Catija Nov 24 '20 at 16:09
  • 6
    @EmilJeřábek I must admit that National Sardines Day is a bit... of a fishy reason to take a vacation. – Journeyman Geek Nov 25 '20 at 9:44
  • 8
    @AndrewGrimm what kind of disability are we talking about? The HTML tables we're generating are using proper semantics and should work reasonably well for users who are using screen readers. A lot of care goes into our Stacks design system to make sure the colors and fonts we use work for visually impaired users. Accessibility is hard and we don't always get it right, but we're trying. If you notice something specific that's not accessible, please let us know. – Ham Vocke Dec 4 '20 at 11:11
  • 5
    @DavidConrad I get why this is confusing. Let me try to clarify: CommonMark is a popular markdown specification. Switching to CommonMark allowed us to replace our old, hand-rolled Markdown renderers with something off the shelve. CommonMark does not define tables (yet?). The open source renderers we introduced, however, support more than just CommonMark (GFM tables for example). That's the causality. Switching to CommonMark brought us open source renderers and they brought table support. – Ham Vocke Dec 11 '20 at 7:50
  • 6
    @TheTechExpertGuy That's not really how Community Wikis work. A CW is a signal that the post is open to editing and contributions from all people who wish to participate. It's not a way to shelter from rep gains. Additionally, this is an important release that Ham led and getting some reputation for that and taking the time to announce and support the release is... totally fair. We do not use CW for announcements. That would be a huge departure from our standards. This is also a big change, which is why it's been featured for a while, but "a pretty long time" is just a week, not so long. – Catija Dec 11 '20 at 14:24

35 Answers 35


Allow lowercase letters in table headers

It seems that table headers will always appear with uppercase letters, even if the Markdown has them as lowercase letters. This seems to be part of the styling for table headers: there's a text-transform: uppercase there.

I understand that stylistically, uppercase headers look better, and it serves to better signify that it's a header instead of just a normal cell. However, please provide an option to disable capitalization in table headers, for three main reasons:

Capitalization may be important to define and differentiate the header

In some cases, the casing of what's in the table actually matters to the content of the post. Example below:

User group Preference of style "HoTMaiL" Preference of style "Hotmail"
Former users 72% 23%
New users 19% 63%

If you click to edit the post, you'll see that the second heading actually has the text "HoTMaiL", while the third one says "Hotmail". However, they look exactly the same in the table headers. (For context, the first style was used by the site's initial founders to indicate that the site offered the first HTML-based email client - the letters "HTML" were capitalized.)

Violates rules of style in some handbooks, which require lowercase lettering in some specific cases even when using all caps

This also may violate rules of style in certain style handbooks, which state that some letters should be lowercase even if using all caps otherwise. As an example, in at least one style book, the names "McDonald" and "LaSalle" should be written as McDONALD or LaSALLE in all caps. But this styling doesn't allow for that. Example:

Prefers McDonald's Prefers Burger King
72% 23%
19% 63%

Some characters' uppercase forms may be vastly different from their lowercase forms

Finally, the all-uppercase styling can introduce quirks with characters that display differently in uppercase than in lowercase. For example, the long S character ſ's uppercase form is "S", and so tables that have that character will confusingly show the letter "S" instead of the long S character ſ. Example below:

Years Incidence of ſ in books
1700-1800 64%

It's also impossible to type the German eszett symbol ß into a header, as that breaks apart into "SS":

Characters that break in table headers ß
As pointed out by iBug in a comment: actual character in header: ß

While these instances can be worked around with code formatting, as after this answer was completed, code in table headers is no longer uppercased, the general etiquette on sites is to only use code formatting on things that are actually code, and this will go against that.

Can there please be some way to write lowercase letters in table headers, even if the preferred style is to have them all caps?

  • 149
    "I understand that stylistically, uppercase headers look better, and it serves to better signify that it's a header instead of just a normal cell." I don't even agree with that. Uppercase is more difficult to read. A bold weight and the shaded background are more than sufficient to indicate that the cell is a table header. Just make all the headers use normal case. If the author wants uppercase, they can type that. – Cody Gray Nov 24 '20 at 4:16
  • 60
    @CodyGray The purpose of that text was less "I agree with it" and more "I see where you're coming from, but please...". – Sonic the Curiouser Hedgehog Nov 24 '20 at 4:18
  • 11
    @CodyGray real problem with all uppercase is if a column header needs a case-sensitive title (like in a programming language) where the styling works against language rules. I visually like the choice from a design POV, but it takes away flexibility from a coding perspective. – bad_coder Nov 24 '20 at 17:25
  • 2
    Yeah. Even if it were implemented as having the current all-caps formatting as the default, but with some parameter or way to disable that in specific tables (other than inappropriately using code formatting for non-code), it'd be an improvement from always formatting it as all-caps, with no exceptions. – V2Blast Nov 27 '20 at 8:36
  • 11
    Worse, is one character, but breaks into two when uppercased. Similarly, breaks into three, plus more. ſßstflSSSSTFL (what?) – iBug says Reinstate Monica Nov 28 '20 at 19:14
  • 3
    @iBug: Unicode discourages the use of those ligature characters anyway: unicode.org/faq/ligature_digraph.html. However, the German eszett is a different matter, as it's a "real letter" rather than a purely presentational artifact. Fortunately, it does have an uppercase form (ẞ) which can be used in lieu of the lowercase form. – Kevin Nov 29 '20 at 22:36
  • 1
    @Kevin I knew that, and that's why that's the only character I edited into my post in response to their comment. Still, though, the fact that the lowercase eszett becomes "SS" instead of ẞ is unexpected. From the looks of it, this is a direct result of the CSS attribute, and thus would be extremely difficult to work around without drastically altering the code. – Sonic the Curiouser Hedgehog Nov 29 '20 at 22:41
  • 6
    @Sonic: I agree that the eszett is a problem. It is likely because, at the time the lowercase eszett was added to Unicode, capital eszett was not formally a thing in German. So far as I can tell, the new capital form is considered "optional," meaning that SS is still considered a valid alternative and Unicode has to pick one or the other. Since it previously picked SS, and has to contend with various stability policies, this is probably the path of least resistance. – Kevin Nov 29 '20 at 22:51
  • It's also impossible to type the German eszett symbol ß into a header, as that breaks apart into "SS" Actually, german has an uppercase ß, the ẞ. Capitalizing ß as SS is wrong. – Polygnome Dec 4 '20 at 14:48
  • 3
    @Polygnome See the above two comments. – Sonic the Curiouser Hedgehog Dec 4 '20 at 20:04
  • 1
    @Polygnome Capitalizing ß as SS is not wrong. See § 25 E3 – jazzpi Dec 7 '20 at 13:03
  • 2
    There is a workaround using MathJax: meta.stackexchange.com/a/357525/391772. It's not ideal though. – user1271772 Dec 7 '20 at 17:49
  • 4
    Aaron says that this will be in the next version of Stacks but he's having to work around some alignment issues. – Catija Dec 7 '20 at 20:46
  • 6
    @poke It was in the Stacks design, but was removed 7 days ago. Unfortunately, as Catija commented, they ran into some layout issues with that, so the latest version hasn't been deployed to the sites yet. They're still on the older version that has it. – Sonic the Curiouser Hedgehog Dec 8 '20 at 9:16
  • 3
    There can be lags in publishing to Stacks and getting Stacks into production. As you can imagine, there's quite a bit more testing that needs to happen on the production side before we can get our Stacks package updated everywhere. This is in production everywhere now and things are looking good across the app. – Aaron Shekey Dec 14 '20 at 18:54

Please include a help for table support as well.
See screenshot for implementation suggestion.

enter image description here

  • 50
    I just got a fix out for review that will add inline help for tables. The fix will go out early next week. Don't be disappointed, please: I had to deviate from your design suggestion a bit as I couldn't find a suitable font that matched your design. – Ham Vocke Nov 26 '20 at 10:35
  • 15
    Thanks for the work @HamVocke. My incredible font is hard to copy, I know. I sure do hope you found a suitable replacement that supports a giant S ;) – Luuklag Nov 26 '20 at 11:25
  • 7
    Too bad your font does not support a giant S @HamVocke, makes me want to downvote this answer ;) – Luuklag Dec 3 '20 at 9:45
  • 6
    @Tinkeringbell is "Code" supposed to be pluralized as "Codes" or "Codez"? :) – Zev Spitz Dec 5 '20 at 20:06
  • @Zev Oof, hard question... ask a native speaker? ;) – Tinkeringbell Dec 6 '20 at 10:49
  • 5
    @ZevSpitz "code" in the meaning of "text written in a programming language" is uncountable, so there is no need for a giant S (that meme is deprecated, anyway). Therefore, "Codez" is clearly better, giving an opportunity to show how 1337 you are. – Discrete lizard Dec 6 '20 at 12:55
  • 1
    @ZevSpitz You haven't checked out my skillz in HTMLz yet. – Ray Dec 7 '20 at 16:06

Add ability to lexicographically sort data in a column. I.e., make tables sortable (click on a header = sort the corresponding column).

E.g., useful in a result table:

Human 5.8 12.7
Google 2018-03-30 23.2 24.2 16.6 12.1 28.8
Google Cloud 2018-03-30 23.3 26.3 18.3 12.3 27.3
IBM 2018-03-30 21.8 47.6 24.0 9.8 25.3
Microsoft 2018-06-30 29.1 28.1 23.1 18.8 35.9
Speechmatics 2018-09-12 19.1 38.4 21.4 7.3 19.4
Wit.ai 2018-01-03 35.6 54.2 37.4 19.2 41.7

as we can do in most spreadsheet programs or Wikipedia:

enter image description here

Another example of a table where sorting would be useful: https://space.stackexchange.com/a/49247/1111

  • 8
    You would need Javascript to make it work and it typically only makes sense for tables with many rows. There could be a default sort order and users could sort by other columns as well. Typically upwards and downwards pointing triangles are used for that in web pages. Wikipedia for example has this feature. Teams users would probably like it a lot. – Trilarion Nov 24 '20 at 20:20
  • 20
    What's the idea behind this? Should this be a tool for the post author to sort a table when writing a post? Or is this supposed to be something for a reader so they can sort data according to their needs? – Ham Vocke Nov 25 '20 at 16:24
  • 29
    @HamVocke for the reader. Same as on Wikipedia. – Franck Dernoncourt Nov 25 '20 at 18:36
  • 20
    We've got prior art in Stacks, our design system. Maybe we can do something similar here. It's an interesting proposal and we'll have to think this through. – Ham Vocke Nov 25 '20 at 18:40
  • 2
    @HamVocke I can imagine it could be both. Even though the content creator could in principle create any desired sorting manually, it might be convenient to use the feature once it's there to also allow the post author to specify a default sorting. And once it's there one could also allow the reader to re-sort. Once you are there, you also might want to filter. Data tables comes to my mind. – Trilarion Nov 26 '20 at 10:31
  • 31
    We've discussed this idea with a bunch of folks today. We think this is harder to get right than it seems initially. Sorting table data will inevitably lead to follow-up questions: What about sorting multiple columns? What about different sorting methods (dates, integers, ...)? I agree that this is a nice feature but it takes more effort to flesh this out properly. – Ham Vocke Nov 30 '20 at 17:10
  • 8
    @HamVocke Thanks for the feedback. I agree that a perfect solution is very hard to achieve. In your shoes I'd simply imitate Wikipedia's sortable table. – Franck Dernoncourt Nov 30 '20 at 17:13
  • 8
    I love the ability to sort tables in Wikipedia; and I've updated a few articles to allow tables with "strange" data to sort correctly, and there are unfortunately lots of workarounds to sort things nicely. en.wikipedia.org/wiki/Help:Sorting I think there are few cases in SO where I would have benefitted from sorting a table. – Mark Stewart Dec 4 '20 at 17:03
  • 4
    Why don't we just do exactly what Wikipedia has? The code is not hard to access and is easy to imitate. – user1271772 Dec 6 '20 at 17:33
  • 11
    If sorting is ever introduced, please use a stable sorting algorithm (one which preserves previous order in case of ties) - this is an intuitive way to do multiple column sorting. – Jan Dorniak Dec 8 '20 at 18:44
  • 10
    I can't think of a single use case where this would be useful? If someone is adding so much data that sorting is useful, then that data is probably detrimental to the question being asked. Seems like an idea for ideas sake. Given the difficulty of the task I'd say there are better things to fix – Liam Dec 9 '20 at 10:02
  • 1
    @Liam easy to do client side. Tables can also be used in answers. No need for a table to be large for sorting to be useful. My table is an example where sorting would be useful. – Franck Dernoncourt Dec 9 '20 at 10:07
  • 1
    @Liam I'd use the table for a question on the accuracy of speech recognition apis. Linguistics SE, or DS. – Franck Dernoncourt Dec 9 '20 at 10:12
  • 1
    Right ok, I think I'm focusing on the list of names in Excel. I get that now, I still think it's niche TBH. I guess it depends on how this feature is going to get used and I don't think we know that right now. – Liam Dec 9 '20 at 10:13
  • 2
    @HamVocke "What about sorting multiple columns?" The easiest way to support this is by using a stable sort (and IMO that is the correct way to do column sorting; the non-stable variant is wrong). Then, if you want to sort by (Firstname, Lastname), you can sort the firstname column, then sort the lastname column. – Justin Dec 12 '20 at 18:43

The tables work just fine in blockquotes:

A header Another header
Row, row your boat Gently down the stream
Merrily, for life is but a burnout.

This is what happens in spoilers:

| A header | Another header | | -------- | -------------- | | First | row | | Second | row |


when MathJaX is in the header

There is a lot of wasted space when there's MathJax in a header:

enter image description here

Here's the code for what I tried so far:

| Can MathJax be used as a workaround for lower case letters? | $\textrm{Yes}$ |
| -------------- | --------------------- |
|     | $\int e^x = f(u)n$ |

| Is the right-side ruined just because there's Mathjax in the header? | $\int e^x=f(u)n$ |
| -------------- | --------------------- |
|     | $\int e^x = f(u)n$ |

| What about if we mix MathJax with non-mathjax? | $\int e^x=f(u)n$ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;It fixes it |
| -------------- | --------------------- |
|     | $\int e^x = f(u)n$ |

| So can there be a workaround? by using `&nbsp;` | $\int e^x=f(u)n$ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
| -------------- | --------------------- |
|It required 15 `&nbsp;` commands though, and the spacing<br> required at the end is sub-ideal. In fact without the `<br>` <br> commands I'm using, the right-side gets messed up again.<br> So there's even more wasted space on the left-side than <br> one would hope would be necessary.     | $\int e^x = f(u)n$ |

| So can there be a workaround? by using `&nbsp;` | $\int e^x=f(u)n$ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
| -------------- | --------------------- |
|It required 15 `&nbsp;` commands though, and the spacing required <br>at the end is sub-ideal. This is what the above table looks like if the <br>`<br>` comes just one word later. Lots of wasted space on the<br> left-side of the table, and still the right-side is slightly mesed up.     | $\int e^x = f(u)n$ |

| So can there be a workaround? by using `&nbsp;` | $\int e^x=f(u)n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~$ |
| -------------- | --------------------- |
|It required 15 `&nbsp;` commands though, and the spacing required <br>at the end is sub-ideal. This is what the above table looks like if the <br>`<br>` comes just one word later. Lots of wasted space on the<br> left-side of the table, and still the right-side is slightly mesed up.     | $\int e^x = f(u)n$ |
  • 15
    Reading this announcement, I thought that Mathjax in tables is intended to be supported. "inline content" seems to include Mathjax. I don't think it is part of "other complex stuff", as Mathjax cannot contain other markdown elements. But I could be wrong, this is all not very clear. Additionally, there currently does not appear to be a site where both markdown tables and Mathjax is supported, so it's currently hard to test whether it will work or not. – Discrete lizard Dec 6 '20 at 18:06
  • 2
    Yes. Under the "Limitations" section, the original post said nothing about MathJax. – user1271772 Dec 6 '20 at 21:34
  • 7
    As far as I can tell, this should just work. It's now live network-wide, though, so feel free to try. – Catija Dec 7 '20 at 17:03
  • 5
    @Catija Perhaps you could have specified that it just went live recently? The update to the original post was made 3 minutes before your comment, and the live update was not long before that. Your comment reads to me as if it had been live network-wide for a long time and something was wrong with my brain when I tested it several times earlier. – user1271772 Dec 7 '20 at 17:21
  • 5
    The troubles with column width are most certainly related to the fact that the width of MathJax content is not known before it is actually rendered, hence the table layout cannot adapt to it. If one of the entries in the column is regular text, this forces the column to accommodate this text, alleviating the issue. – Emil Jeřábek Dec 8 '20 at 12:08
  • @EmilJeřábek That's a good point. I don't see why there has to be so much wasted space in the left column in my last two examples though. Also the amount of space that $\int e^x=f(u)n$ would be "estimated" to take up before rendering the MathJax, is more than the amount after rendering, so I'm a bit puzzled by the right-column being so narrow in some of the above examples. – user1271772 Dec 9 '20 at 22:21
  • @Edward it's really a terrible solution if you have a 15-row table that needs mathjax for just 1 symbol. – user1271772 Dec 31 '20 at 16:17
  • @Edward I wonder if you could consider deleting your commemts, and I will too. I consider it to be "noise" that is distractong people from the signal. I wrote this question math.meta.stackexchange.com/q/32841/202425 (different username but same network profile), which contains a very large number of examples of that type of table. If you want to add to the answer that this is a temporary fix with major flaws such as slowing down loading of the page, then please do so, but I don't want comments suggesting to people that this bug shouldn't be fixed. Actually look at v1 of this question – user1271772 Dec 31 '20 at 16:30
  • Maybe a pointer to that math.meta question would be potentially helpful to others? – Edward Dec 31 '20 at 16:33

Code in headers shouldn't be uppercased?

code sample uppercase
The same code sample is lowercase in the body
  • 3
    Yeah, my bad, I've deleted the comment. I keep forgetting there's two ways of doing code samples (inline vs. blocks) :) Still, doesn't seem a bug to me since everything else is uppercased too... and I wonder how many people will put code samples a.) in a table and b.) in a table header. I still like the way it is now, at least that looks consistent. – Tinkeringbell Nov 23 '20 at 17:22
  • 12
    Fixed in Stacks. It'll be a moment before it gets into production. – Aaron Shekey Nov 23 '20 at 17:43
  • Why would you want this? And why don't you use do CODE SAMPLE instead of code sample if you want code in headers to be uppercased? See this: meta.stackexchange.com/a/357019/391772 and this: meta.stackexchange.com/a/357525/391772 – user1271772 Dec 9 '20 at 22:21
  • 2
    @user1271772 I want it lowercase not uppercase. Before this was status-completed it was uppercase like this: i.stack.imgur.com/yFPuJ.png. – a hat-collecting arachnid Dec 9 '20 at 23:03
  • @amask-wearingarachnid Ok that was a bit confusing, because now your post shows code sample in lower case. So this is just a subset of the larger feature request to allow lower case in headers. You helped it to become possible for code blocks, and now we need them to get it working for everything else. – user1271772 Dec 9 '20 at 23:35

While putting a markdown quote in a table renders in the preview without breaking...

this is a table

...it fails in the actual post:

> markdown quote | > another quote | > quote 3 | > 4
this is a table

markdown quote | > another quote | > quote 3 | > 4

While this is an edge case, it would be nice if the preview matched the real rendering.


As pointed out by @HamVocke♦ in a comment below, as long as you add pipes | to the outer edges of the table row containing the leading > character, it should render without breaking.


|> markdown quote | > another quote | > quote 3 | > 4|
this is a table
> markdown quote > another quote > quote 3 > 4
  • 8
    Thanks! The rendering differences between our preview and server-side rendering are always subtle and annoying. I figured out that you can get both to render the table properly if you include leading and trailing pipe characters in each row. – Ham Vocke Nov 24 '20 at 9:16
  • 4
    @HamVocke What's the general cause of differences between the client-side renderer and the server-side one? I've seen a lot of bugs crop up with differences between one and the other, especially since the CommonMark migration began. Why are the two renderers different; why not use the exact same code for rendering on both sides? – Sonic the Curiouser Hedgehog Nov 24 '20 at 9:50
  • 6
    @SonictheK-DayHedgehog client-side and server-side renderer are two different pieces of code, both sticking to the CommonMark specification. As it turns out, the specification leaves room for ambiguity and both interpret the spec slightly different at times, leading to the differences we're seeing. We can't run the same code in both places, we've got to use JavaScript client-side while our backend runs on C#. We're trying to eliminate these differences as good as we can (and as is reasonable given time and impact). – Ham Vocke Nov 24 '20 at 10:00
  • Thanks for the info @HamVocke! It makes sense that adding the outer pipes | would bound the row, and help the renderer recognize it as a table row rather than a blockquote. – zcoop98 Nov 24 '20 at 16:12
  • 2
    Given that we've found a workaround that removes any ambiguity, I'll give this a status-deferred. Ideally we align both libraries here but this will take some fixes in the respective libraries directly which is more cumbersome than us fixing it directly. – Ham Vocke Nov 25 '20 at 7:52
  • Wait, why can't we markdown within a table cell? – einpoklum Dec 3 '20 at 21:42
  • @HamVocke Worth considering running a node.js microservice maybe on the server? Or the less trivial, but far cooler alternative would be to compile markdig to webassembly using wasm or blazor. – David Mulder Dec 7 '20 at 7:34

The link renderer (which automatically converts raw links to a link displaying the title of a question) works in the preview, but not in the actually rendered post, unless you add leading and trailing spaces.

Source Link Spaces
| https://meta.stackexchange.com/q/277369 | A Terms of Service update restricting companies that scrape your profile information without your permission leading+trailing
|https://meta.stackexchange.com/q/333965 | https://meta.stackexchange.com/q/333965 trailing
| https://meta.stackexchange.com/q/336526| https://meta.stackexchange.com/q/336526|leading|
|https://meta.stackexchange.com/q/7931| https://meta.stackexchange.com/q/7931 none

The third row is especially interesting since the client side preview renderer correctly guesses my intentions but the server side renderer does not.

You can start to edit this post to see it for yourself, or check this screenshot.

  • 3
    I suspect that our server-side renderer is tripping because you didn't use leading/trailing spaces after the | characters of your tables. You shouldn't have to use spaces, of course, but my hypothesis is if you added them, it'd work properly - so this might work as a workaround for now. I'll do some digging and see if I can reproduce. – Ham Vocke Dec 1 '20 at 8:08
  • 4
    So now you found a bug: in the current revision (the 3rd) the preview shows the penultimate row with "leading" in the Spaces column, while the saved version shows it in the Link one with a full content of https://meta.stackexchange.com/q/336526|leading|. – fedorqui 'SO stop harming' Dec 1 '20 at 8:21
  • 8
    @fedorqui'SOstopharming' thanks for breaking this down, this is helpful. Looks like this is an issue with Markdig's link parser (it seems to interpret | as part of a URL which isn't allowed according to the official RFC). This will take a fix in Markdig itself which will take us a bit longer since we've got to coordinate those changes. For the time being: Use spaces, please. – Ham Vocke Dec 1 '20 at 8:41
  • 2
    @HamVocke so status-deferred or planned? – Luuklag Dec 1 '20 at 9:27
  • 3
    @Luuklag deferred. This is not in our hands alone so I can't make any promises about the timeliness of a fix. – Ham Vocke Dec 1 '20 at 9:44

Tables don't show up in the profile editor preview:

preview on profile

Though they do show up on my actual profile:

actual profile

  • 8
    This is due to the old editor used in tag wikis, profile descriptions, and election nomination posts. It will soon get replaced, hopefully. – Sebastian Simon Nov 23 '20 at 18:59
  • 16
    @user289905 good thinking but that's not what it is. It's the same editor we're using elsewhere but it looks like I missed passing down the tables option for user profiles, tag wikis and election nominations. Totally my fault and hopefully a quick fix. (Narrator: it was a quick fix) – Ham Vocke Nov 25 '20 at 16:42

The tables also do not render in the tag wiki previews:

enter image description here

However, the tables do render properly in the actual tag wiki (here).

  • According to user2389905's comment on another answer: "This is due to the old editor used in tag wikis, profile descriptions, and election nomination posts. It will soon get replaced, hopefully." – V2Blast Nov 24 '20 at 1:12
  • 7
    same update as on that other post: Not an old editor, just me being silly. Got a fix up for review. Some more testing and a few critical eyes and I'm confident that it can go out early next week (after our build freeze is over). – Ham Vocke Nov 25 '20 at 17:00

After the note about HTML element limitations, I wanted to experiment:

left align center align right align none/ default align
markdown link HTML Image:
pre tag
triple backticks just yield code spans
backtick inline code, with no added breaks html code tag
pre tag with
break tags
pre tag with
break tags
> markdown quote
This breaks in real posts, but not the preview
>! spoiler
html <blockquote>
html blockquote with
html code tag
with inline
break tags
* markdown ul 1. markdown ol html <strike>
Description List (<dl>):

item (<dt>) 1
item 1 description (<dd>)
description list item 2
item 2 desc
Ordered List (<ol>):

  1. list item 1
  2. list item 2
  3. list item 3
Unordered List (<ul>):

  • list item 1
  • list item 2
  • list item 3
Default aligned <ol> list:

  1. list item 1
  2. list item 2
  3. list item 3
markdown italic markdown bold markdown bold italic # markdown header
html italic html bold html bold italic

html <h1> header

superscript <sup> subscript<sub> markdown horizontal --- rule html horizontal
rule <hr>

(SE allowed HTML tags refresher)

It generally seems, on the surface, to play fairly nice right now!

Is there any reason this support would foreseeably change in the future?
Or can this be counted upon as a feature?

  • 5
    Currently the system won't let you write CommonMark lists inside cells. If we start seeing HTML tags spread in posts it's a step back, because only rarely would you see any HTML when editing other people's posts. Also, not keeping the separators aligned makes for some serious spaghetti. – bad_coder Nov 23 '20 at 20:31
  • 6
    Resounding agree on the spaghetti comment. The underlying source for this post is a mess lol – zcoop98 Nov 23 '20 at 20:56
  • 2
    Thanks for the effort, the upcoming Editor might help a little; but wasn't able to parse and render the contents of this answer. – Rob Nov 24 '20 at 1:46
  • 14
    I'm hesitant to make any recommendation that encourages mixing HTML and Markdown. There are just too many nasty cases how this can go wrong and break assumptions. The official spec is the source of truth. Anything that you manage to pull off beyond that is coincidence. Practically, it's not like we're changing our Markdown renderers frequently - so if it works now, chances are it will continue to work for a good while. – Ham Vocke Nov 24 '20 at 7:51

Please add the ability to make tables without headers.

  • 29
    This is nothing we want to do for the time being. The official table extension specification requires a table header and we absolutely want to stick to a (de facto) standard and avoid rolling our own. Whenever either the GitHub-flavored Markdown spec or CommonMark specify tables that work without headers, we'll gladly support this. Until that happens, all tables will have to include a header. – Ham Vocke Nov 30 '20 at 17:02
  • @HamVocke What about allowing lower-case letters in headers? – user1271772 Dec 7 '20 at 17:23
  • 5
    @user1271772 we're working on that. – Ham Vocke Dec 7 '20 at 18:26

The tables render differently in the timeline of a post than in the actual thing. For example, here is a screenshot of a table in the timeline of this post:

enter image description here

And here's the table in the actual post:

enter image description here

You can see that the "user group" and "preference of style" are not separated with the lines the | pipe should make. The header font is also not as black/bold in the timeline.

  • 4
    Good catch. Looks like the style definitions of the tables within the post clash with the table structure used for displaying the timeline. – Ham Vocke Nov 27 '20 at 8:06
  • @HamVocke Similar to this? – Ollie Nov 27 '20 at 21:42

When suggesting an edit, and switching from "Rendered Output" to "Markdown" and back to "Rendered Output", the table disappears in the diff.

Before switching:

table appears before switching

After switching:

table disappears after switching

Also, the table header padding in the diff is interesting.

  • Good find. Can confirm that I'm seeing the same weirdness in the example suggested edit you linked. – V2Blast Dec 6 '20 at 22:36
  • 2
    gif – Yatin Jan 8 at 6:20

If you have text right above or below the table, the preview renders the table markdown as a table. But after you save the post, the table is not rendered and just shows the markdown code.

You can use the code below as an example. If you try to edit my answer, it shows a table in the preview but not in the backend-rendered post view.

Raw Markdown:

text above table

How it looks in Preview

Table formatted correctly

Result after posting

text above table |test|test| |----|----| |test|test|

So either the backend renderer is broken or the preview renderer is broken.

  • 2
    In general, this is pretty standard. The only markdown I know of that works without a full paragraph break is the paragraph immediately following a heading. I'm not even sure it works if a heading doesn't have a double return before it. It's just still considered part of the prior block. – Catija Dec 8 '20 at 2:24
  • 12
    @Catija in that case the preview rendering is broken since it doesn't follow this rule. – Kodos Johnson Dec 8 '20 at 2:27
  • 1
    That's fair. I'll be interested to see whether we can make work or not. 🙂 – Catija Dec 8 '20 at 2:28

Can we get "Table" option in the markdown editor toolbar, same as which was already introduced in the Stack Overflow documentation.

Screenshot taken from SO documentation:

Table option in toolbar

  • 8
    This is part of the new editor, that is already live in SO Teams. I think it will eventually roll out network-wide: meta.stackexchange.com/a/356354/361484 – Luuklag Dec 3 '20 at 11:27
  • @Luuklag: Judging from the Stack Moderators team, there's currently no shortcut for it - Ctrl+E doesn't seem to work... The "table" button in the current editing interface there just seems to insert a table "template" with 2-3 rows and 2-3 columns (it doesn't prompt the user to choose a number of rows and columns or anything). – V2Blast Dec 6 '20 at 22:56

Add ability to transpose a table (it is tedious to do it manually).


enter image description here

Example of use case: when writing the table, the author may realize the table's width has become too large and transposing the table would make it fit without having to horizontally scroll.

  • 3
    I think this is a great idea and will save people a lot of time! – user1271772 Dec 6 '20 at 21:11
  • 6
    Even Excel doesn't have this feature... good luck, it would be great. – TylerH Dec 7 '20 at 14:52
  • 15
    @TylerH copy, paste special / check the "transpose" box ;-) – Mathieu Guindon Dec 9 '20 at 20:26
  • 1
    @MathieuGuindon Mats Mug at it again... :-) – TylerH Dec 9 '20 at 20:51
  • 6
    Related Code Golf Challenge – Jonas Jan 6 at 18:45

Add ability to swap two columns in a table (it is tedious to do it manually).


enter image description here

  • 3
    Should this be permanent, i.e.an autogenerated edit? – Trilarion Nov 24 '20 at 15:03
  • 1
    @Trilarion Good point, I was thinking autogenerated edit for the author, but making columns switchable from the reader end would be nice as well (in case the reader prefer a different column order than the one decided by the author). – Franck Dernoncourt Nov 24 '20 at 19:42
  • 11
    Time for a Microsoft Excel plug-in ;) – Luuklag Nov 25 '20 at 7:54
  • 4
    The new editor (being trialed on Teams) has a WYSIWYG table editor, which may/may not support this. – Sonic the Curiouser Hedgehog Nov 25 '20 at 8:08
  • This isn't a must-have for me, but would be fantastic to have nevertheless - I hadn't even considered the possibility! :) – V2Blast Nov 27 '20 at 8:42

Please add a keyboard shortcut to insert a table into a post. I really like these new tables and would appreciate not having to click Show formatting tips → Insert table → copy/paste table to insert them.

  • Which keyboard shortcuts do you use when writing SE posts? I'm curious! – user1271772 Dec 6 '20 at 21:15
  • 1
    @user1271772: Ctrl+L to add links, Ctrl+B and Ctrl+I to add bold/italic formatting, Ctrl+U for bulleted (unordered) lists and Ctrl+O for numbered (ordered) lists, Ctrl+Q for blockquote formatting. – V2Blast Dec 6 '20 at 22:33
  • Also, Ham replied to Nick's comment on the question confirming that there would be a button in the editing interface to make inserting/editing tables easy, but I'm curious what that'll look like - presumably, the keyboard shortcut for this will do the same thing as clicking that button. – V2Blast Dec 6 '20 at 22:33
  • @user1271772 All of them! – Ollie Dec 6 '20 at 22:40
  • 1
    Judging from Arulkumar's answer, the new post editor seemingly includes (or will include) a "Ctrl+E" shortcut for tables. Though judging from the Stack Moderators team, there's currently no shortcut for it - Ctrl+E doesn't seem to work... The "table" button in the current editing interface there just seems to insert a table "template" with 2-3 rows and 2-3 columns (it doesn't prompt the user to choose a number of rows and columns or anything). – V2Blast Dec 6 '20 at 22:55
  • @V2Blast That's a very good point. Thing is, we don't know when the new editor will be made public, and until then I'd still appreciate a keyboard shortcut. Also, the Ctrl+E is a shortcut for searching Google, so that may need to be jiggered. – Ollie Dec 6 '20 at 23:00
  • 1
    @Ollie: I'm pretty sure the SE post editor's shortcuts "override" any that are already used by the browser for something else. For instance, Ctrl+B brings up the Bookmarks sidebar in Firefox, but when used in the post editor, it bolds the thing. Likewise, Ctrl+L jumps to the address bar in Firefox, but in SE's post editor, it inserts a link. As for your other point, Yaakov says in another MSE answer that they won't be making any more changes to the current editor (and that the new Stacks Editor will eventually be rolled out network-wide). – V2Blast Dec 6 '20 at 23:25
  • @V2Blast I'll wait until we actually have the shortcut so I can test it. – Ollie Dec 6 '20 at 23:27

Add the ability to copy tables from spreadsheet software (Microsoft Excel, LibreOffice Calc, Google Sheets, and others) and paste them in the edit box on SE.

Given how tedious creating Markdown tables is, I've discovered that ever since GitLab introduced this option it has become my preferred workflow.

  • 7
    This is a tricky one. I certainly see the value and we've played around with this when building the new editor. Handling pastes - especially from Office apps - is a wild ride. You have to deal with a lot of inconsistencies and edge cases depending on the source you copied from (including browser differences). On top of that: Markdown tables only support a limited subset of what Excel tables can do - no merged cells, no resizing, no custom formatting. I haven't found a good way to handle those cases in a way that's not confusing for a user yet, but I'm all ears! – Ham Vocke Dec 8 '20 at 19:40
  • 4
    The GitLab MR looks quite simple - even a very basic support is better than none. IMO even if you strip all formatting, as long as I can paste a table it's a win. It might not fit in with how SE works, but a simple implementation with the option to improve over time is better than getting it perfect - which you are right, is very hard. I believe I'm not a typical user, but as long as it's predictable even imperfect behavior is fine. What I describe here is probably best for the more technical sites though... – Jan Dorniak Dec 8 '20 at 19:48
  • While not rally being viable for the average, non-technical user who will just complain that it doesn't work. – Jan Dorniak Dec 8 '20 at 19:48
  • (and I almost started a rant why I dislike Markdown... no multi line table rows is one of those reasons, although not viable for you to solve) – Jan Dorniak Dec 8 '20 at 19:51
  • 6
    GitLab's implementation indeed looks tempting, they're relying on the plain text representation of a copied Excel table (in contrast to the HTML representation which I struggled with in previous attempts). Let me take this for another spin, maybe we can get something in place. Thanks for the pointer, I really appreciate it! – Ham Vocke Dec 8 '20 at 20:32
  • 1
    Glad to help! I do hope this something comes sooner rather than later ;) – Jan Dorniak Dec 8 '20 at 20:45
  • Related feature request: meta.stackexchange.com/q/358890/394472 – Boghyon Hoffmann Dec 29 '20 at 23:40
  • I just posted an answer which shows a quick way to format data from Excel (while we wait for the feature to be implemented). Check it out here: meta.stackexchange.com/a/359176/299995 – Kodos Johnson Jan 4 at 21:08
I just wanted to say...
Thank you very much !

Having said that...

I would like to have some bot/query/process go over all my posts on the network, and suggest those posts with what appear to be tables, for me to review and edit into actual tables. Example.

  • @Ollie: Maybe post that as a bug-report-reply? I haven't gotten any inbox notifications about tables yet. – einpoklum Dec 3 '20 at 21:46
  • @Ollie: Can you link to a partial screenshot of that? – einpoklum Dec 3 '20 at 21:49
  • @Ollie : It's not that bad. – einpoklum Dec 3 '20 at 21:51
  • Can you link to an example of an appear-to-be-table? – ReinstateMonica3167040 Dec 4 '20 at 0:55
  • @Userthatisnotauser: Sure. But why are you "not a user"? – einpoklum Dec 4 '20 at 9:34
  • 1
    I know basically nothing about SEDE... But might there be any way to find such posts using a SEDE query? – V2Blast Dec 6 '20 at 22:28
  • 1
    @V2Blast: 1. That would be an extremely expensive query which would probably fail. 2. Queries are site-specific, aren't they? 3. I meant for this to be done for everyone, not for individuals to be able to do it for themselves. – einpoklum Dec 6 '20 at 23:09
  • 1
    @einpoklum: Regarding point #3, I wasn't meaning this as a replacement for your request, just as an alternative (e.g. in case SE doesn't implement this). I think point 2 is correct. (I know nothing about your first point.) – V2Blast Dec 6 '20 at 23:21
  • 5
    I see how this could be useful but it's nothing we're going to invest time in now. The cost/benefit ratio doesn't look compelling to me. People have been creative to work around the fact that we didn't have proper tables in the past, so surfacing all these posts with confidence is going to be a massive rabbit-hole for marginal gain. These posts seem to have been doing fine without proper tables so there's not much of an urgency to trigger a conversion now. – Ham Vocke Dec 7 '20 at 8:40
  • @HamVocke: That's fair enough, I guess. However, the obvious cases of code-segments with lots of -----'s and | whatever | might not be a lot of effort. – einpoklum Dec 7 '20 at 9:11
  • 3
    Here you go: data.stackexchange.com/stackoverflow/query/… is per site, as I couldn't get the networkwide version to run within 2 minutes. – rene Dec 7 '20 at 9:19
  • 1
    @rene: I think you should make that an independent post... – einpoklum Dec 7 '20 at 9:22
  • 3
    If you say so. Done that meta.stackexchange.com/questions/357555/… – rene Dec 7 '20 at 13:00

When highlighted, the table body is orange while the header stays gray enter image description here

  • 2
    To be clear, this is specifically the :target (or #fragment) flash highlight animation that you get when e.g. opening an answer in a new tab. – Sebastian Simon Nov 23 '20 at 17:38
  • 1
    Isn't this status-bydesign ? – user1271772 Dec 6 '20 at 18:07
  • Also, I cannot reproduce this in Chrome on Ubuntu 16.04. – user1271772 Dec 6 '20 at 21:10
  • 4
    This one dropped off my radar. Yes, by design. Table headers have a dedicated background color that's getting painted instead of the default yellow-ish background color we use when highlighting. Table bodies don't define an explicit background color, so the yellow tint from the question body gets applied here, too. – Ham Vocke Dec 8 '20 at 9:10

I posted this on meta S.O originally because I couldn't post it here (not enough rep) but apparently that restriction was removed and I was told maybe I should repost it here.

I tried to post this markdown table in an answer on S.O

| Number of bytes | First code point | Last code point | Byte 1 | Byte 2 | Byte 3 | Byte 4 |
| - | ------- | -------- | -------- | -------- | -------- | -------- |
| 1 | U+0000  | U+007F   | 0xxxxxxx |          |          |          |
| 2 | U+0080  | U+07FF   | 110xxxxx | 10xxxxxx |          |          |
| 3 | U+0800  | U+FFFF   | 1110xxxx | 10xxxxxx | 10xxxxxx |          |
| 4 | U+10000 | U+10FFFF | 11110xxx | 10xxxxxx | 10xxxxxx | 10xxxxxx |

It formats correctly in the preview:

good preview

But the editor claims it's a bad code block and won't let me post the answer:


  • Yeah, I came across that too. I really dislike that check. – Ollie Jan 7 at 18:38
  • I just submitted an edit to your post and it worked perfectly. I don't understand why you are getting an error. All I did was remove the three ` from the start and end – The Grand J Jan 8 at 3:44
  • 2
    Thanks for raising this. This is an issue with our code formatting detection, not with tables themselves but I totally see your point. Let's track the discussion around this bug over in your meta.SO post so we have it in one place. Cool? – Ham Vocke Jan 8 at 8:06

I am left wondering how this will impact copy-editors. Because editing wrongly formatted tables may become the most tedious chore a copy-editor is likely to encounter.

Hopefully you can build-in some kind of detection mechanism to give the OP a warning if the table isn't well formatted.

  • 9
    IMO the sort of people who go through the hassle of formatting with tables will probably double check that it is formatted correctly. – Kodos Johnson Nov 23 '20 at 18:21
  • 2
    @KodosJohnson posters experienced with Markdown derivatives aren't the ones I'm worried about. It's the inexperienced members who will likely post broken tables (that will be left for others to fix.) I like the idea, it's a game changer. – bad_coder Nov 23 '20 at 18:29
  • yea and it will probably be worse if they include a button to generate the table code, which I think is in the new editor which is going to be rolled out. – Kodos Johnson Nov 23 '20 at 18:45
  • 3
    Editing badly formatted tables is already one of the more tedious tasks (that and disentangleing error stacks that got munged when someone used quotes instead of code to highlight them). At least now the tables will look pretty afterwards. – ben is uǝq backwards Nov 23 '20 at 20:41
  • Honestly, my biggest fear about this. I like using tables when it makes sense and I just generate them. Saves me a lot of hassle. Making sure to manually format the table correctly sounds like a slow torture when the editor screen is slightly too small to fit the whole thing and you're trying to add one more column. I do hope some sort of convenience tool emerges. – VLAZ Nov 24 '20 at 7:36
  • @VLAZ isn't the editor window resizeable? – TylerH Nov 30 '20 at 14:31
  • @TylerH resizable up/down but not left/right. Screenshot. – VLAZ Nov 30 '20 at 14:41
  • 1
    @VLAZ Ah, bummer. While SO should fix that, it can be user-fixed w/ a user style with the following CSS selector/properties: textarea { resize: revert !important; position: relative; z-index: 1; } – TylerH Nov 30 '20 at 14:45
  • 1
    @TylerH not sure it's a great solution, either. When I use a vertical monitor, I don't have much extra space to the side. When I use a horizontal monitor, I use the three columns editor userscript which splits the page in three and shows the question (left panel), the answer box (middle panel), and answer preview (right box). Looks like this. So, I'm not sure it's a great idea to make the box wider. I already use a text editor if the content is wider. – VLAZ Nov 30 '20 at 14:49
  • 1
    @VLAZ Well trying to scroll an input box wider than your monitor only makes as much sense as wanting to view a box wider than your monitor, so that doesn't seem like much of a concern :-P – TylerH Nov 30 '20 at 15:01
  • @TylerH hence my wish for some convenience tool that helps. When adding code in an answer, we can use a stack snippet. It's a bit of a hack if the code is not actually meant to be runnable but it does allow you to more easily edit it if it's too wide, since you can scroll left/right in the editor window. Then you can delete the starting snippet tag and you're left with just a code block. A more complex table like here becomes very hard to edit. 3-column view | view with your CSS – VLAZ Nov 30 '20 at 15:16

On Opera (unsupported I know but FYI) with Opera's dark mode on on Android 10: table borders are sometimes grey, sometimes white:

enter image description here


A Stack Overflow or Database Administrators minimum reproducible example should have code that readers can cut and paste and run, including initial values for tables or similar data structures formatted in a tabular way for readability.

Unfortunately these new markdown tables are going to make it harder to get MREs because initial values will be given in a format that we can't cut and paste and run. In particular, for SQL, and, ironically, at Database Administrators.

At the very least please update the documentation for tables and for code post composition and editing to emphasize that use of markdown tables should not interfere with giving code that is both readable and able to be cut and pasted and run, in the post and not just at a link.

Functionality to generate code from text tables found at language sandbox sites like sqlfiddle.com is helpful for writers. But readers should not be expected to all reproduce that effort.

Here we go.

joining two tables to display data relative to each other

  • 4
    Tables are for outputted data, not input data/code. You don't write SQL in table format. So I'm not sure how this will negatively affect those sites. – TylerH Dec 2 '20 at 2:27
  • 3
    @TylerH Because, as I said, MREs have initial values that are tables & uninformed askers use non-code to express them. (Also answerers tolerate that.) Moreover there is no way to cut & paste output tables to format them per current markdown tables. Essentially the markdown is useless in a post in which a MRE is relevant. – philipxy Dec 2 '20 at 19:23
  • 2
    I don't see how OP including data in a table either as desired output or as current input/current data is harmed (vis a vis 'copy and paste') by doing it in markdown, since it already can't be used anyway via copy and paste. – TylerH Dec 2 '20 at 19:29
  • 1
    @TylerH As I said, people will use markdown to format tables instead of code block text or actual output. The markdown source or output when cut & pasted is valid input code or text output, so using markdown moves a question away from a MRE. I would agree that cutting & pasting markdown input or output is more or less as bad as not using input code or actual output, but, as I said, it's not useful for MREs & it would be helpful to emphasize to table markdown users to not use it in MREs. – philipxy Dec 2 '20 at 19:53
  • 4
    Do you have an example of people using table-based layouts for MREs on Stack Overflow or DBA.SE? It sounds like you expect people will start formatting code as markdown tables for some reason. – TylerH Dec 2 '20 at 20:13
  • 2
    Yeah... that doesn't seem like a problem. If anything, it seems like an improvement, because the OP there has displayed their data as an image, which... you already can't copy and paste into any runnable scenario/environment. At least if they input their tabular data as a markdown table, you can at least copy the text. – TylerH Dec 2 '20 at 20:22
  • @TylerH It happens all the time. Use of images instead of text exemplifies how tables will be similarly misused. – philipxy Dec 2 '20 at 20:29
  • 5
    I've been pondering on this one for the past few days and keep arriving at the same conclusion: There's not much we can do to prevent people from using improper formatting. Code samples and example data should be formatted as code blocks to render everything verbatim. If that doesn't happen, it's not only tables messing with the representation. * characters could cause text to be rendered bold, a # comment would be interpreted as a headline. We rely on commenters to point this out or editors to fix this directly. This has worked reasonably well in the past. – Ham Vocke Dec 9 '20 at 8:02
  • @HamVocke On clicking the edit function you could pop up a warning that a table that is data to be used in example code (which includes debugging questions) should not use the selected feature. Etc. But I would also argue that despite some people asking for table formatting, supplying a non-code formatter before (at least a link to) a code formatter is getting priorities wrong & not accounting for human nature & the site's poor user education. (Did you even look at what percentage of tables should be formatted either way at SO & DBA?) – philipxy Dec 9 '20 at 8:18
  • 3
    @philipxy I'm sorry but I really don't understand what you're suggesting. Are you saying we should treat all user input as plain text and abandon Markdown by default to avoid mistakenly formatting something that could happen to be a code sample? – Ham Vocke Dec 9 '20 at 9:44

Can we also enable table support on the onebox in chat?
Currently this post renders as: enter image description here

Which is not as elegant as the post is on the site itself.

  • 9
    I think most post formatting doesn't display properly when a question is "oneboxed" in chat... – V2Blast Nov 24 '20 at 1:14
  • 17
    This is a problem that's much harder to solve than it seems on the surface. Since we're truncating the onebox content, chances are high that we cut things off right in the middle of a table and can't make proper sense of it anymore. I agree that this would be super slick but I'm gonna have to say "not now". – Ham Vocke Nov 25 '20 at 7:55

Add ability to specify thead (<th>) labels (i.e., row headers).

For example:

enter image description here

  • 3
    Semantically marking columns as headers is not possible at the moment and would require changes to the GFM specification which is nothing we trigger from our end. Everything in the header row will be created as a <th> and be wrapped in a <thead>, and that's what we've got to work with. Maybe there will be an update to the tables specification in the future and we can inherit this functionality. – Ham Vocke Dec 7 '20 at 8:52

Spoilers in a table render in neither the preview nor the actual post:

A header Another header
>! First >! row
>! Second >! row

And in the preview:

enter image description here

  • 4
    I think this is more of a feature request than a bug. It seems that tables only support the same mini-Markdown features used in comments and bounty remarks. – Sonic the Curiouser Hedgehog Nov 26 '20 at 21:33
  • 10
    Yep, this is definitely by design. Block-level elements like blockquotes, code blocks or spoilers won't work in Markdown tables. – Ham Vocke Nov 27 '20 at 8:08
  • 3
    @HamVocke I understand what you mean, but it's hard to call this 'by design'. It's more like markdown just doesn't support it, not that they intentionally chose for them to not work. This is one of the few cases where forking from Markdown is highly called for. – TylerH Nov 30 '20 at 14:36
  • 6
    @TylerH I disagree. Forking Markdown would be a maintenance nightmare and we just took a step in the opposite direction with the CommonMark migration. Not allowing block-level elements inside tables is not an oversight. If you want to have a concise table syntax, you simply can't allow things that allow e.g. code blocks or blockquotes without running into conflicts. Tables rely on line breaks to mark the end of a row, blockquotes and code blocks allow line breaks as part of their content. Tables with line breaks within its cells would hardly be usable. – Ham Vocke Dec 4 '20 at 7:45
  • @HamVocke "Block-level elements like blockquotes won't work in Markdown tables..." Wait a minute, I think I found a workaround by using the blockquote HTML tag. Doesn't seem intentional, should I post this as an answer to this question? – mindstormsboi Dec 4 '20 at 15:39
  • 4
    @mindstormsboi mixing HTML and Markdown allows you to break out of some limitations but will sooner or later get you in trouble regarding other edge cases. There's another answer here outlining some of the things you can do with Markdown tables and HTML. Personally, I wouldn't encourage mixing HTML and Markdown since we know results can be hard to predict. – Ham Vocke Dec 4 '20 at 20:06
  • I agree with @SonictheK-DayHedgehog . I don't think someone would really need to put a spoiler into a table. It doesn't really make much sense. It's just fun(ny) lol. – Tech Expert Wizard Dec 11 '20 at 15:57
  • 1
    @HamVocke Would allowing inline spoliers using say >!spoiler text!< = <span>spolier text<span> help? I came across this and posted a Feature Request here – TheMaster Dec 29 '20 at 9:26

Using the mobile version of the site, some columns can be too thin and thus impossible to read its content. See this post:

The original table is this:

App versions  Free? Description
Diccionario de la lengua española
by RAE and ASALE
Duolingo Android
Windows Phone
yes app to help you learn Spanish with game-like lessons
(similar a Memrise)
yes se basa en tarjetas que contienen una palabra/expresión/oración en un idioma y su traducción a otro idioma. La frecuencia con la que te sale cada tarjeta depende de tu facilidad para memorizarla, que tú seleccionas una vez destapas la tarjeta. De esta manera practicas las palabras que te cuestan más. Para saber más, consulta esta respuesta.
Speed Spanish Android yes app with multiple tools and games to help user's learn Spanish, including: Dictionary, translator, conjugator, lessons & multiplayer games. Developed by Kes Walker

From my mobile phone I see it as follows. You can reproduce it by switching to the mobile version of the site and reducing the screen to the minimum:

enter image description here

As you can see, the first column is extremely thin. I don't know why it does not take more space and all of it is given to the 4th column.

  • 6
    Yeah, unfortunately the browser's default layouting algorithm can be annoying, especially on small viewports. Our Stacks folks got a basic version for responsive tables up their sleeves but last time I checked they were still struggling with a few edge cases. Once we get that in, tables should start scrolling horizontally on narrow viewports if they exceed a minimum width. – Ham Vocke Dec 10 '20 at 13:16
  • 1
    @HamVocke that's good news. Thanks for being so supportive – fedorqui 'SO stop harming' Dec 10 '20 at 13:48
  • 3
    I checked in with our Stacks folks and it turns out I was wrong. Tables do start scrolling if they need to on small viewports already. However, this isn't available in the mobile view of the page but only in the responsive view. Make sure to choose "full site" and "enable responsiveness" in the footer to switch. – Ham Vocke Dec 11 '20 at 8:02

You must log in to answer this question.

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