Content: Source specification section from BCD; improve rendering

[Elchi3]

Over on BCD we've introduced spec_url:

The spec_url property is a URL or an array of URLs, each of which is for a specific part of a specification in which this feature is defined. Each URL must contain a fragment identifier (e.g. https://tc39.es/proposal-promise-allSettled/#sec-promise.allsettled).

It is populated for all javascript.* features and we're working on populating it for html.* features. At some point all BCD features will have a spec_url property.

Further, the spec_url data in BCD is carefully reviewed and we make sure it actually contains relevant specs and not abandoned or outdated ones.

Therefore, I think the "Specifications" section on MDN pages should use this information to render a specification table (or specification section as opposed to a table as recommended by @nschonni in https://github.com/mdn/content/pull/1121#discussion_r554464075. That way we no longer need to maintain it in two places.

cc'ing @sideshowbarker with whom I worked on this a lot.

[chrisdavidmills]

Totally 100% on board with this @Elchi3 ! Let's move forward with a porposal for what the table should look like exactly that we can comment and interate on, and then once we are agreed, let's create lists of pages to migrate over the spec tables to BCD and then replace with a macro call, and get the community to help with the migration, like we did with the original compat table migration project ;-)

/me Excited.

[Elchi3]

@hamishwillee has great feedback about this proposal:

including spec info in the BCD looks great; though of course there are a whole bunch of things that aren't and never will be in BCD that are still relevant to docs (and in particular this is true of HTTP headers where the definition of "supported" is unclear).

Imo, this is something to keep in mind but "making sense of support info for HTTP" is a BCD/MDN issue that exists whether we move forward with this spec_url proposal or not, so it is not really blocking.

[Ryuno-Ki]

Let's move forward with a porposal for what the table should look like exactly that we can comment and interate on

Sounds like a design ticket (linking to this one)

and then once we are agreed, let's create lists of pages to migrate over the spec tables to BCD

A second issue?

and then replace with a macro call, and get the community to help with the migration, like we did with the original compat table migration project ;-)

A third one? Or perhaps a blog article on Mozilla Hacks?

This issue here could serve as a meta issue then?

[hamishwillee]

@Elchi3 Re https://github.com/mdn/content/issues/1146#issuecomment-763492997 - agree, non blocking.

Not really a discussion for here, but if we're going to include spec info I start to think that the BCD should be broader than just things where highlighting compatibility makes sense. For example, I'd like to have all those missing HTTP headers so that I also get the spec info, and so that I can have an explicit place in BCD where I show that the omission of the compatibility info is deliberate.