This is the respective issue as https://www.drupal.org/project/drupal/issues/80855 for D8, which introduced a new '#type' => 'table'
form element in the core Form API (change record: https://www.drupal.org/node/1876710). It comes with built-in, optional support for TableDrag and TableSelect, and it requires no more custom plumbing for most use-cases.
Building and rendering a table required to write a custom/dedicated theme function for most tables in Drupal 7. TableSelect (bulk operations) and TableDrag (drag & drop) support had to be added and attached manually when necessary. This led to many duplicate/unnecessary theme functions, which in turn made it hard for other modules to enhance or alter a table.
This was suggested to be backported to D7, but was rejected, with the recommendation to implement it in contrib (in https://drupal.org/project/elements specifically). Someone backported the D8 version to a dedicated contrib in https://www.drupal.org/project/table_element (only 300 lines of code in a single .module file; including comments: https://git.drupalcode.org/project/table_element/-/blob/7.x-1.x/table_el...).
PS: if we decide to do this, then this d.org issue is also related, and we should create a separate meta-issue for it, to convert all tables in core to the new '#type' => 'table'
: https://www.drupal.org/project/drupal/issues/1876712
Recent comments
In page.tpl.php you can get the current path and add it to the class array $classes[] = 'path-' . str_replace('/', '', $_SERVER['REQUEST_URI']); You will get an original class for each page....
Insert custom class into body tag
https://www.drupal.org/project/views/issues/1266388 shows that this is an architectural issue, and requires another 2 hooks being adjusted. It would be really nice to add comments/notes to...
node access
Hmmm, from D7 ancient tomes: from https://drupal.stackexchange.com/questions/7056/limit-which-roles-can-view-a-node-basing-on-its-content-type yet https://docs.backdropcms.org/api/...
node access