Move system tabledrag.theme.css, tableselect.theme.css, and tablesort.theme.css to Classy

See this issue #2505931: Remove SafeMarkup::set in ViewListBuilder

I had to make some CSS changes to item list that should not be moved to Classy. Basically, added some declarations for "comma-list". Those really need to stay in core in a item-list.module.css, but it was hard to do that without refactoring some of the item list CSS, including things in Seven and Bartik. Those would have been out of scopr for the other issue. That should be easier to do with the main item list CSS moved to Classy.

The easiest thing would probably be to move the main item list declarations to Classy, remove the ul specificity, and then refactor what is needed.

If someone works on this, ping me and I'll explain it better. I can also work on this myself, but I wanted to make this comment so I don't forget.

Some work has been done in #2557367: Fix inline list CSS FYI, @davidhernandez found the connection.

I carried out the test steps and can confirm the following:

✔︎ Check that the CSS file was deleted from the module and added to Classy
– tabledrag.theme.css no longer exists in the module and tabledrag.css now exists in Classy.
– tableselect.theme.css no longer exists in the module and tableselect.css now exists in Classy.
– tablesort.theme.css no longer exists in the module and tablesort.css now exists in Classy.

✔︎ Check that the references to that CSS file removed from the system module
– References to tabledrag.theme.css, tableselect.theme.css and tablesort.theme.css within system.libraries.yml have been removed.

✔︎ Check that the CSS file is being loaded in the correct places in Classy
– tabledrag.css, tableselect.css and tablesort.css are being loaded within Classy in the same order as the originals in system.libraries.yml

✔︎ Check that there are no HTML classes in the module that relies on the theme CSS
- I couldn't find any markup references to CSS in tabledrag.css, tableselect.css or tablesort.css.

+++ b/core/themes/classy/classy.libraries.yml
@@ -2,6 +2,9 @@ base:
     theme:
+      css/components/tableselect.css: { weight: -10 }
+      css/components/tabledrag.css: { weight: -10 }
+      css/components/tablesort.css: { weight: -10 }

Agreed, these should be globally included. Posting the same question I've been posted elsewhere, should these be in a 'theme' folder since they are being added in the theme category? Otherwise, looks good.

This is what I'm seeing. Changing the category changes the ordering more significantly, putting the files lower in the cascade. I think leaving it in theme is fine. I was suggesting putting the files into a theme folder to keep it consistent with the categories. Does that make sense?

I'm actually looking at Bartik and Seven and they both seem a bit inconsistent with this regard.

before

after

I'm not sure where the suggestion of putting them in the component group came from. I think we were ok. (Well I added some stuff in component to get it higher.) I was just suggesting changing the directory where the files are stored, since we are adding things using the theme group. Since most of these are coming from the theme group, added by system, moving to component is a bigger change.

I don't think there is anything we can do to keep the ordering exactly the same. As you've noted, the module css gets added higher. I think best we can do is get it high in the category, since it is a base theme. What I've been doing is checking the ordering to make sure it at least is before any similar css being added by Bartik or Seven.

...actually, I partial recant. Why are they dropping in order. Moving from theme to component should put them higher. Can someone else test?

I agree with @mdrummond's assessment in #11. And SMACSS theme should be able to override a component. So putting something in theme should be higher than component IMO.

Search Component:
.search { border: 1px solid silver; }

Search Seven Theme:
.search { background-color: tan; }

https://smacss.com/book/type-theme#themes

Don't mean to step on your toes here, I'm sure you both know more more what's going on in banana land than I do.

Right, theme should be lower than component, to override it. That is why I was confused why switching from theme to component made it drop so much lower in the order.

I wasn't working on core when most of the ordering was designed, and hadn't delved into, so I keep making assumptions. That'll get me in trouble.

So I assumed the ordering would work like this:

base
- modules
- base theme
- child theme

component
- modules
- base theme
- child theme

theme
- modules
- base theme
- child theme
...

but it looks like it does this:

modules
- base
- component
- theme

themes all together
- base
- component
- theme
...

Is that right? If so that is less flexible than I thought, but whatever. We won't be able to control the ordering to match the original then. We just need to make sure the files are getting included higher in the order to come before child theme CSS. That is my main worry. So putting them all in component with weights might be the best thing.

What we're really deciding is whether all Classy CSS should come before the child theme CSS. If yes, then there is no point putting any of it in theme.

By the SMACSS definition, theme should be used very very rarely. The problem we have here is that we have a bit of a mixed meaning in Drupal, because we originally associated 'theme' to be a Drupal theme as part of the the MAT definition (Module/Admin/Theme). These groupings were originally created to make it easy for themers to remove all non-essential module CSS in their theme.

Moving all the *.theme.css files to Classy removes the need to distinguish these two groups, the Classy and Stark separation achieves this for us.

Yes this looks correct. It needs a reroll though.

re-rolled #9 based on 8.0.x

Great, thanks

Postponed on: #2566597: [Mega patch] Move system *.theme.css files to Classy

The mega was committed so we don't need this.