WordPress.org

Ready to get started?Download WordPress

Make WordPress UI

Updates from Andrew Ozz Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Ozz 7:26 pm on September 26, 2012 Permalink  

    Recently a lot of “!important” stuff has made it’s way into our CSS. It’s really important that this doesn’t happen :)

    Proposing a new rule: if somebody wants to add !important in a patch, they would need to clear it in the weekly UI chat in IRC.

     
  • Andrew Ozz 8:01 pm on July 23, 2012 Permalink  

    Most links and buttons in the admin don’t have clear :focus and :active styling. This is a big problem when using the Tab key to navigate. There is usually no indication of what element is focused and if there is some, like on the admin menu, it’s quite weak/unnoticeable.

    Thinking we should add clear and visible styles for :focus and :active everywhere by default. If this is impossible to do without making the UI “ugly”, can add another global screen option “Enhanced Accessibility” or similar that would turn these styles on.

    Pinging all designers, if you come up with a nice solution, please add a screenshot (and possibly a patch) to ticket 21324.

     
  • Andrew Ozz 11:19 pm on July 1, 2011 Permalink  

    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 “CSS 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 core.
    3. Follow a light OOCSS approach. Agreed. Think this covers the “best practices” in CSS.
    4. 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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

        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 | Log in to Reply

        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.

      • WraithKenny 8:01 pm on July 6, 2011 Permalink | Log in to Reply

        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 | Log in to Reply

          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 | Log in to Reply

          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 | Log in to Reply

            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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

      Btw, i would REALLY like to be involved in this round, where do I go to read about how?

    • Denis 11:05 am on July 2, 2011 Permalink | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

          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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

          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.

        • Andrew Ryno 2:17 pm on July 4, 2011 Permalink | Log in to Reply

          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 | Log in to Reply

        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 | Log in to Reply

        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 | Log in to Reply

      Cool! Great trick!

    • Akif 12:34 pm on July 5, 2011 Permalink | Log in to Reply

      I hope it works!

    • Matt 4:48 pm on July 5, 2011 Permalink | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

        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 4:36 pm on August 21, 2011 Permalink | Log in to Reply

      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.

  • Andrew Ozz 4:04 pm on April 27, 2011 Permalink  

    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!

     
    • Kenneth Younger 7:11 pm on April 27, 2011 Permalink | Log in to Reply

      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 | Log in to Reply

        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.

    • easilyamused 8:01 pm on April 27, 2011 Permalink | Log in to Reply

      Count me In, been looking for something to get more involved

    • John Blackbourn 9:08 pm on April 27, 2011 Permalink | Log in to Reply

      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 | Log in to Reply

        plugin developers will have to adopt the new standarts.

        • Chelsea Otakan 9:34 pm on April 29, 2011 Permalink | Log in to Reply

          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 | Log in to Reply

          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 | Log in to Reply

            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 | Log in to Reply

      Should migration to HTML5 for admin be on schedule for 3.3 ?

      • Andrew Ozz 4:38 pm on April 28, 2011 Permalink | Log in to Reply

        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 | Log in to Reply

          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 | Log in to Reply

          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 | Log in to Reply

            +1

          • Ryan 12:49 am on April 30, 2011 Permalink | Log in to Reply

            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 | Log in to Reply

      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_Standards

      I’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 | Log in to Reply

        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 | Log in to Reply

        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 | Log in to Reply

        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 | Log in to Reply

      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 | Log in to Reply

      -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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

        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 | Log in to Reply

      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 | Log in to Reply

        • Chelsea Otakan 6:14 am on May 2, 2011 Permalink | Log in to Reply

          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 | Log in to Reply

            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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

      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 rather than using classes and IDs everywhere. We should also move this to global.css.

      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#doaction2

      But it could be better done with something like

      .wpbody > .wrap > .wp-lists-table > .actions > input

      and 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 | Log in to Reply

        Exactly, you said it better :)

      • Ryan Imel 10:33 pm on April 28, 2011 Permalink | Log in to Reply

        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 | Log in to Reply

      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.

    • Jack 9:36 am on April 29, 2011 Permalink | Log in to Reply

      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 | Log in to Reply

      +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 | Log in to Reply

        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 | Log in to Reply

          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 | Log in to Reply

          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 | Log in to Reply

            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 | Log in to Reply

      I’m all in this~ Would love to help as much as I can :)

    • Spencer Hill 3:06 am on April 30, 2011 Permalink | Log in to Reply

      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.

    • Melvin Ram 7:38 pm on April 30, 2011 Permalink | Log in to Reply

      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.

    • Melvin Ram 7:39 pm on April 30, 2011 Permalink | Log in to Reply

      How exactly should I go about this if I want to help? Make the changes and submit a patch?

    • pampfelimetten 5:26 pm on May 5, 2011 Permalink | Log in to Reply

      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 | Log in to Reply

      I think we can stick with latest FF rather then ff3.6 since they end-of-life’d even 4.0

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel