If you have a view using the views-view-table.html.twig template, with some fields/columns set to display default classes and others not ("Add default classes" checked or not under Style Settings), any field/column that is not meant to get default classes will instead get the default classes of the last field/column to be rendered before it that does have "Add default classes" checked. This is because the column_classes Twig variable is not reset on every iteration through the column loop, but only for those columns where "Add default classes" was checked.
Any of the no-default-classes fields ("columns" in the template) that follow a field that is set to display default classes will be found to have the same classes as that previous field. If multiple no-default-classes columns appear in sequence, they all will get the same classes as the last field with default classes rendered before them.
The column_classes variable should be reset on each loop through the row columns. As it is now, the variable is only "reset" on those iterations where default_classes is set.
There are two ways this could be done. I'll leave it to the experts to determine which ways is better:
{% for key, column in row.columns %}) with {% set column_classes = [] %}. This is the simplest option at only one new line of code, but it is slightly redundant for columns where default_classes is set (likely the majority of cases).{% else %} condition to the default_classes condition block ({% if column.default_classes %}) and reset the variable there ({% set column_classes = [] %}). This adds two lines of code and creates a more complex logical structure for the themer to navigate, but it has the benefit of more explicitly demonstrating how classes are being handled by the default_classes setting.Active
11.0 🔥
This is a core issue actually, not views_templates.
To further your explanation, the column classes are only reset if the default value is set.
I'll move it over and take a look later.