771

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

Syntax

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, and you can't have spaces between separators (- characters)

    (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

Limitations

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.

FAQ

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.

34
  • 94
    Is there a plan to add a table button (wizard, csv converter, something?) to the editor for those... less fluent in md? Nov 23, 2020 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, 2020 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, 2020 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. Nov 23, 2020 at 18:23
  • 34
    @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 StaffMod
    Nov 23, 2020 at 19:07
  • 1
    @Ollie It was added to meta.stackexchange.com/editing-help. We'll update the help center once we're ready to roll support out network-wide.
    – Adam Lear StaffMod
    Nov 23, 2020 at 22:33
  • 2
    Glad to finally have table formatting, instead of having to rely on complicated MathJax to make "arrays". Hope the rollout goes well! (...Also, it bothers me that that last header about migrated posts is missing a question mark at the end. >.>)
    – V2Blast
    Nov 24, 2020 at 0:48
  • 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. :) Nov 24, 2020 at 14:58
  • 2
    @SonictheK-DayHedgehog I'm still around, just had a busy day yesterday and didn't manage to triage the feedback. I'll catch up on things and will do my best to support the responses in this question throughout the week.
    – Ham Vocke StaffMod
    Nov 25, 2020 at 7:57
  • 2
    This syntax seems fairly similar to Markdown Extended Syntax's tables.
    – Robotnik
    Nov 26, 2020 at 0:28
  • 1
    Can you address forcing of header content to uppercase? E.g., in section "Limitations". Nov 27, 2020 at 8:10
  • 2
    @P.Mort.-forgotClayShirky_q I'm still trying to figure out the right course of action for uppercasing headers. I want to run this by our designers once they're back from holiday next week to see if this is something we want to keep or not.
    – Ham Vocke StaffMod
    Nov 27, 2020 at 8:13
  • 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 StaffMod
    Dec 4, 2020 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 StaffMod
    Dec 11, 2020 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, 2020 at 14:24

41 Answers 41

237

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?

19
  • 153
    "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. Nov 24, 2020 at 4:16
  • 62
    @CodyGray The purpose of that text was less "I agree with it" and more "I see where you're coming from, but please...". Nov 24, 2020 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, 2020 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, 2020 at 8:36
  • 11
    Worse, is one character, but breaks into two when uppercased. Similarly, breaks into three, plus more. ſßstflSSSSTFL (what?) Nov 28, 2020 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, 2020 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. Nov 29, 2020 at 22:41
  • 7
    @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, 2020 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, 2020 at 14:48
  • 3
    @Polygnome See the above two comments. Dec 4, 2020 at 20:04
  • 1
    @Polygnome Capitalizing ß as SS is not wrong. See § 25 E3
    – jazzpi
    Dec 7, 2020 at 13:03
  • 2
    There is a workaround using MathJax: meta.stackexchange.com/a/357525/391772. It's not ideal though. Dec 7, 2020 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, 2020 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. Dec 8, 2020 at 9:16
  • 4
    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. Dec 14, 2020 at 18:54
123

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

enter image description here

8
  • 54
    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 StaffMod
    Nov 26, 2020 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, 2020 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, 2020 at 9:45
  • 6
    @Tinkeringbell is "Code" supposed to be pluralized as "Codes" or "Codez"? :)
    – Zev Spitz
    Dec 5, 2020 at 20:06
  • @Zev Oof, hard question... ask a native speaker? ;)
    – Tinkeringbell Mod
    Dec 6, 2020 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. Dec 6, 2020 at 12:55
  • 1
    @ZevSpitz You haven't checked out my skillz in HTMLz yet.
    – Ray
    Dec 7, 2020 at 16:06
  • @HamVocke comic sans with a red font?
    – A P
    Jul 6, 2022 at 18:10
78

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:

ASR API Date CV F IER LS-c LS-o
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, Wikipedia and Reddit:

enter image description here

Other examples of a table where sorting would be useful (feel free to add your example to the list):

