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:
- Use Modernizr or similar “CSS 3 browser fix” script. The WordPress admin degrades quite well when JS is disabled. We would need to keep it that way.
- 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 core.
- Follow a light OOCSS approach. Agreed. Think this covers the “best practices” in CSS.
- Migrate to HTML 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 wp-admin.dev.css 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 accessibility 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 trac 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.
Andrew Nacin 3:19 am on July 2, 2011 Permalink
You might be able to find the support to drop IE7. Jaquith and I are tentatively +1.
Ramiy 12:17 pm on July 2, 2011 Permalink
Many developers want to drop support for ie7 for obvious reasons, but most of the “regular” non-technical users are still using old browsers. You have to consider that fact.
On the other hand, WordPress is used in more than 14% of all websites world-wide, and many web hosts upgraded their PHP/MySQL to support WordPress 3.2.
But, it’s harder to change user-behavior than business-oriented organisation behavior.
Andrew Ozz 6:06 pm on July 2, 2011 Permalink
Had a quick look through the browser stats while writing this post, IE7 is at about 7-8% of all browsers used for the last few months.
Perhaps is better to continue support for it (even gracefully degraded support) until next year.
Andrew Nacin 1:32 pm on July 4, 2011 Permalink
Should be noted that Google Apps is dropping support for IE7 as of August 1. Let’s see if Browse Happy causes a bump in our stats.
Cristopher Ocana 2:47 pm on July 5, 2011 Permalink
wouldn’t be easier to use modern CSS on modern browsers and give minimal fallback support for IE7?
WraithKenny 8:01 pm on July 6, 2011 Permalink
It’s worth noting that users on IE7/IE8 with JavaScript disabled is much smaller then all IE7/IE8 user statistics and those users are who’d be effected. A JS Shim solves the issue for normal users. Styles could still be applied to non-html5 elements anyway (<article><div id=”foo”>test</div></article>), even in IE7, but that wouldn’t be as useful or fun.
WraithKenny 8:26 pm on July 6, 2011 Permalink
Perhaps a warning message, “WordPress is a modern web app. It can’t run perfectly in an old browser with JavaScript disabled.”
Andrew Ozz 8:44 pm on July 6, 2011 Permalink
Seems a lot of users that ate stuck in IE7/8 are also behind corporate firewalls and often have limited or completely disabled JS. We can have reduced functionality when no JS but cannot completely break everything for them. Think that would happen if we use HTML 5 shim.
Mark Ayers 5:20 am on July 13, 2011 Permalink
Everyone always seems to forget that there is no need to support users at work. They should be doing work, not browsing people’s blogs.
Marvin Hagemeister 8:48 am on July 30, 2011 Permalink
As I understand these changes are intended for the admin area, the backend. The frontend is seperate and browser support depends on the chosen theme.
Ryan Imel 3:58 am on July 2, 2011 Permalink
Awesome. I’m on board.
I’m in agreement on 1-4. In looking over the files right now, it wouldn’t take long at all to do some basic merging of the stylesheets. I’m seeing some cleaning up that could be done during that step as well. It would take a bit more time to comb through for redundant/unneeded CSS and things that can be improved, but it’s definitely doable.
I’m ready to go, deadline sounds good to me. I’ll hold off on toying more until there’s a ticket to add to.
Jack 7:53 am on July 2, 2011 Permalink
As far as I know html5 elements will not accept styling in both ie7 & ie8 without declaring them first in js. So you’ll have to compromise on #1 to implement #4.
That said, you probably wont need to drop ie7 if some basic elegant depredations are acceptable.
Andrew Ozz 6:07 pm on July 2, 2011 Permalink
I’ll be running some tests for that today, perhaps you can run a few too and then will compare findings.
Jack 7:55 am on July 2, 2011 Permalink
Btw, i would REALLY like to be involved in this round, where do I go to read about how?
Andrew Ozz 6:09 pm on July 2, 2011 Permalink
Look out for new tickets on trac early next week.
jackreichert 6:10 pm on July 2, 2011 Permalink
Wonderful!
Denis 11:05 am on July 2, 2011 Permalink
Re the second point (SaSS), why not add a commit hook that auto-compiles it?
Andrew Ozz 6:12 pm on July 2, 2011 Permalink
Correct me if I’m wrong but you cannot compile .scss files from css. It has to be the other way around. In either case this would be better left as an individual choice (what tools to use).
WraithKenny 7:52 pm on July 6, 2011 Permalink
Someone would have to maintain the source files and keep them in sync for anyone to actually use a pre-processing library.
Seems like it can’t be much of a individual choice; it’s too much work, it’d need to be shared… perhaps in a github fork.
I do know that in some libraries, like LESS, you can compile .css to .css without issue as CSS syntax is valid LESS syntax. I’m sure it’s got to be the same with the other ones.
Andrew Ryno 3:28 pm on July 2, 2011 Permalink
I’m available for any work that needs to be done. Deadline works fine for me. I’d love to do a little more on 3.3 than I did on 3.2.
As far as HTML5 goes, I think it would be fine for a lot of elements if we simply used them and then just defined them as display: block; IE7 should be fine with that, but I can’t remember exactly.
And yes, we need to reorganize the CSS and rethink the way it’s handled. It’s a mess of files right now and is really frustrating when developing. Using 1 main file (plus *-rtl.css and the colors) with clearly defined sections would get my vote. And please, no pre-processors. Devs can use them if they want, but I think that everything included in core should just be a complete .css file.
jackreichert 6:10 pm on July 2, 2011 Permalink
Unfortunately declaring unknown elements as block in css just isn’t enough, even in ie8. All styles are ignored in ie up to ie9 without them first being declared via js.
Ref: http://diveintohtml5.org/semantics.html#unknown-elements
Andrew Ozz 1:07 am on July 3, 2011 Permalink
Right, it seems impossible to use HTML 5 elements in IE7 and IE8 without JS. Unfortunately IE8 is the highest version available for win XP (still used a lot, especially in Asia), meaning we won’t be able to migrate to HTML 5 anytime soon.
WraithKenny 8:23 pm on July 6, 2011 Permalink
Regardless of the new elements being js-only for IE users, we can still support the new input types
(they degrade gracefully) and the doctype.
Andrew Ozz 8:39 pm on July 6, 2011 Permalink
Agreed. We should use the new doctype in the admin.
Can you make a list of all HTML 5 elements that degrade well in IE8 and IE7 without JS plz (and of course test them).
WraithKenny 9:46 pm on July 6, 2011 Permalink
http://html5doctor.com/how-to-use-html5-in-your-client-work-right-now/ for a vetted complete list and extra info.
Andrew Ryno 2:17 pm on July 4, 2011 Permalink
Thanks for the info! I haven’t done much work with HTML5 without using the JS for it and not sure if it should be put into WP (it would be just another JS needed to be loaded).
Andrew Ozz 6:16 pm on July 2, 2011 Permalink
Yes, the magic formula for IE7 is “display: block; zoom: 1;”. I’ll be testing how well that works but more tests are welcome.
Joachim Kudish 5:29 pm on July 5, 2011 Permalink
What’s the big deal with having a js file for declaring the elements for IE7/8? I use that technique on every site I build (frontend) and it seems like a sensible solution these days, even for a backend…
In terms of IE7 support. I do think we need to wait before dropping it. Lots of corporations still use IE7 and users are stuck behind pesky firewalls where they can’t install any other browser. Such is the case for some of my clients who use WordPress.
I’d also like to be involved with this project as much as I can. I’ll keep track of the tickets on trac, and hopefully will be able to submit a few patches
jackreichert 8:38 pm on July 2, 2011 Permalink
Cool! Great trick!
Akif 12:34 pm on July 5, 2011 Permalink
I hope it works!
Matt 4:48 pm on July 5, 2011 Permalink
From a UI end user prospective, I always feel that I am opening a ton of pages to get my WP sites ready for launch. From adding plugins, to tweaking the widgets, adding pages, categories, posts, customizing menus. Not to mention if I need to edit multiple pages at the same time. I usually wind up right clicking and opening everything in a new tab in firefox, which gets confusing and annoying. It would be pretty sweet if I could open new tabs inside of the wordpress dashboard, or even if I could create groups inside of a specific tab, let’s say that there are 5 to 10 functions that I use most often ie. Pages, posts, widgets, a certain plugin, ect, if I could create a tab or page where I could gather all of my most commonly used functions into one location, it would save a ton of time. Rather than clicking through the sidebar nav menu that opens dropdown after dropdown until I have a menu that is a mike long. I could just click my home tab in the nav bar and instantly be back to my most used functions. Even better would be to incorporate an Mac expose style functionality, i have no idea if this is even possible, im just trying to stir up some thoughts in the community. Anyway, just some thoughts. Hoping to stir the pot a little.
Jane Wells 7:39 pm on July 6, 2011 Permalink
Definitely a power user feature, but an interesting idea. We’ve talked about letting people choose their start screen, having a setup completion meter, self-selected faves menu… all things aiming to solve the problem. I think the best approach would be to start it as a plugin until the UI is nailed, and then consider if it makes sense for core (or a core-supported plugin).
Leo_Nel 3:31 am on July 6, 2011 Permalink
Also, Microsoft will drop support for Vista SP1 on July 12. If I recall correctly, Vista’s default browser was IE7.
Jon Brown 6:06 am on July 6, 2011 Permalink
I understand wanting to maintain support for IE 7 & 8. IE8 at least still has a significant user base. However, requiring JS for that support seems a reasonable trade off and middle ground to move forward without completely leaving the past behind.
Personally I havent’ used modernizer yet, but I just recently used CSS3PIE on a site and it’s actually a pretty effective method for enabling CSS3 for IE7/8 (With the exception of the background element which requires uses -pie-background).
While I don’t think building SASS directly into core makes sense… if you are using it to build your CSS I think providing the SASS/SCSS source would be very cool.
WraithKenny 7:10 pm on July 6, 2011 Permalink
If you’ve got a Trac tag for this, maybe http://core.trac.wordpress.org/ticket/17959 would fit? It improves functionality of default wp tabs css and removes a bunch of dup classes.
WraithKenny 7:46 pm on July 6, 2011 Permalink
A preprocessor like LESS/SASS/Compass would be run for example when minification and concatination scripts run. Their use might effect patch writers, but not users.
Although it’s good to note here, that plain old CSS is LESS compatible, so contributes could probably still submit patches with old fashion plain CSS and it’d still compile. There’s also a PHP version of LESS that was forked prior to LESS.js (which runs on Node.js) and SASS/Compass runs on Ruby.
+1 for preprocessors.
Andrew Ozz 8:31 pm on July 6, 2011 Permalink
Perhaps we can try this as an external feature for one release cycle. Whoever wants to lead this can fork core on github and maintain the extra css/preprocessor files needed there.
If it’s successful, i.e. used and maintained by enough developers, we can think of implementing something in core.
thezman84 2:04 pm on July 7, 2011 Permalink
I’m new to the discussion here, but definitely not new to the world of CSS / HTML development. If I can lend a helping hand in any way, I’m on board.
I work just north of Atlanta and while the rest of the world may only be using only 7% – 8% IE7, that percentage is significantly higher in our area. While I personally would love to see the demise of support for IE7, our clientele would have a much harder time understanding why their admin doesn’t work on their computer anymore.
I do agree that using a .js file to overcome some of the greater differences is a fair trade-off for IE7 support. I also think that if you’re smart enough to turn off javascript in your browser, you know what to expect and you know how to turn it back on. Last time I checked, for the average user, javascript is enabled by default for every browser.
Nevertheless, I’m most definitely willing / wanting to help.
Andrew Ozz 9:04 pm on August 1, 2011 Permalink
There is quite strong support to drop IE7. Seems this will happen in 3.4. After consulting with other WordPress lead devs, seems it would be best to leave most of the CSS overhaul for then too as we won’t need to code for IE7.
However I think we should do the admin CSS files merge and duplicates removal for 3.3, https://core.trac.wordpress.org/ticket/18314. Perhaps even can sneak in some basic cleanup
saracannon 10:22 pm on August 1, 2011 Permalink
This sounds good. Basic cleanup and documentation is needed for sure & the merge is going to make things easier for responsive implementation rather than everything still scattered about. In our UI IRC meeting tomorrow, we should talk about the timing of the cleanup/merge with the responsive admin implementation.
saracannon 10:25 pm on August 1, 2011 Permalink
Also, do we have a document of WordPress Admin CSS formatting standards? If we don’t we should document that somewhere. (ie. `#CCCCCC` vs `#CCC` vs `#cccccc`) Everyone codes differently with spacing and shorthands and comments. It would be great to make sure we’re all on the same page.
(I don’t think the dot org style guide addresses code.. )
Andrew Ozz 1:04 am on August 2, 2011 Permalink
We have this: http://codex.wordpress.org/CSS_Coding_Standards that perhaps needs a little updating (not sure we need “Properties should be organized alphabetically inside each block” for example).
saracannon 6:51 pm on August 2, 2011 Permalink
awesome.
Daryl Koopersmith 7:25 pm on August 2, 2011 Permalink
+1 to polishing up the standards.
Andrew Ozz 4:36 pm on August 21, 2011 Permalink
Pinging everybody that wanted to participate, https://core.trac.wordpress.org/ticket/18314 is expecting your input
There are still a lot of duplicate and nearly duplicate styles in wp-admin.css, lets get rid of them all. The only thing while working on it would be to merge any uncommited patches before you start as it’s quite hard to merge css patches later.