Updated: Comment #N
#1839318: Replace drupal.base.css library with normalize.css for all themes was a great move, and it will be a huge benefit to many subthemes. However, it should be possible to exclude it, and it might not be completely obvious at first how to do that.
Additionally, the Stark theme has always had as little styling as possible loaded, and should not include normalize.css
Remove normalize.css from Stark
N/A
Stark will revert back to how it looked before normalize was added (an undocumented UI change!)
N/A
#1839318: Replace drupal.base.css library with normalize.css for all themes
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | drupal8.stark-renormalize.patch | 299 bytes | sun |
| #2 | Screen Shot 2013-10-04 at 00.49.35.png | 52.02 KB | swentel |
| #1 | Screen Shot 2013-09-29 at 4.28.29 PM.png | 44.91 KB | tim.plunkett |
| #1 | Screen Shot 2013-09-29 at 4.28.24 PM.png | 42.55 KB | tim.plunkett |
| #1 | stark-2100571-1.patch | 299 bytes | tim.plunkett |
Comments
Comment #1
tim.plunkettBefore:
After:
Comment #2
swentel commentedYes please. Testing page (tables in general?) still looks small though
Comment #3
tim.plunkett#1: stark-2100571-1.patch queued for re-testing.
Comment #5
tim.plunkett#1: stark-2100571-1.patch queued for re-testing.
Comment #6
dawehnerThe normalize css file is no longer added with this patch (checked via firebug)
Comment #7
alexpottCommitted c3b7575 and pushed to 8.x. Thanks!
Comment #9
sunHm. I do not really understand this change, and the issue summary does not actually explain why Stark should not load normalize.css.
Among other things, normalize.css also normalizes the presentation for
<details>elements, and without normalize.css, all details elements look very broken in Stark (unless you are using Chrome).Since Stark is the default theme (especially in tests), this change at least negatively affects developer experience.
Before re-opening this issue (or creating a separate) to revert this change, I'd like to understand why this change was performed, because I'm not able to parse any reasoning out of this issue. There are only claims that it "should not", but no actual reasoning. Therefore, I'd like to evaluate the importance of those reasons (if any) compared to the degraded experience.
Comment #10
sunAttached patch reverts this change.
Comment #11
tim.plunkettThe issue that added it in the first place ignored Stark completely, much the same as the recent "Seven" theming issues.
At the time this went in, it was reverting weird UI quirks, and everything looked fine once normalize.css was not loaded for Stark.
If that is not the case, and things do not look correct, that is the fault of issues that went in since November 2013, likely the "Seven" theming issues.
My "should not" directive was trying to uphold
If we want to quibble on what "default" means, since normalize.css is loaded by default for everyone, that's fine by me.
----
TL;DR I'm fine with reverting this if it resolves UI weirdness caused by the recent changes to Seven.
Comment #12
sunHm. Perhaps I'm misguided...
Technically, normalize.css is the wrong tool for the job of fixing the presentation of HTML5 elements that are not supported by a browser.
To my knowledge, that's the purpose of html5shiv JS, which should be unconditionally loaded on all pages. It indeed contains the necessary tweak, too:
But alas, the html5shiv library has been explicitly limited to IE:
Without that limitation to IE, details elements should appear correctly in Stark when using e.g. Firefox.
Created #2218023: Details and other HTML5 elements do not appear correctly in Stark
Sorry for the confusion.