Wow! this is a huge PR and at first glance it's pretty fantastic. Thanks a lot @MartijnCuppens

I'll make sure to find time this week to review it.

Thanks @andresgalante!

Yeah, I was working on a solution to prevent styles from leaking to nested tables, but this code also influenced the the theming of coloured tables. Before I knew it I was rewriting a lot. The only thing I kept my hands of was the responsive tables (because of #25813).

I think a rewrite like this is needed to make the bootstrap tables more consistent but if you have some improvement suggestions, let me know!

I am concerned about this increase many CSS.

Current:

.table td,
.table th {
  ...
}

After:

.table > thead > tr > td,
.table > thead > tr > th,
.table > tbody > tr > td,
.table > tbody > tr > th,
.table > tfoot > tr > td,
.table > tfoot > tr > th {
  ...
}

@mdo and many people may not like a universal selector for performance reason, but it is effective in this case?

.table > * > * > td,
.table > * > * > th {
  ...
}

This PR actually decreases the file size of the css files because of the flexible implementation of the coloured tables.

But indeed, using the universal selector would decrease the file size even more (I would keep the tr though). Not sure if there is much of a difference in performance because we still use the child combinator (>) and we're actually decreasing the number of selectors.

Some bundlesize stats:

v4 dev (June 14):
./dist/css/bootstrap.css: 22.19KB < maxSize 25KB gzip
./dist/css/bootstrap.min.css: 20.58KB < maxSize 21KB gzip

PR without universal selector:
./dist/css/bootstrap.css: 22.06KB < maxSize 25KB gzip
./dist/css/bootstrap.min.css: 20.45KB < maxSize 21KB gzip

PR with universal selector:
./dist/css/bootstrap.css: 21.98KB < maxSize 25KB gzip
./dist/css/bootstrap.min.css: 20.38KB < maxSize 21KB gzip

About the universal selector usage:
I'm quite sure there won't be a a performance drawback if we use this, on the contrary
we might even have a performance improvement. Browsers read selectors from right to left and the child combinator (>) is always used.

Let's analyse this case:

.table > thead > tr > td,
.table > thead > tr > th,
.table > tbody > tr > td,
.table > tbody > tr > th,
.table > tfoot > tr > td,
.table > tfoot > tr > th {
  ...
}

For the first line, the browser searches for all td elements and then checks if the parent is a tr, checks if the tr has a thead parent and checks if the thead has a .table parent. This happens analogously for all 6 lines.

This case:

.table > * > tr > td,
.table > * > tr > th {
  ...
}

For the first line, the browser searches for all td elements and then checks if the parent is a tr, checks if the tr has a parent and checks if that element has a .table parent. This happens analogously for the next line. This actually sounds like an improvement.

Original case:

.table td,
.table th {
  ...
}

For the first line, the browser searches for all td elements and then checks if the parent or a grandparent (not sure if this is the correct term) is a .table. This happens analogously for the next lines. The performance of this might be comparable to the universal selector implementation.

Source: https://www.youtube.com/watch?v=2Rn8an74khk&feature=youtu.be&t=14m28s

I just changed my PR and used the universal selector.

@mdo, do you want me to remove the child combinator (>) only from the .table or also from .table-sm, .table-bordered, .table-hover,…?

@mdo, you're right, this would mean every developer would need to add the .table class to nested tables if they want to update Bootstrap, so I changed the selectors for .table but kept it (for the time being) for .table-sm, .table-bordered, .table-borderless, .table-striped and .table-hover.

For .table-sm, I could understand why we would leak the padding. But for .table-bordered & .table-borderless, there is a problem. We can't add a bordered table inside a borderless table, because .table-borderless overwrites the bordered styling if we don't work with the child combinator (this might be an edge case).

Nested .table-hover may also look weird and this styling can not easily be overwritten. Same for nested .table-striped.

What do you think?

Closing for now given conflicts and upcoming changes to v5. Opened #28480 to revisit for our next major release.