773

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? Commented 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
    Commented 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
    Commented Nov 23, 2020 at 18:11
  • 4
    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. Commented 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
    Commented 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
    Commented 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
    Commented 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. :) Commented 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
    Commented Nov 25, 2020 at 7:57
  • 2
    This syntax seems fairly similar to Markdown Extended Syntax's tables.
    – Robotnik
    Commented Nov 26, 2020 at 0:28
  • 1
    Can you address forcing of header content to uppercase? E.g., in section "Limitations". Commented 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
    Commented 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
    Commented 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
    Commented 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
    Commented Dec 11, 2020 at 14:24

41 Answers 41

1
2
7

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.

2
  • 9
    I think most post formatting doesn't display properly when a question is "oneboxed" in chat...
    – V2Blast
    Commented Nov 24, 2020 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 StaffMod
    Commented Nov 25, 2020 at 7:55
7

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
Android
iOS
yes
Duolingo Android
iOS
Windows Phone
yes app to help you learn Spanish with game-like lessons
Anki
(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.

3
  • 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 StaffMod
    Commented Dec 10, 2020 at 13:16
  • 1
    @HamVocke that's good news. Thanks for being so supportive Commented Dec 10, 2020 at 13:48
  • 5
    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 StaffMod
    Commented Dec 11, 2020 at 8:02
5

When viewing a table as a reader, add an option to display the table full screen (or at the least some larger view), since it is quite annoying to do the horizontal scrolling for wide tables.

Example of table for which a larger view would be beneficial:

Row # Date Action Stock A price Stock A cost basis Gain/loss Commutative Gain/loss Taxed Commutative Gains Cumulative Taxed Commutative Gains
1 2020-02-07 Buy 100 of stock A 10 10 0 0 0 0
2 2020-03-17 Sell 100 of stock A 20 20 1000 1000 1000 1000
3 2020-03-22 Buy 100 of stock A 18 18 0 1000 0 1000
4 2020-03-29 Sell 100 of stock A 3 3 -1500 -500 -1500 -500
5 2020-04-10 Buy 50 of stock A 2 2 + (18-3) = 17 0 -500 1500*(50/100)=750 250
6 2020-04-15 Sell 50 of stock A 3 3 50 -450 (3-17)*50=-700 -450
7 2020-05-15 No activity on stock A 3 NA 0 -450 0 -450

A larger view is much more readable:

enter image description here

1
4

Enabled network-wide? Well, not entirely... One small network of indomitable chatters still holds out against the invaders.

This doesn't work in chat. Can we get updates for chat too please?

4
  • 5
    Why would you want to insert a giant table in chat? Commented Dec 18, 2020 at 6:26
  • 2
    I said nothing about "giant", just a table. Commented Dec 18, 2020 at 7:20
  • 2
    Let me try again: tables are for presenting long-form information. Why would you want to do this in chat? How would this be useful? Commented Dec 18, 2020 at 7:33
  • 6
    @CodyGray Same reason multi-line code snippets work in chat? Markdown support should be as consistent as possible, so that I don't have to remember which features don't work in chat/comments/questions/answers/…
    – Bergi
    Commented Dec 18, 2020 at 11:00
3

You might want to support colspan.

Right now, only MultiMarkdown does, I believe. See this SO question for a good test case.

The answer in that particular case, eg, is this:

| Available  |||| Process   | Allocation    ||||     Max      ||||
|---|---|---|---|-----------|-----|---|---|----|---|---|---|-----|
| A | B | C | D |           |   A | B | C | D  | A | B | C | D   |
| 1 | 5 | 2 | 0 | P0        |   0 | 0 | 1 | 2  | 0 | 0 | 1 | 2   |
|            |||| P1        |   1 | 0 | 0 | 0  | 1 | 7 | 5 | 0   |
|            |||| P2        |   1 | 3 | 5 | 4  | 2 | 3 | 5 | 6   |
|            |||| P3        |   0 | 6 | 3 | 2  | 0 | 6 | 5 | 2   |
|            |||| P4        |   0 | 0 | 1 | 4  | 0 | 6 | 5 | 6   |

You can see results in different renderers at BabelMark.

Only MultiMarkdown includes the expected/intended colspans.

screenshot of table code as rendered by MultiMarkdown


For @shog9, this isn't better than the MultiMarkdown, above. It's better to have a non-destructive shortcut for colspans than to use html, I believe. That is, MMD tables are a clean superset of GFM tables.

<thead>
<tr>
    <th colspan="4"> Available </th>
    <th> Process </th>
    <th colspan="4"> Allocation </th>
    <th colspan="4">  Max  </th>
</tr>
</thead>

<tbody>
<tr>
    <td> A </td>
    <td> B </td>
    <td> C </td>
    <td> D </td>
    <td>   </td>
    <td> A </td>
    <td> B </td>
    <td> C </td>
    <td> D </td>
    <td> A </td>
    <td> B </td>
    <td> C </td>
    <td> D </td>
</tr>
<tr>
    <td> 1 </td>
    <td> 5 </td>
    <td> 2 </td>
    <td> 0 </td>
    <td> P0  </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 1 </td>
    <td> 2 </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 1 </td>
    <td> 2 </td>
</tr>
<tr>
    <td colspan="4">   </td>
    <td> P1  </td>
    <td> 1 </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 0 </td>
    <td> 1 </td>
    <td> 7 </td>
    <td> 5 </td>
    <td> 0 </td>
</tr>
<!-- etc etc -->
9
  • 2
    I can't vouch whether this is in scope, but that's pretty cool!
    – zcoop98
    Commented Feb 9, 2021 at 15:56
  • 1
    For now, I don't see us supporting this. We're trying to stick to the CommonMark specification as close as possible and already make an exception with the current GitHub-flavored markdown table syntax because we found it's the syntax with the best support across markdown parsers. As nice as colspan support is, it's not something we can support in good faith any time soon.
    – Ham Vocke StaffMod
    Commented Feb 10, 2021 at 11:05
  • @HamVocke My hope was if you were already adding a non-standard extension to CommonMark you might as well go big so you can prevent the hassle of opening up a settled codebase later. That said, I haven't looked at Penney's source -- a quick glance this morning isn't comforting.
    – ruffin
    Commented Feb 10, 2021 at 13:45
  • 3
    In my experience, the best part about GFM-style tables is that they look pretty nice in the source (or can, at least). Once that's not true anymore, you're better off just using raw HTML - it's more portable and just as unreadable. If SO was gonna support colspan/rowspan, I'd prefer they did so by supporting limited table HTML.
    – Shog9
    Commented Feb 10, 2021 at 15:17
  • @Shog9 I added the start of what the HTML code would be for that table. I realize this is edgy, but that table even as formatted in the MMD is much easier to scan as source than the table html, below. That is, I think I'd rather have this non-destructive "hidden" shortcut (ie, don't use or know about it? No changes to rest of the table format) for colspan than to support html table tags. That is, MMD tables are a clean superset of GFM tables.
    – ruffin
    Commented Feb 10, 2021 at 18:21
  • I agree it remains pretty readable in your example, ruffin; that said, this example is well-suited for it: column heading text is consistently longer than column data. As data length grows, it gets harder and harder to look at the table source and understand what it represents; this is already an issue with even simple GFM tables when, say, an initial column contains lengthy text, as unlike normal Markdown content text cannot be wrapped to a readable length! HTML OTOH does not suffer from this issue, and as content complexity increases the verbose markup becomes less predominate.
    – Shog9
    Commented Feb 10, 2021 at 18:51
  • I think it's interesting here to contrast the Markdown table extensions with something like RST, which... Doesn't much bother with trying to make table sources look like tables, but does try to at least keep them readable and beyond that mostly focuses on ease of authoring (with CSV tables assuming the data is likely coming in from an external source anyway): sublime-and-sphinx-guide.readthedocs.io/en/latest/tables.html For these sites, that could mean recognizing that an awful lot of tabular data is coming from database tooling, CSV exports, or other structured formats.
    – Shog9
    Commented Feb 10, 2021 at 18:55
  • @Shog9 "I agree it remains pretty readable in your example; that said, this example is well-suited for it: column heading text is consistently longer than column data." Agreed. Cell wrapping is a big enough issue I tried to provide a fix by extending MMD tables with "multiline grids" in my app, but even those are quickly a huge pita to format. (I do want to revisit auto whitespace insertion for them tho). I like the table-as-list hack in RST. The limits of human readable text - I just don't know that html table tags are ever much better. /shrug
    – ruffin
    Commented Feb 10, 2021 at 19:29
  • 2
    HTML tables are... Terribly unreadable, even when nicely formatted. Their advantage is simply widespread support: if not explicitly disallowed, they can at least work reliably on every parser. Lacking a clearly better solution for the general case, that at least is something!
    – Shog9
    Commented Feb 10, 2021 at 20:11
