[GH-ISSUE #1818] Proposal: Update MD060/table-column-style to allow exempting violations for the last column

kerem commented

2026-03-07 20:09:14 +03:00

Owner

Originally created by @Ravlen on GitHub (Oct 17, 2025).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1818

I'd like to propose an extra parameter for MD060, which is something we already implement in our docs through https://marketplace.visualstudio.com/items?itemName=fcrespo82.markdown-table-formatter:

That formatting extension has the limitLastColumnLength setting, with an option called: Follow header row length, and the description is: Do not extend last column to more than the table's header row.

Essentially, what it means is "Align all columns except the last column":

Before:

| App name   | Default status | Requirements                                                                                                                 |
|------------|----------------|------------------------------------------------------------------------------------------------------------------------------|
| App one    | Enabled        | None                                                                                                                         |
| App ten    | Disabled       | Use on Thursdays                                                                                                             |
| App twenty | Enabled        | If you are going to use this application, ensure you have fulfilled the prerequisites and can no longer use any other option |

After

| App name   | Default status | Requirements |
|------------|----------------|--------------|
| App one    | Enabled        | None         |
| App ten    | Disabled       | Use on Thursdays |
| App twenty | Enabled        | If you are going to use this application, ensure you have fulfilled the prerequisites and can no longer use any other option |

This is a very common formatting issue with Markdown tables, as we often put descriptions, requirements, etc in the last column and they can vary drastically in length, causing a huge amount of additional padding.

It would be great if we could add one more parameter to the existing aligned / any / compact / tight. Maybe aligned-compact? Which aligns all columns, except the last which uses 1 space if it's longer than the header row?

Originally created by @Ravlen on GitHub (Oct 17, 2025). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1818 I'd like to propose an extra parameter for MD060, which is something we already implement in our docs through https://marketplace.visualstudio.com/items?itemName=fcrespo82.markdown-table-formatter: That formatting extension has the `limitLastColumnLength` setting, with an option called: `Follow header row length`, and the description is: `Do not extend last column to more than the table's header row`. Essentially, what it means is "Align all columns except the last column": Before: ```md | App name | Default status | Requirements | |------------|----------------|------------------------------------------------------------------------------------------------------------------------------| | App one | Enabled | None | | App ten | Disabled | Use on Thursdays | | App twenty | Enabled | If you are going to use this application, ensure you have fulfilled the prerequisites and can no longer use any other option | ``` After ``` | App name | Default status | Requirements | |------------|----------------|--------------| | App one | Enabled | None | | App ten | Disabled | Use on Thursdays | | App twenty | Enabled | If you are going to use this application, ensure you have fulfilled the prerequisites and can no longer use any other option | ``` This is a very common formatting issue with Markdown tables, as we often put descriptions, requirements, etc in the last column and they can vary drastically in length, causing a huge amount of additional padding. It would be great if we could add one more parameter to the existing `aligned` / `any` / `compact` / `tight`. Maybe `aligned-compact`? Which aligns all columns, except the last which uses 1 space if it's longer than the header row?

kerem added the

enhancement

label

2026-03-07 20:09:14 +03:00

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 17, 2025):

I understand the issue and I considered something like this with the initial implementation. However, looking around for examples, it was pretty easy to find cases where it wasn't just the last column that needed special treatment. Sometimes it was the last two columns or maybe the first column has really long names sometimes. It didn't seem that there was a broadly applicable pattern, though I expect the last column is the most popular exceptional column as you show above.

@DavidAnson commented on GitHub (Oct 17, 2025): I understand the issue and I considered something like this with the initial implementation. However, looking around for examples, it was pretty easy to find cases where it wasn't just the last column that needed special treatment. Sometimes it was the last two columns or maybe the first column has really long names sometimes. It didn't seem that there was a broadly applicable pattern, though I expect the last column is the most popular exceptional column as you show above.

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 17, 2025):

Another issue (which I capture here largely for my own benefit now that I'm thinking about this again) is that rule configuration is done per project (or in extreme conditions per file) and there's nothing to say that every table in the project wants or needs its last column handled uniquely.

It would be ideal to be able to infer the need for this on a case-by-case basis. And although it might be straightforward to detect a table using this pattern and not report an issue for it, it may be difficult to detect a table NOT using this pattern that just happens to have a weird last column, etc. and recommending how to fix it could also be iffy.

@DavidAnson commented on GitHub (Oct 17, 2025): Another issue (which I capture here largely for my own benefit now that I'm thinking about this again) is that rule configuration is done per project (or in extreme conditions per file) and there's nothing to say that every table in the project wants or needs its last column handled uniquely. It would be ideal to be able to infer the need for this on a case-by-case basis. And although it might be straightforward to detect a table using this pattern and not report an issue for it, it may be difficult to detect a table NOT using this pattern that just happens to have a weird last column, etc. and recommending how to fix it could also be iffy.

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@Ravlen commented on GitHub (Oct 20, 2025):

@DavidAnson Hrm, I feel there's not much you can do if an internal column needs special treatment, either all columns are aligned, or not. If an internal column requires special treatment, everything else to the right of it would likely get misaligned if you didn't just do the whole table?

Thinking a bit more about it too, perhaps I should have called it a "less-padding" or "tight-padding" option, rather than alignment. Because all "internal" pipe characters are still aligned, it's just checking if there's extra padding at the end. This sort of matches the "no external pipes" or "open" format (I'm not sure what it's called). But if you use that format, you omit the leading and trailing pipes, which also means at no point is padding used in the last cell. So my idea would be to do the same, but with the outer pipes.

"open" style of a table I was looking at recently, auto-formatted by any formatting tool always gives this, with no padding in any row in the last column:

Tool       | Language | Command        | Regex pattern 
-----------|----------|----------------|---------------
pytest-cov | Python   | `pytest --cov` | `/TOTAL.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` 
Simplecov  | Ruby     | `rspec spec`   | `/\(\d+.\d+\%\) covered/`

Same table, but with the "tight-padding" style. Same as above, but with the pipes.

| Tool       | Language | Command        | Regex pattern |
|------------|----------|----------------|---------------|
| pytest-cov | Python   | `pytest --cov` | `/TOTAL.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` |
| Simplecov  | Ruby     | `rspec spec`   | `/\(\d+.\d+\%\) covered/` |

So perhaps adjust the proposal to be about limiting end-column padding?

@Ravlen commented on GitHub (Oct 20, 2025): @DavidAnson Hrm, I feel there's not much you can do if an internal column needs special treatment, either all columns are aligned, or not. If an internal column requires special treatment, everything else to the right of it would likely get misaligned if you didn't just do the whole table? Thinking a bit more about it too, perhaps I should have called it a "less-padding" or "tight-padding" option, rather than alignment. Because all "internal" pipe characters are still aligned, it's just checking if there's extra padding at the end. This sort of matches the "no external pipes" or "open" format (I'm not sure what it's called). But if you use that format, you omit the leading and trailing pipes, which also means at no point is padding used in the last cell. So my idea would be to do the same, but _with_ the outer pipes. - "open" style of a table I was looking at recently, auto-formatted by any formatting tool always gives this, with no padding in any row in the last column: ```md Tool | Language | Command | Regex pattern -----------|----------|----------------|--------------- pytest-cov | Python | `pytest --cov` | `/TOTAL.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` Simplecov | Ruby | `rspec spec` | `/$\d+.\d+\%$ covered/` ``` - Same table, but with the "tight-padding" style. Same as above, but with the pipes. ```md | Tool | Language | Command | Regex pattern | |------------|----------|----------------|---------------| | pytest-cov | Python | `pytest --cov` | `/TOTAL.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` | | Simplecov | Ruby | `rspec spec` | `/$\d+.\d+\%$ covered/` | ``` So perhaps adjust the proposal to be about limiting end-column padding?

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 20, 2025):

This framing seems helpful, thanks! I'm still not sure I see how to distinguish your original example from being deliberate in your style vs. incorrect in the fully aligned style, so this capability seems to need to be an additional property on the rule that says something like "relaxed last column" (as you propose).

If the right-most cell of an aligned table with end pipes is longer than expected, require that cell to have the compact style instead.

I'll need to experiment with this to see if there are unexpected implications, but it seems like it might do the trick.

@DavidAnson commented on GitHub (Oct 20, 2025): This framing seems helpful, thanks! I'm still not sure I see how to distinguish your original example from being deliberate in your style vs. incorrect in the fully aligned style, so this capability seems to need to be an additional property on the rule that says something like "relaxed last column" (as you propose). > If the right-most cell of an aligned table with end pipes is longer than expected, require that cell to have the compact style instead. I'll need to experiment with this to see if there are unexpected implications, but it seems like it might do the trick.

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@DavidAnson commented on GitHub (Dec 4, 2025):

FYI, I came back to this issue recently with the intent to fix it, but couldn't come up with an approach I liked after a couple of days thought. One challenge is that if you want to allow the compact single-space format for the last column, you should also allow the tight style, so this option is more than a boolean. And per my comments earlier, it needs to be opt-in. Also, whatever it is should make sense (or at least not be silly) for people using compact or tight for the entire table.

But even after sorting those questions out, it's unclear what to do with something like the following:

| Heading | Heading |
| ------- | ------- |
| Text    | Text    |
| Text    | Text text text text      |
| Text    | Text text text text text |

Does anyone really want to argue the second-to-last line should be reported as a violation? What's shown above seems truer to the aligned style than if the two long lines both ended compact. And surely the following table has a violation even though the proposed changes to this rule would not report one:

| Heading | Heading                 |
| ------- | ----------------------- |
| Text    | Text                    |
| Text    | Text text text text text |

Instead of jumping through hoops here, I feel like it makes sense for tables with funky last columns to simply delete the trailing pipe (and optionally the leading one) which leads to the following approach which is ALREADY valid today:

| Heading | Heading | Heading
| ------- | ------- | -------
| Text    | Text    | Text
| Text    | Text    | Text text text text
| Text    | Text    | Text text text text text

@DavidAnson commented on GitHub (Dec 4, 2025): FYI, I came back to this issue recently with the intent to fix it, but couldn't come up with an approach I liked after a couple of days thought. One challenge is that if you want to allow the `compact` single-space format for the last column, you should also allow the `tight` style, so this option is more than a `boolean`. And per my comments earlier, it needs to be opt-in. Also, whatever it is should make sense (or at least not be silly) for people using `compact` or `tight` for the entire table. But even after sorting those questions out, it's unclear what to do with something like the following: ```markdown | Heading | Heading | | ------- | ------- | | Text | Text | | Text | Text text text text | | Text | Text text text text text | ``` Does anyone really want to argue the second-to-last line should be reported as a violation? What's shown above seems truer to the `aligned` style than if the two long lines both ended `compact`. And surely the following table has a violation even though the proposed changes to this rule would not report one: ```markdown | Heading | Heading | | ------- | ----------------------- | | Text | Text | | Text | Text text text text text | ``` Instead of jumping through hoops here, I feel like it makes sense for tables with funky last columns to simply delete the trailing pipe (and optionally the leading one) which leads to the following approach which is ALREADY valid today: ```markdown | Heading | Heading | Heading | ------- | ------- | ------- | Text | Text | Text | Text | Text | Text text text text | Text | Text | Text text text text text ```

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@DavidAnson commented on GitHub (Dec 4, 2025):

/cc @trentm and @yuluo-yx

@DavidAnson commented on GitHub (Dec 4, 2025): /cc @trentm and @yuluo-yx

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@Ravlen commented on GitHub (Dec 15, 2025):

@DavidAnson Oh yes, I didn't think it would work as a boolean, it would have to be a completely separate parameter. Based on the current ones, the most similar is aligned, but with the last column unpadded. So something like aligned-except-last might give a good hint as to what it does.

couldn't come up with an approach I liked after a couple of days thought

Yeah, I've got ideas, but I got no skills 😓 I can't offer up any programming solutions, but in my mind the pseudocode/logic check would be like:

Check that all columns are aligned except the last.
Check the last cell of the header, throw violation if it has extra spaces.
Count the number of characters in header row (all chars, to last pipe), minus any extra spaces in the last cell.
- If any row is longer than the header count, throw violation if the last pipe is preceded by more than one space. If only one space, then pass.
- If any row is shorter than the header count, throw violation.
- If any row is the exact same length as the header count, then pass.

Regarding the three examples:

In the first two examples I'd call those both very minor issues, but violations of the rule nonetheless (to maintain consistency). To me it's the same as most other consistency markdownlint rules, like ordered list numbering. Either do it everywhere, or don't use markdownlint/the rule.

And yes, you are absolutely right that the third example is a sensible workaround. But I think people prefer to have everything enclosed in pipes. It feels unbalanced otherwise.

@Ravlen commented on GitHub (Dec 15, 2025): @DavidAnson Oh yes, I didn't think it would work as a boolean, it would have to be a completely separate parameter. Based on the current ones, the most similar is `aligned`, but with the last column unpadded. So something like `aligned-except-last` might give a good hint as to what it does. > couldn't come up with an approach I liked after a couple of days thought Yeah, I've got ideas, but I got no skills 😓 I can't offer up any programming solutions, but in my mind the pseudocode/logic check would be like: - Check that all columns are aligned _except_ the last. - Check the last cell of the header, throw violation if it has extra spaces. - Count the number of characters in header row (all chars, to last pipe), minus any extra spaces in the last cell. - If any row is longer than the header count, throw violation if the last pipe is preceded by more than one space. If only one space, then pass. - If any row is shorter than the header count, throw violation. - If any row is the exact same length as the header count, then pass. Regarding the three examples: In the first two examples I'd call those both _very_ minor issues, but violations of the rule nonetheless (to maintain consistency). To me it's the same as most other consistency markdownlint rules, like ordered list numbering. Either do it everywhere, or don't use markdownlint/the rule. And yes, you are absolutely right that the third example is a sensible workaround. But I think people prefer to have everything enclosed in pipes. It feels unbalanced otherwise.

kerem commented

2026-03-07 20:09:15 +03:00

Author

Owner

@trentm commented on GitHub (Feb 10, 2026):

Sorry for not ever having gotten back on this.

I feel like it makes sense for tables with funky last columns to simply delete the trailing pipe (and optionally the leading one) which leads to the following approach which is ALREADY valid today:

I don't hate this as answer. :)
I ran into this recently, and when I tried to delete the trailing pipe, I fell afowl of MD055:

experimental/packages/opentelemetry-instrumentation-http/README.md:90:265 error MD055/table-pipe-style Table pipe style [Expected: leading_only; Actual: leading_and_trailing; Unexpected trailing pipe]
experimental/packages/opentelemetry-instrumentation-http/README.md:91:265 error MD055/table-pipe-style Table pipe style [Expected: leading_only; Actual: leading_and_trailing; Unexpected trailing pipe]
experimental/packages/opentelemetry-instrumentation-http/README.md:92:265 error MD055/table-pipe-style Table pipe style [Expected: leading_only; Actual: leading_and_trailing; Unexpected trailing pipe]
...

because there was another table in the same file. This required me to change all tables in the same file to the same consistent table-pipe-style. My other option was to disable MD055 I guess.

@trentm commented on GitHub (Feb 10, 2026): Sorry for not ever having gotten back on this. > I feel like it makes sense for tables with funky last columns to simply delete the trailing pipe (and optionally the leading one) which leads to the following approach which is ALREADY valid today: I don't hate this as answer. :) I ran into this recently, and when I tried to delete the trailing pipe, I fell afowl of MD055: ``` experimental/packages/opentelemetry-instrumentation-http/README.md:90:265 error MD055/table-pipe-style Table pipe style [Expected: leading_only; Actual: leading_and_trailing; Unexpected trailing pipe] experimental/packages/opentelemetry-instrumentation-http/README.md:91:265 error MD055/table-pipe-style Table pipe style [Expected: leading_only; Actual: leading_and_trailing; Unexpected trailing pipe] experimental/packages/opentelemetry-instrumentation-http/README.md:92:265 error MD055/table-pipe-style Table pipe style [Expected: leading_only; Actual: leading_and_trailing; Unexpected trailing pipe] ... ``` because there was another table in the same file. This required me to change all tables in the same file to the same consistent table-pipe-style. My other option was to disable MD055 I guess.

Rows
Columns

[GH-ISSUE #1818] Proposal: Update MD060/table-column-style to allow exempting violations for the last column #2600