The big CSS overhaul in 3.3
Following the discussion at the UI irc meetup yesterday, I think it’s time to start planning for the CSS overhaul for 3.3. I’ve been dreaming to do that since before 2.7 came out and finally we seem to have the opportunity to accomplish it (no more IE6!). Some quick points:
- The overhaul should be on the coding side, no changes (or only minimal changes) to the look and feel of the admin theme.
- Don’t think we need to change the structural CSS. Yes, it’s overly complicated, that was needed to support IE6 and still have nice liquid layout and proper footer placement but it still works well.
- I think we should start by redefining and perhaps abstracting as many CSS classes as possible and make them global, i.e. apply styling directly to the HTML elements using CSS 2.1 and CSS 3.0 selectors rather than using classes and IDs everywhere (as long as this doesn’t affect rendering speed in the browsers). We should also move these to global.css.
- Don’t think we will need the CSS reset/normalization any more, perhaps only for IE7, so it can be moved to ie.css.
- As IE7 seems to be the problematic browser now (from CSS point of view), I think we should concentrate on writing nice standard CSS and then adding any fixes for IE7 in ie.css.
- We can add second conditionally loaded stylesheet for IE8 if necessary.
- We can change the HTML as much as needed in order to apply the new styling.
- We can change/adapt the JS too since in many cases it uses the same CSS classes and IDs that currently are used for styling.
Ideally we will end up with much shorter stylesheets (faster rendering in the browser) that will give any HTML loaded in the admin the look and feel of the theme without the need of any classes. Most importantly we should end up with nicely structured CSS that will be easy to change or extend in the future and would require minimal tweaks/additions when adding new components to the admin.
Browsers we will need to test in: Firefox 3.6? and 4.0; IE 7, 8, 9, 10 (eventually); latest Chrome and Safari, Opera 10? 11.
I know this will be a lot of work so the sooner we have a working plan, the better. Comments, suggestions, thoughts are welcome!
Ken Newman, 
Kenneth Younger 7:11 pm on April 27, 2011 Permalink
Has there ever been talk to moving to using a CSS framework like LESS.js?
Chelsea Otakan 9:32 pm on April 29, 2011 Permalink
I’d recommend against it. While i like the thinking behind LESS.js, would another layer to interpret LESS (and wouldn’t work with no-js, unless we did it serverside, but that would be another thing to think about when making sure .org users have compatible server setups).
Would also require all the core contributors to learn a new framework. I’m thinking something like this probably won’t get worked into core anytime soon.
Ryan Imel 3:28 am on April 30, 2011 Permalink
+1 on that thinking.
easilyamused 8:01 pm on April 27, 2011 Permalink
Count me In, been looking for something to get more involved
John Blackbourn 9:08 pm on April 27, 2011 Permalink
Out of curiosity, what’s the aim behind removing classes and targetting elements instead? Surely reverting to element selectors is less extensible and less future-proof, because any plugins that add admin elements which inherit a certain style will need to use the correct element instead of just the correct class. If we then change an element in the future then all the plugins using these elements will break.
Rami Y 3:05 pm on April 28, 2011 Permalink
plugin developers will have to adopt the new standarts.
Chelsea Otakan 9:34 pm on April 29, 2011 Permalink
Which we see as a positive. we’re going to start trying harder encourage plugin developers to standardize their UI to integrate better into core.
Rich 'elfin' Pedley 11:28 am on May 6, 2011 Permalink
I do hope you will give plugin developers several months to fix any issues that arise from this change, or you are going to see a lot of complaints about it. But if this is one step closer to getting better markup in the admin, then I’m all for it.
Jane Wells 6:38 pm on May 6, 2011 Permalink
That’s why we’re doing this all out in the open, live, instead of getting it picture perfect behind closed doors (or local installs). 3. is due to come out at the end of June, so that is almost 2 months to get ready. Beta scheduled to start May 11, so we usually do an announcement to plugin authors at that point.
Rich 'elfin' Pedley 10:08 pm on May 6, 2011 Permalink
thanks Jane, can I ask that an announce goes on the hackers list at that time. It’s about the only one I can keep upto date with at present.
arena 9:52 pm on April 27, 2011 Permalink
Should migration to HTML5 for admin be on schedule for 3.3 ?
Andrew Ozz 4:38 pm on April 28, 2011 Permalink
We are still supporting IE7 (and seems we will be for another year at least) so full migration to HTML 5.0 seems unlikely given the amount of fixes needed for IE7. However IMHO we can start preparing the newly added components for easy transition to HTML 5 in the future.
Ryan 1:09 am on April 29, 2011 Permalink
HTML5 requires no “fixes” beyond addition of an HTML5 Shiv script to add support for extra tags. Other than that, everything should work as before.
Andew Ryno 5:38 am on April 29, 2011 Permalink
So if the elements can be supported by IE7 by simply declaring them as display: block;, then those could be used as long as they are used properly??
Chelsea Otakan 9:34 pm on April 29, 2011 Permalink
+1
Ryan 12:49 am on April 30, 2011 Permalink
They don’t need to be displayed using display: block necessarily. But yeah, the standard ones like header, footer, nav etc. do often need to be set as display: block. But that’s no different to HTML4 elements which aren’t set to the desired display property.
Ryan Imel 10:34 pm on April 27, 2011 Permalink
Definitely excited to see this discussion starting. Hope I can help.
There are definitely places to improve the current CSS. Just spent a bit of time looking through what’s there now.
I think it would be nice to see standardized comments in all the dev.css files explaining what they apply to. Right now the best looking comments are in
wp-admin.dev.css, but those could use some improvement too, following the CSS formatting conventions on http://codex.wordpress.org/CSS_Coding_StandardsI’ll need to spend more time with these files to really see what they all are intended to do. Looks like at least some can be deprecated.
One thing I’m not sure I follow you on is the third bullet, “apply styling directly to the HTML elements rather than using classes and IDs everywhere. We should also move this to global.css.” I don’t think I agree with this, but I could be missing your point. What would be an example of inline styles being better than well thought out classes/IDs?
Hopefully I can dig in here and contribute. I missed the UI IRC meetup yesterday, and definitely don’t want to step on any toes just commenting here. If there’s something I’m saying/doing wrong, please let me know. Looking forward to helping!
Daniel Koskinen 3:22 am on April 28, 2011 Permalink
I think by “apply styling directly to the HTML elements” Andrew doesn’t mean inline styles, but using element selectors instead of classes, eg:
table { /* global styles here */ }
instead of
.somecustomclass { /* other styles here */ }
that girl again 2:55 pm on April 28, 2011 Permalink
I don’t think he’s talking about inline styles as such, more styling html elements rather than classes. So, rather than adding a ‘title’ class to your h3s and styling that, you’d apply the style to the h3s. I suppose this is meant to be getting us ready for HTML5 when the divs we’re using now will mostly be replaced by elements, making us less reliant on classes and IDs in general.
JohnONolan 5:13 pm on May 10, 2011 Permalink
Pls note that the referenced coding standards are not final – formatting is being overhauled right now, starting with wp-admin.dev.css – other files are being brought inline with this formatting, along with the other changes which are being discussed here.
Jess Planck 2:47 am on April 28, 2011 Permalink
If ie6 is out of the party then WordPress might actually use ID and classes a little nicer. Maybe even create some nice reusable compound design elements. You know, that cascade thing… class=”message error-BBQ”
Gary 3:42 am on April 28, 2011 Permalink
-1 for for point Ryan also picks up on. There’s nothing wrong with using classes to ensure styles are applied to only the chosen elements that just otherwise happen to match the tag selector combination that a plugin uses which doesn’t want style. Switching to HTML5 semantic selectors at some point in the future means that the selectors won’t need to be updated if classes are used. And don’t even think about applying styles via the style attribute.
Moving away from using IDs as CSS hooks is a good thing (first suggested to me in OOCSS), and greatly lowers the average specificity for a style sheet. It also means any use of !important can be dropped as there’s no specificity wars going on (a class has a specificity of 10, compared to IDs being 100). Use classes as CSS hooks, and leave the IDs as scripting hooks.
Any news on the Developer and Theme/Plugin Developer handbooks, of which the Styling rules was going to be included in?
Andew Ryno 5:35 am on April 28, 2011 Permalink
I’m definitely interested in helping with this. I would suggest not leaning too much on tags for selectors. CSS reads from right to left so if you are selecting an element last, it will select ALL elements on the page, and then narrow it down. Using classes will help cut down that selection time.
Also, I’m probably going to be switching the tables in the options pages to divs, so that might be considered a part of this overhaul. Main reasoning behind the switch is easier manipulation with CSS anyway.
Jack 7:40 am on April 28, 2011 Permalink
Would love to see a mobile friendly admin area implemented via CSS. I’d be happy to help out as much as possible.
Joshua Goodwin 8:45 am on May 15, 2011 Permalink
It does seem a bit odd that “responsive” design is not being considered amongst these interface changes, but apparently they’re putting their eggs in the native apps basket, which is fine but there’s an awful lot of different mobile platforms.
Rami Y 3:18 pm on April 28, 2011 Permalink
We have to update the documentation on accordingly. Maybe if it will be a wiki, more people will help ?
Rami Y 3:19 pm on April 28, 2011 Permalink
http://dotorgstyleguide.wordpress.com/
Chelsea Otakan 6:14 am on May 2, 2011 Permalink
Style guide does need to be updated. Is it possible to make it a somewhat moderated wiki? Would hate to have people adding in style standards others might see that aren’t actually standards.
Ryan Imel 7:42 am on May 2, 2011 Permalink
There is a nifty wiki plugin out recently that would be nice for that. Complete with talk pages and everything you’d expect from a wiki. Would be a cool way of working on the style guide.
Chelsea Otakan 4:40 pm on May 2, 2011 Permalink
I think @nacin has been maintaining the style guide. Think we could make it more collaborative?
JohnONolan 5:17 pm on May 10, 2011 Permalink
The UI Style Guide? That’s Tracy’s thing, she set it all up / maintains it – but Jane set it up, so should be able to give you access
Ken Newman 3:20 pm on April 28, 2011 Permalink
Sign me up. I’m better at CSS then PHP, so this is somewhere I can contribute.
Tom Adams 3:53 pm on April 28, 2011 Permalink
I agree with Kenneth on the point of using CSS alternative syntaxes. I prefer SASS though ( http://sass-lang.com/ ).
I’m surprised nobody’s mentioned it yet, but html5boilerplate’s CSS is very helpful: https://github.com/paulirish/html5-boilerplate/blob/master/css/style.css There’s also font normalisation for IE7 support, default print styles, etc..
Andrew Ozz 4:13 pm on April 28, 2011 Permalink
I should have explained the third bullet point better. What I mean is to use more CSS 2.1 and even CSS 3.0 selectors (with fixes for IE7 in ie.css) instead of adding classes everywhere. However if that is affecting the browser rendering speed we can drop it. Edited the post to include this.
Austin Matzko 4:20 pm on April 28, 2011 Permalink
Abstracting and minimization sounds great, but lets leave in at least semantically-descriptive class names on the section level, so plugins and themes can easily overrule the admin CSS.
The status quo is like this:
#wpwrap > #wpcontent > #wpbody > #wpbody-content > .wrap > #posts-filter > .actions input#doaction2But it could be better done with something like
.wpbody > .wrap > .wp-lists-table > .actions > inputand accomplish the goals of being more abstracted, more semantic, yet still able to be easily overruled by plugins.
Andrew Ozz 4:26 pm on April 28, 2011 Permalink
Exactly, you said it better
Ryan Imel 10:33 pm on April 28, 2011 Permalink
Okay yes, I’m all about that move. Sorry for misunderstanding what you were saying Andrew.
I’d also be interested in getting a few more helpful classes/IDs added throughout the admin. The few times I’ve ever had to/wanted to make a few tweaks with my own CSS, I’ve had trouble targeting exactly what I wanted to. So it would be nice to supplement the classes/IDs that are already there.
Philip Downer 8:56 pm on April 28, 2011 Permalink
Count on me to pitch in wherever I can as well. Has any thought been given to using a JavaScript library like Modernizr to provide progressive enhancement based upon what CSS3 capabilities a user’s particular browser has? Taking an approach of enhancement rather than fixes for specific browser versions may help ensure that as users move to IE8+ or another browser they simply have that functionality added.
Chelsea Otakan 9:42 pm on April 29, 2011 Permalink
+1. I love modernizr and it sets up CSS to eventually move to global styles once the features are standard. Any other thoughts on this?
Ryan Imel 3:31 am on April 30, 2011 Permalink
+1 on the idea. My thought is, why not?
GaryJ 8:21 am on May 5, 2011 Permalink
-1 to any use of JavaScript to support browser CSS failings, unless it will still all be usable in those browsers without the JS support too.
JohnONolan 5:18 pm on May 10, 2011 Permalink
-1 I completely agree with GaryJ.
Jack 9:36 am on April 29, 2011 Permalink
Very happy to help out with the project in any way I can… Where can I see more about how?
Stefan 10:27 am on April 29, 2011 Permalink
+1 here as well. I also agree on using a preprocessor, SASS/Compass would be sweet. http://compass-style.org/ Whis would also help a lot on multiple admin themes since you cand use variables, interpolate them etc. and you basically write just a single core css file that complies to as many as you want.
I think a light OOCSS approach would work. https://github.com/stubbornella/oocss/wiki By that I mean we should use for the most part just classes while leaving the ids only for js when possible. This would avoid specificity chaos and if the objects are thought out well it could really simplify the code and improve speed. I said “light” because Nicole’s approach might seem a bit extreme since she uses lots of presentational classes
So where do I sign?
Andew Ryno 3:03 am on April 30, 2011 Permalink
Chelsea gave her views on using something such as LESS/SASS/etc. I agree with her. It’s just one more thing that people would need to learn/use and another step for the CSS to render.
http://make.wordpress.org/ui/2011/04/27/the-big-css-overhaul-in-3-3/#comment-2816
Stefan 9:53 pm on April 30, 2011 Permalink
Yes, but we’re talking about the admin, not themes. Using SASS for example should be easy as cake to devs. (I think SASS is more powerful than LESS at the moment)
gem install compass (one time)
compass watch /path/to/css
That’s all there is to running it.
IMO the advantages vastly outnumber this extra work. You can separate logical chunks of css into separate files for easier maintenance, http://grab.by/a0Gh and this way you could even generate multiple themes at once as I mentioned earlier because you only change a few variables or you import a different module.
Furthermore, using mixins would save a ton of headaches for CSS3 properties. You just say @include border-radius(5px) and compass generates every vendor prefixed declaration you need. The compass authors do a great job of maintaining those mixins so if Opera implements tomorrow some feature that Webkit already has it’s just a matter of doing a “gem update compass” instead of changing any line of code. border-radius is the simplest example, this goes for gradients, box-shadow, etc. as well. Tie this up with Modernizr http://www.modernizr.com/ and you could avoid a bunch of images altogether in supporting browsers and thus get a speed improvement. CSS3 performance is probably at it’s peak of trendiness since it got a Smashing Magazine article too
http://www.smashingmagazine.com/2011/04/21/css3-vs-css-a-speed-benchmark/
http://compass-style.org/reference/compass/css3/border_radius/
Lots more stuff included like nested elements, functions, color calculations and adjustments, @media bubbling (huge win here), cache-busting image paths, have a look through the docs.
Having a /sass folder and automatically generating a (even minified) .css file seems like the same amount of hassle to me as having a .dev.js file and generating a minified .js file. Everybody’s already doing that out of obvious reasons and you don’t see anyone complain.
I say and advocate all this out of experience since I’m also working on a WordPress network with Scribu where every site has a fairly different theme and this http://grab.by/a0G2 is all you’d need in order to generate a new theme stylesheet. The $child variable you see there for example is the path to the image folder being used for each theme, you never change the background-image declarations, http://grab.by/a0G9 you just make a new folder with with the images you need. http://grab.by/a0Gn This is just my solution to a problem as an example, things can be done in many ways.
Another thing you can see in that background declaration screenshot is that you never have to write class=”clearfix” on an html element ever again, you just include it in the css.
Since I started using SASS I never made any themes or client work with non-preprocessed css ever again.
Hope you give this another thought.
Stefan 11:28 pm on April 30, 2011 Permalink
Oh, and Chelsea was talking about LESS which is written in javascript and could be run in node.js or in the browser directly. Doing it in browser should be out of the question since it cancels the performance gain.
So you’re doing it “server-side” although I’m not comfortable with the term since you just generate a .css file upon saving that you upload to the repo as you would with the current css files.
I’d say SASS is ahead (it was the other way around back in the days) in features and forward compatibility with upcoming css standards that are undergoing work.
Please, oh please, don’t use the “it’s another thing to learn” argument
It’s brain dead simple. Way more simple than any other .js problem that people surely have encountered. It’s still css and devs are smart people 
Using variables, mixins or nesting is the way to go either way and btw, here’s a presentation from Tab Atkins on just that and other stuff in future Chrome versions:
http://www.xanthir.com/talks/2011-01-12/slides.html
Also, preprocessors are endorsed by unicorns.
Andew Ryno 11:45 pm on April 30, 2011 Permalink
Okay, so even if I drop the “another thing to learn”, it’s still another thing for people to use.
node.js won’t work since most people wouldn’t use it. Browser has performance issues. If you’re compiling it locally and just generating a .CSS file, then go ahead and use it for yourself when working and just compile the final stylesheet and use that.
Point is, there is really very little point in adding it to core. It’s not needed and would cause more problems and ones it would solve.
Stefan 11:58 pm on April 30, 2011 Permalink
Right, I also posted another longer comment before that one but it got into moderation probably because it has quite a few links.
Agreed on node.js.
The point would be to add the .scss files to the core as well (the files from which you complile the .css ones) so that developers could use them. The compiled .css file would be preferably minfied though you can make them look pretty when you compile instead.
JingKai Seah 2:26 pm on April 29, 2011 Permalink
I’m all in this~ Would love to help as much as I can
Spencer Hill 3:06 am on April 30, 2011 Permalink
I would like to see the deprecation of non-systematic classes. Every website on the planet has a row and column based structure to it. Even if it appears to blur those lines visually, it is, ultimately, a table of sorts. My team and I have been using this method for several years now and it saves us so much time. Let me demonstrate and explain:
My header.
My main content.
My sidebar.
My footer.
And you can imagine the CSS.
With this systematic approach, a developer is no longer basing their class names of partially descriptive, variably shortened, dictionary words based on their opinion of the contents or design of each element. Rather, it’s based of a calculative naming convention that can be learned and practiced by any developer who can… count… and read…
When this method is properly executed other developers can literally just LOOK at a site, without even seeing it’s code, and correctly presume how the HTML and CSS is coded. Allowing developers to focus on what they are paid to do instead of deciphering a previous developers methodology of naming conventions that is different than the website they worked one which was different than the one before that!
Here is a recent project we did using this methodology: http://vista-capital.theportlandco.com (review the HTML and CSS)
Obviously there are some cases where the developer really needs to use a descriptive class name (like light boxed elements, messages, etc…), but when it comes to layout I’ve never seen a better approach.
=========================
Now, regarding CSS files. I would like to see a globals file, like anyone else, but I’d also like to see a CSS file for each template. For example, when coding a THEME there is the 404.php, search.php, page.php, etc… And rather than coding all of those styles into style.css, we create a CSS folder and create 404.css, search.css, etc… Even if we don’t have any custom styles for those pages we still create the blank documents so future developers know what belongs there. Then in our header.php file we include simple conditional statements to include those styles when the related template is being used. It eliminates 3,000 line CSS documents and, again, systematically directs developers while keeping things organized.
=========================
Regarding IE7, it seems that if we are trying to standardize, advance and simplify WordPress under the hood than we shouldn’t set ourselves up to fail by avoiding complete use of HTML5 (and I understand we would use it where we can). Rather, like we’re doing with CSS3, I think we should use HTML5 to the fullest extent, then create separate degradation utilities to accomodate IE7. It means more work for us as developers now, but we won’t have to have another overhaul like this to deprecate everything we did for IE7 when IT’S deprecated.
=========================
Lastly, I’d like to help. And so would my team.
Go GitHub! SVN works but Git is the future so creating a hook to the WordPress repository and allowing pull requests would be SO nice so developers like us can contribute.
Spencer Hill 4:53 pm on May 3, 2011 Permalink
It appears my code got filtered, so you’ll have to review the link I provided to see what I’m referring to.
Melvin Ram 7:38 pm on April 30, 2011 Permalink
I’d like to help by putting in 10 hrs per week towards this but I’m just not clear on how specifically to help. Can we just fork WP, make the changes to it and just send in a patch when it’s done or what? I’m a long time user of WP and I’d like to actively help but I’m just not sure how yet.
Jane Wells 5:00 pm on May 2, 2011 Permalink
Please go to http://core.trac.wordpress.org/ and see the instructions at “How to Contribute Patches” at the bottom of the screen.
Melvin Ram 7:39 pm on April 30, 2011 Permalink
How exactly should I go about this if I want to help? Make the changes and submit a patch?
Jane Wells 5:02 pm on May 2, 2011 Permalink
Yep!
pampfelimetten 5:26 pm on May 5, 2011 Permalink
I love the general idea of a better css structure, keep it going.
Is there any chance in working on tickets like this? http://core.trac.wordpress.org/ticket/12295
In short: It would be nice to be able to apply styles to the profile page as well.
WraithKenny 7:05 pm on July 6, 2011 Permalink
I think we can stick with latest FF rather then ff3.6 since they end-of-life’d even 4.0