The big CSS overhaul in 3.3, part II

Thanks to all that responded to the first post.

As WordPress 3.2 is almost ready for release, it’s time to set the immediate goals for this overhaul. There are several ideas in the comments on the first post:

  1. Use Modernizr or similar “CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. 3 browser fix” script. The WordPress admin degrades quite well when JS is disabled. We would need to keep it that way.
  2. Use a CSS framework or preprocessor like SASS/Compass. I see this as an individual choice and think we shouldn’t force the use of any CSS extensions or preprocessos in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
  3. Follow a light OOCSS approach. Agreed. Think this covers the “best practices” in CSS.
  4. Migrate to HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. 5 and CSS 3. Personally would really like to see this done. However IE7 is still being supported. If there are any ways of implementing HTML 5 and CSS 3 even partially (without using JS, see above) I think we should use them. We can add any hacks needed for IE7 in ie.css.

Some more areas that need improvement:

Currently we have 13-14 different stylesheets not counting the files added by external components and the color themes. We load global.css and wp-admin.css everywhere and then add one more file on some pages. These extra files are redundant, they can be merged in wp-admin.css without any problems. Alternatively we could split wp-admin.css into smaller chunks and have dependencies for CSS files like the JS files. Both approaches have pluses and minuses.

IMO merging all into an even bigger wp-admin.css would work better for the users as it will be cached in the browser after the first load. This will also make it easier for plugins as they can relay on having all default CSS loaded at all times, but will make it a bit harder for core developers. Not sure we need a separate global.css too. Of course will have to be clearly separated in sections and perhaps some light documentation can be added there.

The same applies for all the *-rtl.css files. They would be better off merged into one wp-admin-rtl.css.

We have been working on improving the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). ( of the WordPress admin, but are still missing a high contrast theme. Thinking we can add 1-2 high contrast themes relatively easy, that only would involve the colors stylesheets.

Don’t think we need CSS reset any more. Perhaps it’s better to add a section with default styles that will also cover the few elements that are different between the browsers (excluding IE7 that may need some reset in ie.css).

Looking at colors-classic.css and colors-fresh.css there are a lot of styles that are the same. Perhaps we need a better system for supporting different color themes in the admin. Thinking we can have the default color theme always loaded (perhaps even included in wp-admin.css) and then override it with an additional file that changes colors only where needed. That file can be queued with dependency on the default colors stylesheet which will ensure it loads after it and plugins can extend it in the same way.

How to get involved: to be able to eliminate any duplicate work in the first stage, thinking we should split the main tasks between the people that can complete them faster. Ideally we should have the bulk of this done whitin two to three weeks after 3.2 comes out. Please leave a comment on this post if you feel confident with this deadline.

After that we will need to test and refine everything and will need as many people involved as possible so we don’t miss anything.

When 3.2 is released watch out for tickets on tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub. for the main parts and perhaps one ticket that will list the rest so they can be found faster.

As always suggestions and comments are welcome.