2

It is cool! Thx! ;)

I have a question. How will it be combined with the new WYSIWYG editor?

2
  • 2
    Yes, they will be there. Just a wysiwyg table in the post.
    – Qwertiy
    Commented Dec 14, 2020 at 21:05
  • @Qwertiy Thx! ;) Commented Dec 15, 2020 at 11:24
1

All text to the right of a table is ignored.

Column 1 Column 2 Column 3
1.1 1.2 1.3
2.1 2.2 2.3

I am not sure if this was done on purpose. If it is not a bug, adding this caveat in the post would be helpful.

How did I encounter this issue?

I was editing some posts on Stack Overflow with "hardcoded" tables (I don't know what's the term for manually typed tables) to use the new table feature. The posts had some text on the right of some rows. I then noticed after the table was visible in the preview, all that text disappeared.

I then had to do this:

Enter image description here

It was not the only post with such text on the right. IMO, allowing text on the right of tables can be useful sometimes, but it'll leave that to discussion.

1
  • 10
    That's on purpose. We can't really show text next to a table that's not part of the table itself due to the way table syntax is specified and the parser handles things. I can imagine two workarounds: (1) Make the "note" part of an extra column that you specify as part of the table syntax, or (2) highlight the row in question (e.g. in bold or with an asterisk/dagger character) and reference that in a note below the table.
    – Ham Vocke StaffMod
    Commented Jan 6, 2021 at 15:49
