Clean up the CSS for System module

Note: some of this was already completed here: #916424: Merge system.messages.css and system.menus.css into system.theme.css

Great! so it appears what remains is a review of the system's css in it's entirety to make sure it follows the rules listed above.

Tagging for the next sprint.

Some thoughts here

/**
 * Float clearing.
 *
 * Based on the micro clearfix hack by Nicolas Gallagher, with the :before
 * pseudo selector removed to allow normal top margin collapse.
 *
 * @see http://nicolasgallagher.com/micro-clearfix-hack
 */
.clearfix:after {
  content: "";
  display: table;
  clear: both;
}

.clearfix {
  zoom: 1; /* hasLayout trigger to clear floats in IE */
}

The .clearfix{zoom: 1;} is IE6/IE7 specific. If we dropped support for IE7 we could eliminate the zooming part of this hack.

/**
 * Block-level HTML5 display definition.
 *
 * Provides display values for browsers that don't recognize the new elements
 * and therefore display them inline by default.
 */
article,
aside,
details,
figcaption,
figure,
footer,
header,
hgroup,
menu,
nav,
section,
summary {
  display: block;
}

Will we still need this after the html5shim.js gets into core?

Also what do you think of this patch. It does one thing, remove all tag specific css throughout the system.base.css (instead of the html5 stuff referenced above). I know we want to reduce selector specificity and all, but does this patch take that idea too far?

@cosmicdreams both of those hunks are brand new, so this cleanup issue should not touch that stuff.

Regarding the HTML5 stuff, yes we will absolutely need that. The Shiv does not provide CSS styling. It just makes IE recognize the elements so that they can be styled against.

As far as that patch goes, I think it's going in the right direction, but will need to be heavily tested. :)

@jacine, thank you.

I'm attempting to test as I go, but I do recognize that since this is the system.css it touches everything. I suspect that the question of "What should go into system.css" has been debated a lot. As someone who has just started getting into organizing that file, it seems that parts of it make more sense to be placed elsewhere.

On clear example for me is the code referencing #autocomplete at the top. That's a kind of form field and makes sense to be placed either with the jQuery Form library or the module for the field_ui.

Should a full refactoring of the system.css be on the table?

So, you happened to pick one of the harder CSS cleanup issues.

In addition to cleaning up code for the tabledrag styles and some others we were unable to get to in D7 (because it was too late), this is what I'd like to see happen here: #885228-24: CSS Files are in major need of clean up!. Most of the work is already done as far as splitting things up properly goes in that patch.

Wow @jacine, a lot of history there.

What is the purpose of field_ui.css if not to handle the styles that impact how a user interfaces with field controls? Can you comment on whether to move #autocomplete styles there is a good recipe for our Cleanup task?

@cosmicdreams If you look at the patch I linked it makes the bits of JS functionality more like functional plugins. That's the direction I believe we should go in. You should literally follow the direction taken in that patch. I can go through this in more detail with you on Sunday if you plan on attending the office hours.

field_ui.css is a separate issue. I believe an issue was not created because a component did not exist at the time. It does now, so a separate issue should be created for that.

Setting to needs work.

untagging... this is too complicated right now.

In an effort to get a better picture of issues remaining in the HTML5 Initiative, we are removing the "html5" tag from issues that are not directly HTML5-related. Note: Any issues assigned to the "Markup, CSS and JavaScript" components will still be broadcast on the HTML5 Twitter feed so that interested parties are aware and can participate. This effort will continue on it's own as a community-driven initiative.

just get rid of all css outside the themes alltogether, and then create a better (actual) solution for module theming

FWIW, I worked on two specific areas of system.theme.css, since I'm exclusively working in Stark today (but these two annoyed me for years already):

#1813792: Remove ugly default CSS styles for table
#1813854: Simplify and improve default CSS styling for menus

Although I’ve read this issue through, I can see no clear description of what the system stylesheets are for. What problem are these system stylesheets solving? I suspect the most effective resolution for this issue depends a lot on the answer to that question.