15
  • 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. Nov 24, 2020 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 StaffMod
    Nov 25, 2020 at 16:24
  • 33
    @HamVocke for the reader. Same as on Wikipedia. Nov 25, 2020 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 StaffMod
    Nov 25, 2020 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. Nov 26, 2020 at 10:31
  • 35
    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 StaffMod
    Nov 30, 2020 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. Nov 30, 2020 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. Dec 4, 2020 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. Dec 6, 2020 at 17:33
  • 12
    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.
    – jaskij
    Dec 8, 2020 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, 2020 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. Dec 9, 2020 at 10:07
  • 1
    @Liam I'd use the table for a question on the accuracy of speech recognition apis. Linguistics SE, or DS. Dec 9, 2020 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, 2020 at 10:13
  • 5
    @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, 2020 at 18:43
72

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 |

9
  • 10
    Spoilers don’t support all of Markdown syntax, including code blocks and blockquotes. Nov 23, 2020 at 18:21
  • 17
    Don't support all or most of Markdown syntax: meta.stackexchange.com/questions/116613/…
    – zcoop98
    Nov 23, 2020 at 18:50
  • 6
    How about spoilers inside the table format?
    – Robotnik
    Nov 27, 2020 at 2:54
  • 12
    Stop spoiling the fun^H^H^Htable! Dec 3, 2020 at 17:01
  • 1
    You won't really need tables in spoilers. That's really rare. Dec 11, 2020 at 15:50
  • 8
    @TechExpertWizard Puzzling would beg to differ. Jan 8, 2021 at 15:38
  • @PatrickRoberts Oh. Jan 9, 2021 at 0:26
  • Perhaps this could get edited into the question? It's not a bug or a feature-request. Unfortunately you would lose 100s of points, but it seems like the right thing to do. Jul 16, 2021 at 20:10
  • It appears that the block quote tool (on the toolbar) does not format the table well; it does work if the > are added manually however.
    – user202729
    Sep 29, 2021 at 5:57
58

enter image description here Here's the code:

| This is what happens when MathJaX is used in a header: | $\textrm{Equation gets squished despite enough room:}$ |
| - | ------------------ |
|   | $\int e^x = f(u)n$ |

Likewise the headers can wrap around unnecessarily (this is an example of a real table that I typed to answer something):enter image description hereI had to do some tweaking to get the 4th column header not to look so ugly (and somewhat erroneous due to the "y" variable seemingly not quantified properly):

The two relevant code blocks are here:

| $a|b$ | $a|c$| $(a|b) \\wedge (a|c)$ | $a|(bx + cy), \\forall x,y$  | $a | (bx+cy)$
|-|-|-|-|-|-|-|
|T |T |T |T |T |
|T |F |F |F |Open in $y$ |
|F |T |F |F |Open in $x$ |
|F |F |F |F |Open in $(x,y)$ |

| $a|b$ | $a|c$| $(a|b) \\wedge (a|c)$ | $a|(bx + cy), \\forall x,y$     | $a | (bx+cy)$
|-|-|-|-|-|-|-|
|T |T |T |T |T |
|T |F |F |F |Open in $y$ |
|F |T |F |F |Open in $x$ |
|F |F |F |F |Open in $(x,y)$ |
9
  • 17
    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. Dec 6, 2020 at 18:06
  • 2
    Yes. Under the "Limitations" section, the original post said nothing about MathJax. Dec 6, 2020 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, 2020 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. Dec 7, 2020 at 17:21
  • 6
    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. Dec 8, 2020 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. Dec 9, 2020 at 22:21
  • @Edward it's really a terrible solution if you have a 15-row table that needs mathjax for just 1 symbol. Dec 31, 2020 at 16:17
  • Maybe a pointer to that math.meta question would be potentially helpful to others?
    – Edward
    Dec 31, 2020 at 16:33
  • 1
    @Catija It seems most of the other bugs and feature-requests on this thread were either given a "status-completed" or "status-deferred" etc. Is it possible to get a status update on the bug reported here? Apr 21, 2021 at 5:03
55

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

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.

9
  • 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, 2020 at 2:24
  • 28
    @Catija in that case the preview rendering is broken since it doesn't follow this rule. Dec 8, 2020 at 2:27
  • 3
    That's fair. I'll be interested to see whether we can make work or not. 🙂
    – Catija
    Dec 8, 2020 at 2:28
  • 6
    @Catija What is the status of this bug, it still seems to be an issue Oct 16, 2021 at 20:14
  • 5
    @Catija Still broken. And it unfairly makes question authors look bad. Just saw a question with a table that didn't render as a table and was annoyed that they posted that anyway, but then in the editor I saw that the preview does render it as a table, so it's not their fault. Mar 9, 2022 at 15:40
  • 2
    @Catija I ran into this bug today. Any information about the priority of this bug? Different codebases for preview and publish markdown make it difficult to maintain. 😕
    – kirogasa
    Dec 6, 2022 at 11:09
  • 1
    rpg.stackexchange.com/posts/204156/revisions still occurring :( Jan 22, 2023 at 0:56
  • @Catija This bug tripped up a user on Webmasters today. Before seeing the inconsistent behavior of the edit window and digging to find this thread, I had assumed like others that the user just didn't check their preview before posting a garbled table. Jan 26, 2023 at 8:48
  • Seems like it's still unfixed, barely over 3 years to the day this was originally reported: stackoverflow.com/posts/77641560/revisions
    – esqew
    Dec 11, 2023 at 18:15
51

Code in headers shouldn't be uppercased?

code sample uppercase
The same code sample is lowercase in the body
5
  • 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 Mod
    Nov 23, 2020 at 17:22
  • 12
    Fixed in Stacks. It'll be a moment before it gets into production. Nov 23, 2020 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 Dec 9, 2020 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. Dec 9, 2020 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. Dec 9, 2020 at 23:35
44

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

this is a table

...it fails in the actual post:

this|is|a|table
-|-|-|-
> 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.


Update

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.

Example:

|this|is|a|table|
|-|-|-|-|
|> markdown quote | > another quote | > quote 3 | > 4|
this is a table
> markdown quote > another quote > quote 3 > 4
8
  • 9
    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 StaffMod
    Nov 24, 2020 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? Nov 24, 2020 at 9:50
  • 7
    @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 StaffMod
    Nov 24, 2020 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, 2020 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 StaffMod
    Nov 25, 2020 at 7:52
  • Wait, why can't we markdown within a table cell?
    – einpoklum
    Dec 3, 2020 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. Dec 7, 2020 at 7:34
  • @HamVocke Same issue with a number and a dot in the first column (e.g. 1.). Renders fine in the preview, stops the table and starts a numbered list in live post. Same workaround.
    – GSerg
    Feb 24, 2021 at 19:31
42

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.

5
  • 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 StaffMod
    Dec 1, 2020 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|. Dec 1, 2020 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 StaffMod
    Dec 1, 2020 at 8:41
  • 2
    @HamVocke so status-deferred or planned?
    – Luuklag
    Dec 1, 2020 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 StaffMod
    Dec 1, 2020 at 9:44
36

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

preview on profile

Though they do show up on my actual profile:

actual profile

2
  • 8
    This is due to the old editor used in tag wikis, profile descriptions, and election nomination posts. It will soon get replaced, hopefully. Nov 23, 2020 at 18:59
  • 17
    @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 StaffMod
    Nov 25, 2020 at 16:42
35

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
line
break tags
pre tag with
line
break tags
> markdown quote
This breaks in real posts, but not the preview
>! spoiler
html <blockquote>
html blockquote with
line
breaks
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?

4
  • 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, 2020 at 20:31
  • 6
    Resounding agree on the spaghetti comment. The underlying source for this post is a mess lol
    – zcoop98
    Nov 23, 2020 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, 2020 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 StaffMod
    Nov 24, 2020 at 7:51
33

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

2
  • 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, 2020 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 StaffMod
    Nov 25, 2020 at 17:00
30

Please add the ability to make tables without headers.

1
  • 33
    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 StaffMod
    Nov 30, 2020 at 17:02
27

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.

2
  • 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 StaffMod
    Nov 27, 2020 at 8:06
  • @HamVocke Similar to this?
    – Ollie
    Nov 27, 2020 at 21:42
27

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.

5
  • Good find. Can confirm that I'm seeing the same weirdness in the example suggested edit you linked.
    – V2Blast
    Dec 6, 2020 at 22:36
  • 3
    gif Jan 8, 2021 at 6:20
  • The bug is still present.
    – Ruli
    Feb 5, 2021 at 20:59
  • An example suggested edit for those that'd like to see the bug in action.
    – BSMP
    Feb 9, 2021 at 20:48
  • This was fixed in the meantime.
    – riQQ
    Jun 18, 2021 at 19:27
21

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

2
  • 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, 2020 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, 2020 at 22:56
21

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

E.g.:

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.

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

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.

9
  • 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 StaffMod
    Dec 8, 2020 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...
    – jaskij
    Dec 8, 2020 at 19:48
  • While not rally being viable for the average, non-technical user who will just complain that it doesn't work.
    – jaskij
    Dec 8, 2020 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)
    – jaskij
    Dec 8, 2020 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 StaffMod
    Dec 8, 2020 at 20:32
  • 1
    Glad to help! I do hope this something comes sooner rather than later ;)
    – jaskij
    Dec 8, 2020 at 20:45
  • Related feature request: meta.stackexchange.com/q/358890/394472 Dec 29, 2020 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 Jan 4, 2021 at 21:08
  • An easy way to import is with an online tool: tableconvert.com - It imports: Excel URL HTML Markdown CSV JSON LaTeX SQL MediaWiki - Just [Import], click on the generated table, click on Import button that appears, now in the lower window choose your options, and copy, then paste into SE's editor. --- Complicated tables in less than a minute. --- There is more than one online site, but that one works well. --- If you want to test a bunch and add them to your Feedback, as a workaround, BMG.
    – Rob
    Jul 25, 2021 at 4:00
