Author Archives: Andrew Ozz

Andrew Ozz 7:26 pm on September 26, 2012  

Recently a lot of important stuff has…

Recently a lot of “!important” stuff has made it’s way into our CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site.. 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 UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. chat in IRC.

Andrew Ozz 8:01 pm on July 23, 2012  

Most links and buttons in the admin don’t…

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 UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. “ugly”, can add another global screen option “Enhanced 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). (https://en.wikipedia.org/wiki/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  

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 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 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). (https://en.wikipedia.org/wiki/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 tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. 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 Ozz 4:04 pm on April 27, 2011  

The big CSS overhaul in 3.3

Following the discussion at the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. irc meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. yesterday, I think it’s time to start planning for the CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. 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 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. 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!