Convert HTTP header overview tables to Markdown tables

[teoli2003]

We are in the process of migrating HTTP to Markdown (#7536 and #7853). Tables in MD are less flexible than in HTML.

In particular, these kinds of tables can't be translated in MD, as they don't have a header row:

As they are common, we would like to convert them to Markdown.

I see the following alternatives:

1. Add a header to them, and convert them. E.g.

Or we keep the same look and feel, by generating it using a macro. Here the question is really: Where do we store the information?

2. We can add a key in frontrunner and the macro uses it to retrieve it from structured data (where to store it?),
3. Or we can up to 4 entries in frontrunner to store the data directly in the file, and create a macro {{HTTPHeaderOverview}} that reads the data from there.

cc-ing a few people that had opinions in the past on this kind of questions: @Rumyra @sideshowbarker @peterbe @Elchi3 @wbamberg @hamishwillee (but feel free to chime in anyway)

MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTTP

[wbamberg]

There are always going to be tables in MDN that need to stay as HTML for one reason or another. So if we're considering using a macro only to "keep the same look and feel"[1] as the current tables, we can achieve the same effect by just keeping it as HTML.

The real benefit of generating tables from data is that authors don't have to be concerned with the presentation of it, and the data is potentially readable by other applications (as for BCD).

About whether to use front matter or refer to another source, I think:

• If MDN authors are maintaining this data themselves, and it is reasonably concise (unlike BCD, say) I favour keeping it in front matter. I think it's easier for authors to maintain it if it lives in the same place as the main content.

• If there's another data source that we can use that's reliably maintained and closer to the specs (like webref) we should use that.

Sometimes representing this stuff as data is hard though. In this case I worry about the value of "CORS-safelisted request header". I don't know this content at all really, but if there are lots of possible values for this item, then things get ugly. We have this situation in the CSS data in mdn/data, with "Applies to": there are IIRC about 330 different values for this item, some of which get names like allElementsExceptInlineBoxesAndInternalRubyOrTableBoxes. This seems really hard for authors to work with. I don't have a good answer to this.

[1] If "look and feel" refers to structural features of the tables, like having a header col, then fair enough, it is a Markdown-relevant issue, but if it refers to the styles, we should ask "if the .properties style nicer than the default style, why not make all tables get the .properties style by default"?

[teoli2003]

As:

• we don't have an external canonical source for this data,
• and I don't know of another usage for this data but in this article,

I'm leaning towards a solution inside the article.

As you said, creating a macro doesn't bring much and there are drawbacks (it makes it cumbersome to edit), I think 1. is leading right now.

[Josh-Cena]

It has been three years and it seems nothing will be done. We have many HTML tables in MDN and it doesn't seem very beneficial to convert them to MD (e.g. HTML technical summaries, learning prerequisites...). Instead of keeping it open, I'm going to close it until next time someone feels strongly enough (and it should be in the discussions repo).