Timeline for New Feature: Table Support
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 12, 2023 at 22:52 | history | edited | philipxy | CC BY-SA 4.0 |
expanded & changed example to specific/original version rather than current
|
| Apr 6, 2021 at 14:00 | comment | added | philipxy | @HamVocke My suggestion & motivation are clear. "At the very least please". "Unfortunately". Adding more work for curators is a problem, not a solution. | |
| Feb 1, 2021 at 20:10 | comment | added | kjetil b halvorsen | 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! | |
| Dec 9, 2020 at 9:44 | comment | added | Ham Vocke StaffMod | @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? | |
| Dec 9, 2020 at 8:18 | comment | added | philipxy | @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?) | |
| Dec 9, 2020 at 8:02 | comment | added | Ham Vocke StaffMod |
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.
|
|
| Dec 9, 2020 at 5:40 | history | edited | philipxy | CC BY-SA 4.0 |
added link to table format abuse
|
| Dec 2, 2020 at 20:29 | comment | added | philipxy | @TylerH It happens all the time. Use of images instead of text exemplifies how tables will be similarly misused. | |
| Dec 2, 2020 at 20:22 | comment | added | TylerH | 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. | |
| Dec 2, 2020 at 20:13 | comment | added | TylerH | 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. | |
| Dec 2, 2020 at 19:53 | comment | added | philipxy | @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. | |
| Dec 2, 2020 at 19:29 | comment | added | TylerH | 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. | |
| Dec 2, 2020 at 19:23 | comment | added | philipxy | @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. | |
| Dec 2, 2020 at 2:27 | comment | added | TylerH | 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. | |
| Dec 1, 2020 at 21:59 | history | edited | philipxy | CC BY-SA 4.0 |
continued previous edit
|
| Dec 1, 2020 at 20:19 | history | edited | philipxy | CC BY-SA 4.0 |
incorporated desired suggestions from someone's suggested edit
|
| Dec 1, 2020 at 20:08 | history | rollback | philipxy |
Rollback to Revision 1 - restored my intent. the only change that I agree with is changing &s to ands.
|
|
| S Dec 1, 2020 at 19:18 | history | suggested | shreyasm-dev | CC BY-SA 4.0 |
Improved grammar and formatting
|
| Dec 1, 2020 at 18:29 | review | Suggested edits | |||
| S Dec 1, 2020 at 19:18 | |||||
| Dec 1, 2020 at 17:38 | history | answered | philipxy | CC BY-SA 4.0 |