1

I just tried table markup in https://electronics.stackexchange.com/a/574832/11684. It worked "OK" in the edit window, giving me a good preview view. However, it screwed up the edit tool, providing me with a misplaced cursor which made data entry screwy and difficult. It also wouldn't work when actually viewing the answer.

I edited out the markup, but you can see it in the edit history. I do have blank headers -- but again, it works in the edit preview. It seems to work here. It did not work there!!

| | | |
|---|---|---|
|Bandwidth |XOUT, YOUT   No external filter| 1600 Hz|
|Bandwidth |ZOUT No external filter |550 Hz|
|RFILT Tolerance| |32 ± 15% kΩ|
|Sensor Resonant Frequency| |5.5 kHz|
Bandwidth XOUT, YOUT No external filter 1600 Hz
Bandwidth ZOUT No external filter 550 Hz
RFILT Tolerance 32 ± 15% kΩ
Sensor Resonant Frequency 5.5 kHz
7
  • You need an empty line to separate the table from the preceding text. See this answer for a demo.
    – 41686d6564
    Commented Jul 9, 2021 at 18:52
  • 1
    @41686d6564 -- thanks. It's odd that the preview worked, though! If that can be duplicated, I'd call that a bug. Commented Jul 9, 2021 at 19:05
  • The weird effects in the edit window, where the cursor was a character behind the active entry, was also odd. Commented Jul 9, 2021 at 19:06
  • 3
    You are right about the bug with the preview working but not rendering correctly after saving. I already reported that bug as an answer on this question here: meta.stackexchange.com/questions/356997/… Commented Jul 9, 2021 at 19:14
  • 1
    Could you clarify what you mean by the misplaced cursor? I'm having trouble understanding. Perhaps you could add steps to reproduce and/or screenshots? Commented Jul 9, 2021 at 19:20
  • My cursor would not go to the end of the line. It was one character to the left, the any additions or edits were on the character to the right of the cursor. Commented Jul 10, 2021 at 0:15
  • ah I see what you mean. I'm not able to reproduce that issue. But it sounds like something triggered right-to-left text editing as some languages are typed from right to left. Commented Jul 10, 2021 at 5:12
1

Here is a table: | A header | Another header | | -------- | -------------- | | First | row | | Second | row | I see it in edit mode, but as soon as you submit the text, it doesn't appear on screen. You just see the raw code.

Please try it: Edit my posting (enter the edit mode but please don't change my content) and you will see the table. Leave the edit mode and the table vanishes.

7
  • 2
    This is nothing new. Has been reported dozens of times before. The preview renderer is off, you should add white space in front of your table.
    – Luuklag
    Commented Apr 13, 2022 at 7:51
  • 1
    @Luuklag dozens? Not really. This is the "main" bug report about it. :) Commented Apr 13, 2022 at 7:54
  • How can it happen, that the code works in edit mode but not in the final result? This should not be in a wysiwyg editor because you don't get what you see. Commented Apr 13, 2022 at 7:55
  • 1
    Because, for whatever reason, server-side (live post) and client-side (preview) renderer are two separate things.
    – Luuklag
    Commented Apr 13, 2022 at 8:10
  • @ShadowWizardSaysNoMoreWar, see how many linked questions there are there, that doesn't include all deleted posts or duplicate answers in this post.
    – Luuklag
    Commented Apr 13, 2022 at 8:11
  • An empty line after the table is sufficient. For symmetry, use an empty line before the table as well. Commented Apr 13, 2022 at 11:05
  • @Luuklag: Yes, it is very obvious that server-side (live post) and client-side (preview) renderer behave differently. - Do you think this good? Or at least acceptable? I don't think so. I think having two renderers that behave differently is a very bad idea. I think they should behave exactly identically. And I think there should be test cases in stackexchange's text environment that shall be used to ensure, that both renderers always behave identically after every single change that is going to be rolled out. Commented Apr 14, 2022 at 13:55