19

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

E.g.:

enter image description here

5
  • 3
    Should this be permanent, i.e.an autogenerated edit? Nov 24, 2020 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). Nov 24, 2020 at 19:42
  • 12
    Time for a Microsoft Excel plug-in ;)
    – Luuklag
    Nov 25, 2020 at 7:54
  • 4
    The new editor (being trialed on Teams) has a WYSIWYG table editor, which may/may not support this. Nov 25, 2020 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, 2020 at 8:42
18

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. And it doesn't necessarily reconstruct the actual table definition & contents used.

... and here we go:
https://stackoverflow.com/revisions/65207252/1

12
  • 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, 2020 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, 2020 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, 2020 at 19:29
  • 2
    @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, 2020 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, 2020 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, 2020 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, 2020 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 StaffMod
    Dec 9, 2020 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, 2020 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 StaffMod
    Dec 9, 2020 at 9:44
  • I already see posters at Cross Validated include example data in tables, so some fast way to convert to a readable formt like .csv is needed! Feb 1, 2021 at 20:10
  • @HamVocke My suggestion & motivation are clear. "At the very least please". "Unfortunately". Adding more work for curators is a problem, not a solution.
    – philipxy
    Apr 6, 2021 at 14:00
17

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.

8
  • Which keyboard shortcuts do you use when writing SE posts? I'm curious! Dec 6, 2020 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, 2020 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, 2020 at 22:33
  • @user1271772 All of them!
    – Ollie
    Dec 6, 2020 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, 2020 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, 2020 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, 2020 at 23:25
  • @V2Blast I'll wait until we actually have the shortcut so I can test it.
    – Ollie
    Dec 6, 2020 at 23:27
16
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.

