HTTP semantic convention table is too wide

[Oberon00]

See https://github.com/open-telemetry/opentelemetry-specification/blob/821118e5/specification/trace/semantic_conventions/http.md#common-attributes

The table is cut off at the right side on my 1920x1080 screen and you have to awkwardly scroll by selecting. The culprits seem to be the http.response_content_length_uncompressed and http.request_content_length_uncompressed attributes which have really long names.

...

[arminru]

Are you sure this warrants being labeled a bug? It's more a visual/UX nuisance in my opinion.
It's rather a bug that Github is only using half of the available screen width even if there are wider tables 😉
Any suggestion on how we could make it fit without having to rename the attribute?

[Oberon00]

Since we have no separate label for "minor nitpick", "bug" is the closest thing. The urgency/importance part should be covered by the "after-ga" label.

[Oberon00]

Maybe we could leave out the prefix for such attributes, but just response_content_length_uncompressed would likely still cause a scrollbar.

Another solution would be to not use a table, but an enumeration like:

• http.request_content_length_uncompressed (optional number): Brief brief.

  Note note note (no footnote-splitout required).

  Examples: 5493

An alternative would be to always move the examples to the footnote, or integrate them in the description column.

CC @thisthat

[arminru]

@Oberon00 It would not only cause a scrollbar but also confusion if the prefix is left out only for some attributes (or suddenly for all of them). A list should work, yes.
I, personally, however, am fine with the current tables (even if one has to scroll on this particular one when viewing it on the Github website).

[arminru]

@Oberon00 is this still an issue now that the table is rendered in a different manner in the new repo?

https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md#common-attributes

[Oberon00]

This particular table seems fine. Closing this in favor of #1925