Do not load normalize.css in all themes, load it in Classy

I have searched for core/normalize, removed the two occurrences and manually loaded normalize for Classy :)

@yannickoo I guess no need to remove from theme.inc file

Oh, I forgot to fix the test :)

Re #7: Can you explain me why? I mean it in that place the same libraries as in system_page_attachments should be loaded so when removing from system_page_attachments we should remove it from template_preprocess_maintenance_page as well.

I have removed the lines which were introdued here.

This probably ok. We've gone back and forth on how to handle Classy, but realize it will be the best place to put CSS so we can remove it from core modules. Related to all the dream markup efforts.

P.S. Why would anyone use Stark as a base theme? I don't understand the reasoning.

The remove all visuals from Stark issue is done. Lets try this again.

We are removing the mandatory inclusion of a library in core, so a change record wouldn't hurt.

I just started reviewing with a manual test and found this breaks the Bartik layout:

Seven, also.

+++ b/core/themes/classy/classy.info.yml
@@ -7,3 +7,4 @@ core: 8.x
+  - classy/normalize

Oh, duh. That should be core/normalize. I'll fix.

Adding beta evaluation.

Added a draft change record.

I am confused as to why core/normalize should exist in the context of this issue.

I think because it's a general purpose library it should stay in core so that other themes can use it freely and without possible confusion or dependencies.

Yeah, it's a vendor provided asset, but core is what registers it as a library so it is available to all. Themes that don't use Classy may still want to make use of it, but we don't want to force it on them as a default.

I am reviewing following the official process:

• This is a task so there is no problem to reproduce. I read and understood the issue summary.
• I read the patch. This an easy-to-understand issue and an easy-to-read patch so there is not much to say. The patch does not introduce new coding-style violations.
• I approach a review like this by searching for the given thing with and without the patch applied. Without the patch:

$ ack 'core/normalize' core/
core/includes/theme.inc
1465:  $variables['#attached']['library'][] = 'core/normalize';

core/modules/system/system.libraries.yml
10:    - core/normalize

core/modules/system/system.module
523:  $page['#attached']['library'][] = 'core/normalize';

• With the patch:

$ ack 'core/normalize' core/
core/modules/system/src/Tests/Theme/ThemeInfoTest.php
97:    $this->assertEqual(['classy/base', 'core/normalize', 'test_theme/global-styling'], $active_theme->getLibraries());
103:    $this->assertEqual(['classy/base', 'core/normalize', 'test_theme/global-styling', 'core/backbone'], $active_theme->getLibraries());

core/themes/classy/classy.info.yml
10:  - core/normalize

• I can see from this that 'core/normalize' has been removed from usages in core generally and instead put into the Classy theme as a dependency. I can also see that it is likely no instances were missed. In addition, tests have been updated accordingly, which means this change has some regression test coverage.
• This is a small patch and it is limited in scope to the intended change.
• Next, I tested the patch by making a clean install and turning off CSS aggregation. I found that normalize.css is included in Seven, Classy, and Bartik, as expected. It is not loaded in Stark, so the patch works as expected.
• I manually tested, looking for anomalies like I found in #16 and found none.
• The draft change record describes this change and makes sense to me.

Based on my findings above, this is ready.

Committed 23df3d5 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation to the issue summary.