Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
CSS
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
10 Sep 2015 at 20:47 UTC
Updated:
9 Nov 2015 at 23:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
lewisnymanThis patch includes all the above issues and the following files:
Here's a screenshot of the loading order:

Comment #3
davidhernandezIs this suppose to be in here?
This also looks like you are including the clean up stuff to rename the existing libraries? I'm ok with that. Just want to be clear.
Comment #4
rainbowarray#3: Yes, that is supposed to be there. In the subissue that involved the menu CSS, we found that the menu template still had the class="menu"; however, all the styles associated with that were purely aesthetic and should be moved to Classy. In tracing things back, the menu class was already moved to Classy. However, it was added back to the core template due to a Toolbar regression. A subsequent issue removed the dependency on the menu class for Toolbar, but the menu class was never removed from core. So it's okay to go, the Classy template already has the menu class.
Comment #7
lewisnymanComment #8
rainbowarrayTook a close look through, comparing this patch to all of the patches on the related issues. Everything looks great. Just reordered one CSS file to match the alphabetical sort order.
I also looked at the failing tests, and I can't for the life of me think what in here would have caused that. We didn't see that error on any of the other issue's tests, so not sure why it would pop up here when we essentially have all the same changes.
Comment #11
davidhernandezHere is what I'm seeing. The files all changed from @import to link. Why?
before

after

Comment #12
lewisnymanAhhh, so the only reason they are using import is because they go over the number of stylesheets IE can load. I guess that now we have a more even split between module -> base theme -> sub theme we no longer hit that limit.
Comment #13
davidhernandezOh, ok. We should be able to safely change that test then. The number of files won't grow.
Comment #14
lewisnymanIt might do once we move more and more files into Classy? Is there a way we can remove the assumption completely? We only need to check if the CSS files are being loaded or not. We aren't testing how they are being loaded.
Comment #15
davidhernandezThe test doesn't use Classy. This one in particular installs test_basetheme and test_subtheme and uses them the check the stylesheets related to those themes. So it will only see whatever CSS is loaded by core modules. That is why all the CSS files disappeared.
Comment #16
davidhernandezI wonder if we can rope #2380651: Remove or rename Classy's layout.css file and adjust tests into this while we're at it. It just involves deleting the layout file and switching the tests to use another one of the files in "base" and remove the stylesheets-remove lines from Seven and Bartik. field.css or form.css are probably good candidates.
Comment #17
lewisnymanThat would be nice.
Comment #18
davidhernandezThis hopefully fixes those tests.
Comment #19
davidhernandezUgh that global isn't needed. It was helping troubleshoot.
Comment #20
davidhernandezIn order to remove the layout file, these tests will have to be changed:
core/modules/system/src/Tests/Installer/InstallerTranslationTest.php
core/modules/system/src/Tests/Theme/ThemeEarlyInitializationTest.php
and remove the stylesheets remove lines from Seven and Bartik:
Comment #21
davidhernandezand of course this from Classy's libraries file.
theme:
css/layout.css: {}
Comment #22
davidhernandezThis should finally get rid of the empty layout file.
Comment #23
davidhernandezYay, green. This is the one. Twig team, assemble!
Comment #24
rainbowarrayI had previously compared all of the individual move issues to the patch in this issue, and that looked good except for the failing tests. Reviewed the test fixes, those look solid based on the changes in the HTML, and I agree that test is unlikely to break now that we have moved so many CSS files out of core. Also reviewed the changes that lets us remove the unnecessary layout CSS file that was just there for testing: that too looks good.
This looks ready to commit to me.
Here are all the contributors from the individual issues and this one:
- Cottser
- LewisNyman
- mdrummond
- pjbaert
- jaxxed
- ManuelGarcia
- emma.maria
- maked1sky
- davidhernandez
If I missed anybody, sorry.
Comment #25
lewisnymanConfirmed, I moved the suggested commit message into the summary:
Issue #2566597 by - Cottser, LewisNyman, mdrummond, pjbaert, jaxxed, ManuelGarcia, emma.maria, maked1sky, davidhernandez: [Mega patch] Move system *.theme.css files to ClassyComment #26
alexpottGreat idea to prevent reroll hell with this. Awesome effort and fantastic work. Committed fb07e7b and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation to the issue summary.
Comment #28
chx commentedThis was one classy move...
Comment #29
lewisnymanWe have introduced at least one regression into the admin interface.

We took care to make sure the loading order of the CSS stayed the same relative to sub-theme, but something we didn't consider enough was the loading order of
module.admin.cssfiles in relation to themodule.theme.css(now just Classy CSS) files.The place block buttons happen to fall into the situation where they are affected by Classy CSS that is now being loaded after when it was being loaded before:

Comment #30
davidhernandezSo there would have been nothing we could do about this since the module CSS will always load first, regardless of category. We'll have to fix the CSS.
Lets open a follow up.
Comment #31
davidhernandezFollow up
#2567845: [regression] Fix any visual regressions from moving the System CSS to Classy
Comment #33
wim leersThere was a small oversight here, opened an issue to fix it: #2601232: Follow-up for #2566597: only attach the 'classy/messages' asset library if there are messages.
Comment #34
star-szrI'm not sure how yet but I think this somehow broke the color module lock functionality: #2612150: You can no longer see the locks when locking colors together
I did a git bisect that led me here, it seems to work on 9822652 but not 6586221 where this was committed.