13
  • @Ollie: Maybe post that as a bug-report-reply? I haven't gotten any inbox notifications about tables yet.
    – einpoklum
    Dec 3, 2020 at 21:46
  • @Ollie: Can you link to a partial screenshot of that?
    – einpoklum
    Dec 3, 2020 at 21:49
  • @Ollie : It's not that bad.
    – einpoklum
    Dec 3, 2020 at 21:51
  • Can you link to an example of an appear-to-be-table? Dec 4, 2020 at 0:55
  • @Userthatisnotauser: Sure. But why are you "not a user"?
    – einpoklum
    Dec 4, 2020 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, 2020 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, 2020 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, 2020 at 23:21
  • 6
    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 StaffMod
    Dec 7, 2020 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, 2020 at 9:11
  • 4
    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, 2020 at 9:19
  • 2
    @rene: I think you should make that an independent post...
    – einpoklum
    Dec 7, 2020 at 9:22
  • 4
    If you say so. Done that meta.stackexchange.com/questions/357555/…
    – rene
    Dec 7, 2020 at 13:00
15

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:

warning

4
  • Yeah, I came across that too. I really dislike that check.
    – Ollie
    Jan 7, 2021 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 Jan 8, 2021 at 3:44
  • 3
    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 StaffMod
    Jan 8, 2021 at 8:06
  • I'm also getting this error with my answer, and I think the question poster had the same problem. I couldn't find a work around.
    – mazoula
    Mar 19, 2021 at 5:58
14

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

4
  • 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. Nov 23, 2020 at 17:38
  • 1
    Isn't this status-bydesign ? Dec 6, 2020 at 18:07
  • Also, I cannot reproduce this in Chrome on Ubuntu 16.04. Dec 6, 2020 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 StaffMod
    Dec 8, 2020 at 9:10
13

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

5
11

Do the displayed tables have to be full width?

Or, more accurately, when a table is simple and small, as (for example), in this SQL question on Stack Overflow, it would be nicer to my way of thinking if the tables did not expand to the full width.

The tables there are:

ID Name
157 Bob
157 James
300 Phil
300 Keith
300 Paul

and:

ID Name
157 Bob, James
300 Phil, Keith, Paul

In my opinion, neither table benefits from being expanded to the width of a browser window on a big monitor.

This is an image of a narrower version of the tables (obtained by shrinking a Chrome window to its minimum width), but the final result could be a lot narrower still for these tables.

Shrunken version of the tables, but the final result could be narrower still

I'm not a web programmer (you mean, there are things called 'user interfaces'? I had no idea!), so I'm not sure what this request entails.

1
  • 1
    Yes, that is one of the first questions that comes up when starting to use this feature. Jul 23, 2021 at 9:17
10

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.

11
  • 9
    IMO the sort of people who go through the hassle of formatting with tables will probably double check that it is formatted correctly. Nov 23, 2020 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, 2020 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. Nov 23, 2020 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. Nov 23, 2020 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, 2020 at 7:36
  • @VLAZ isn't the editor window resizeable?
    – TylerH
    Nov 30, 2020 at 14:31
  • @TylerH resizable up/down but not left/right. Screenshot.
    – VLAZ
    Nov 30, 2020 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, 2020 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, 2020 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, 2020 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, 2020 at 15:16
9

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

For example:

enter image description here

1
  • 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 StaffMod
    Dec 7, 2020 at 8:52
9

Ability to repeat header, or have "sticky header"

This post has a very long table: 2020: a year in closing, because it lists stats for all ~200 sites in the SE network.

Here's what the top of the table looks like:

enter image description here

After about 200 rows, here's what the bottom looks like:

enter image description here

If I am interested in information in the lowest rows, then it's very hard to see what the headers are. No amount of zooming out will allow me to see the headers and the data at the same time. A solution could be to have the option to repeat headers after every 50 rows, for example. I have seen this on various tables on Wikipedia. Another option would be a "sticky" header, which remains present when you're scrolling up and down.

1
  • 3
    Hm... I bet a user script could tackle this without a lot of overhead.
    – zcoop98
    Jan 27, 2021 at 23:24
8

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

8
  • 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. Nov 26, 2020 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 StaffMod
    Nov 27, 2020 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, 2020 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 StaffMod
    Dec 4, 2020 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? Dec 4, 2020 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 StaffMod
    Dec 4, 2020 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. Dec 11, 2020 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, 2020 at 9:26

You must log in to answer this question.

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