Now that normalize.css is in core, I propose loading that 1st for all profiles. Then in system.base.css we should remove the HTML5 Block-level styles except for those that are unique to Drupal which as far as I can see is only 'menu'.

Also remove from system.theme.css lines 22-24 'img' style. Lines 10-13 'fieldset' styles. Line 23 'border-collapse' style.

There may be many more conflicts/duplication throughout module and theme css files, but this is just for minimal installation and only for system files.

IF menu styles are the only ones left, I'd love to see us just delete the file. I find myself fighting all too often with the default menu styles and they really don't add any value.

No @jessebeach, not what I meant. It was just the block-level HTML5 specific styles at the bottom of the file.
We had exact same list as normalize.css just with the addition of 'menu' element/tag.

So this:

/**
 * Block-level HTML5 display definition.
 *
 * Provides display values for browsers that don't recognize the new elements
 * and therefore display them inline by default.
 */
article,
aside,
details,
figcaption,
figure,
footer,
header,
hgroup,
menu,
nav,
section,
summary {
  display: block;
}

Can become this:

/**
 * Block-level HTML5 display definition.
 *
 * Provides display values for browsers that don't recognize the new elements
 * and therefore display them inline by default.
 */
menu {
  display: block;
}

In system.base.css

@mbrett5062 drat! Well, tiny drag. Any day we can eliminate presumptive reset CSS from core is a good day for me in any case. Are you comfortable proposing a patch to bat around?

Please note that there is no consensus on normalize.css for all themes. Normalize.css has been added as a replacement for Seven's reset.css only.

If you want to propose that, please create a separate, dedicated issue for that, and make sure to provide solid arguments for why you want to enforce that on everyone. And link to it from here.

@sun, I will create a new issue and link back to here.

IMHO normalize.css is a must have for all themes, to enable site developers and themers to not constantly re-invent the wheel. Today, they are always fighting against cross browser inconsistencies and that is what normalize.css fixes for us. It will also allow us to remove those tweaks and shiv's from core css.

I will include a link out to the documentation for normalize.css so people can read for themselves.

One point I would like to make.

As you yourself stated on #1168246: Freedom For Fieldsets! Long Live The DETAILS.

That's the browser's native handling of the details element, and I don't think we want to touch or "improve" the fundamental handling in any way. At least I think that's an entirely separate discussion of its own, because it would essentially mean that we'd introduce some sort of "polyfill", but not for older browsers, and instead for modern browsers that actually support a new HTML5 element already.

Normalize.css states the following.

Normalize.css preserves useful defaults

Resets impose a homogenous visual style by flattening the default styles for almost all elements. In contrast, normalize.css retains many useful default browser styles. This means that you don’t have to redeclare styles for all the common typographic elements.

When an element has different default styles in different browsers, normalize.css aims to make those styles consistent and in line with modern standards when possible.

Not sure it will help with the details element but it does help a lot in other areas.

Anyway, onto the issue.

Issue #1839318: Replace drupal.base.css library with normalize.css for all themes raised to garner consensus from the community.

As a follow-up to #1806022: Views' text color does not have sufficient contrast, an asterisk that denotes a required field is styled in system.theme.css with

.marker, .form-required {
    color: red;
}

Red (#FF0000) on a white background does not pass the WCAG AA contrast threshold.

Patch to change marker and form-required red to #ee0000. Passes WCAG AA on white.

dead_arm, you should open a separate issue for the patch in #24. It'll be more likely to get committed if it's in a targeted issue and not this general cleanup issue.

@jessebeach Good call. Opened new issue: #1862966: Marker and form-required red (#FF0000) on a white background does not pass the WCAG AA contrast threshold Sorry for the noise here, setting issue back to needs work.

#24: core-systemcsscleanup-1217044-24.patch queued for re-testing.

This is in core now, so I'm marking this as fixed:

.marker,
.form-required {
  color: #e00;
}

One more follow-up: #1906208: Independent .status HTML class triggers message/icon styling

reducing selectors weight.

We don't reuse old issues. Create a new one.

follow-up issue: #1969124: Clean up the CSS for System module

Updated issue summary.