0

Inline code in backticks is processed correctly in cells.
Inline code in <code> messes the columns if it happens to contain the | character.


Rendered correctly:

| One | Two |
| - | - |
| `1|2|3` | `4|5|6` |
One Two
1|2|3 4|5|6

Not rendered correctly:

| One | Two |
| - | - |
| <code>1|2|3</code> | <code>4|5|6</code> |
One Two
1 2 4 6

And looks different in preview too:

enter image description here

8
  • 1
    So you want them to fix what is specifically un-supported? (html in posts)
    – Luuklag
    Commented May 5, 2022 at 7:53
  • 2
    @Luuklag It not only tells you that <code> is supported, but even puts it in a markdown table.
    – GSerg
    Commented May 5, 2022 at 7:56
  • You should read a bit further down after the table: Are HTML comments supported? Yes and no. While they (often) do work in the way you specify, that's not because they're officially supported by the system; they just happen to get removed as invalid HTML. Technically speaking, only the above comments to specify a highlighting language for code blocks or the entire post are supported.
    – Luuklag
    Commented May 5, 2022 at 8:02
  • 1
    @Luuklag What HTML comments (<!-- this is a comment -->) have to do with it?
    – GSerg
    Commented May 5, 2022 at 8:06
  • Those are the only truly supported pieces of HTML. All other HTML just works because it does. SE interpretes markdown into HTML, renders that, and stores the rendered HTML in the post table. The language hits <!-- lang-html --> for example are supported as a way to indicate to markdown what language is to be used to interprete a code block. Other then that no HTML is officially supported, it works when it works, and it doesn't when it doesn't. You could simply use the backticks as you indicate yourself.
    – Luuklag
    Commented May 5, 2022 at 8:16
  • 2
    @Luuklag What are "those" that are "truly supported"? The allowed HTML codes? <code> is one of them like your very link explains, and has been "truly supported" for ages, probably from the beginning of SO. Which has limited relevance here because "HTML in markdown tables" may be different to "HTML in post bodies" which your link discusses. The relevant information about <code> in tables is just above and is ambiguous: "inline code" is explicitly supported in tables (which <code> is), but HTML isn't (which <code> is).
    – GSerg
    Commented May 5, 2022 at 8:29
  • inline code that is markdown formatted is indeed supported.
    – Luuklag
    Commented May 5, 2022 at 8:40
  • @Luuklag All the HTML tags listed in the table are explicitly supported. The “Are HTML comments supported?” section only explains that HTML comments are officially unsupported (except the language hints using comment-like syntax). Furthermore, there is no way to have unsupported HTML tags that just happen to work, as the renderer mercilessly removes anything that looks like a tag unless it actively recognizes it as allowed. Commented May 5, 2022 at 13:53
-4

Add ability to convert the image of a table into Markdown.

E.g., an image of a table =

Enter image description here

Markdown =

| 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

Motivation of my request: one of my answers, containing the image of a table, got downvoted a few times because people wanted the Markdown version instead. The conversion is quite easy to do with OCR + table recognition for simple tables.

5
  • 1
    tag wiki for status-deferred says it can only be applied by moderators and developers. Commented Dec 30, 2020 at 21:47
  • @KodosJohnson thank you, sorry I mistakenly added it. Commented Dec 30, 2020 at 21:50
  • 14
    Honestly not sure how we could ever do this. It'd require a very complicated image recognition system that we simply don't have.
    – Catija
    Commented Dec 30, 2020 at 23:17
  • 1
    If this is as simple as you suggest, you're best served by providing a light-weight, open source solution they can just plug and play. Makes for an easier pitch internally if you do a little of that leg work for them.
    – canon
    Commented Jan 13, 2021 at 19:45
  • @Catija there's a free API, which is worth investigating, if SE will decide such a feature is helpful enough. Commented Feb 9, 2021 at 16:13
1
2

You must log in to answer this question.

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