WordPress.org

Make WordPress Core

Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 9:28 pm on April 5, 2015 Permalink |
    Tags: , , bikeshed,   

    Updates to the default admin color scheme 

    Over on Make/Design, @hugobaeta has posted about some subtle updates to the blues and grays of the default admin color scheme. Work on updating the admin has been completed in #31234. For those who are using those colors in their development, particularly any large areas of colors such as backgrounds, you may want to take a moment to update those values. There’s a handy guide to the changes on the post.

    While we haven’t yet settled on a sensible and semantic way to provide helpers or utilities for these kinds of CSS changes, thoughts and eyes are welcome on #26691 for that.

     
  • Helen Hou-Sandi 7:08 pm on December 19, 2014 Permalink
    Tags: , , , ,   

    Core CSS: A potential roadmap to sanity 

    At the community summit, we discussed a core CSS roadmap, initially a discussion about preprocessors in regard to their role in WordPress, both in the admin and in bundled themes. Recently, there has been significant discussion about the initial use of a preprocessor in the development of Twenty Fifteen that was not included when it landed in core. We discussed what role preprocessors may play with our default theme development and core WordPress for the long term.

    In this post, you will find some history, some observations, and an outline of where we can go next to bring some sanity to our admin CSS as well as move into the future.

    (More …)

     
    • Kevin Miller 7:08 pm on December 19, 2014 Permalink | Log in to Reply

      Any chance of an Admin Style Guide getting done with all of this as well? It’s long over due in my opinion

      This was a good start https://github.com/helenhousandi/wp-style-guide

      • Helen Hou-Sandi 7:10 pm on December 19, 2014 Permalink | Log in to Reply

        Yep, that’s what the pattern library is about. I didn’t get into much specific detail for the roadmap, but my goal would be for the generated documentation to serve as both visual test material as well as a publicly accessible guide for developers.

    • mindctrl 7:39 pm on December 19, 2014 Permalink | Log in to Reply

      What’s the proposal for collecting statistics and performance data?

      • Helen Hou-Sandi 9:12 pm on December 19, 2014 Permalink | Log in to Reply

        Nothing proposed yet, this is “just” a roadmap. I’m sure there will be many discussions and a lot of work to come.

      • Aaron Jorbin 9:58 pm on December 19, 2014 Permalink | Log in to Reply

        Now that this published, there will be a build/test tools roadmap that mentions some potential options for collecting these statistics. That roadmap will be published by the end of the year.

    • PeterRKnight 7:56 pm on December 19, 2014 Permalink | Log in to Reply

      As a plugin developer I continually have issues trying to get my UI to match the look and feel of the rest of the admin, but it’s a real tedious business without some kind of preprocessor functionality. One thing that might go less noticed is how various classes and elements are tied to javascript logic.

      When using common css classes (so you don’t have to add custom css) often comes with surprises. For example, you can’t easily replicate the accordeon-like panels that are used by widgets without creating new css classes. If you have a spinner element somewhere in your UI, you have to watch that it’s not activated by some other WordPress script because the selector used by a WP script is broader than it needs to be. There’s all kinds of these little issues like these that crop up that make working alongside the native admin css not so fun..

      It would be great to see a clearer approach so that it becomes easier to build custom components that utilize native styles and desired patterns. How javascript is being used to target elements based on css classes is something that shouldn’t be overlooked.

      • Michael Arestad 9:31 pm on December 19, 2014 Permalink | Log in to Reply

        I know the pattern library will help in those areas. We could maybe even a section specifically designed to help plugin authors use components in a friendly way.

    • Morten Rand-Hendriksen 8:50 pm on December 19, 2014 Permalink | Log in to Reply

      This looks like a solid plan. Creating standards and a pattern library will make future development and 3rd party development much easier and more consistent.

      IMO the preprocessor discussion is a distraction. It’s a conversation about tools when the real issue is with the code itself. It is a conversation worth having, but it is one that only makes sense once everything else is in place.

    • Konstantin Obenland 8:56 pm on December 19, 2014 Permalink | Log in to Reply

      Great post Helen, thank you!

      newer contributors who are often put off by issues such as the sheer volume of styling or the potential for uncaught side effects

      I’ve been contributing for a while now, but when it comes to admin CSS, I definitely consider myself a “new contributor”. In one ticket I worked on in 4.1 that touched the admin CSS, the potential of uncaught side effects really affected my confidence in my proposed patch. It’s a LOT to grasp and to double check.

      CSS is one of the languages I consider myself more familiar with, so I would love to get involved and help out in any way I can.

      • Michael Arestad 9:33 pm on December 19, 2014 Permalink | Log in to Reply

        Part of what we discussed was implementing a system that compares before/after of each view so you can be alerted if a certain percentage changes on particular views. This would be handy to help ensure a CSS change isn’t breaking other pages.

      • Andrew Nacin 10:49 pm on December 19, 2014 Permalink | Log in to Reply

        I’ve been contributing for a while now and I don’t go near admin CSS.

    • Morgan Estes 10:24 pm on December 19, 2014 Permalink | Log in to Reply

      I did some work about a year ago with trying to get the Sass files inline with the existing CSS coding style guides. Looks like it’s time to take a look at it again and see where I can help.

      https://core.trac.wordpress.org/ticket/26905

    • Gary Jones 10:12 am on December 22, 2014 Permalink | Log in to Reply

      I’ve looked into the tools available or a while, and here are my thoughts on tools that are not already in use (cssjanus, autoprefixer etc.).

      grunt-wp-css is a wrapper for CSSComb (and currently CSS Beautify), which is pre-configured to format CSS to match the WP CSS coding standards. CSSComb is great, but not if everyone has to setup their configuration each time and stay up to date with changes in the coding standards. The default config for the Grunt package also has an opinionated order of properties, which match the suggested grouping in the standards, and it includes fixes not found in the default CSSComb configs.

      CSSComb can also apply to Sass (though it’s waiting on the rule-delimiter property to be supported), so having the same coding standards generally apply as it does to CSS would make sense. Sass has some extra features not covered by CSSComb though, and like the difference between JSCS and JSHint (coding standards vs coding practices), grunt-scss-lint can be used to state and automatically test against these areas.

      One of the big advantages of Sass I find, is being able to put media queries (MQs) right inside (or after) the selector that’s being affected, instead of creating a disconnect and pushing all MQs down several hundred lines to the bottom of the file or into a new file. Keeping the code modular is better for organisation – new contributors don’t have to worry about looking elsewhere for declarations that would also need to be changed. The initial disadvantage of this though, is that the resulting CSS has multiple MQ wrappers for each breakpoint or condition. This can be fixed with grunt-combine-media-queries though, which unwraps MQ blocks and re-wraps them with one MQ block per breakpoint or condition and pushes them all to the bottom. That gives the best of both worlds – code in context when developing, code following the cascade in production.

      It’s a different mindset that some can’t get their head around, but mobile-first styles (i.e. use of min-width in MQs) can make for simpler and reduced code – your styling from one end of the range and working in one direction, instead of starting in the middle and working in both directions. Taking advantage of the natural 100% width of elements means only having to split that into multiple-columns when the screen is wide enough, instead of giving that from the start, and then having to re-define 100% when the screen is small enough. The initial disadvantage of mobile-first is that IE8 and below doesn’t support it. However grunt-stripmq can take a stylesheet and generate a version for IE that has media queries stripped out, so that the desktop styles always apply over the original small-screen styles. In the context of concatenated output from load-styles.php and any intent to bump the minimum version of IE supported above 8, this may not be worthwhile now, but still worth considering if it was the only objection to wanting mobile-first styles.

      grunt-colorguard is a handy tool for finding color values that are extremely similar, but not exact, so that the number of unique colours can be dropped. This also then simplifies the task when using variables within admin Sass to ensure consistency.

      An alternative pattern library to consider is Hologram (which can also be used via grunt-hologram). It looks for inline documentation blocks inside .scss (or .css, .md or a few other file types irrelevant to WP) and produces a living style guide. It supports JavaScript inside the component demos. It’s not a WP plugin, and the output is standalone to any WP install.

      Whatever guidelines and code standards are developed, I’d like to see them be discussed in terms of how suitable tools can be configured to automatically test against them. This removes far more ambiguities than a textual explanation alone, and more importantly, it’s something the whole community can use, not just core.

      • Helen Hou-Sandi 3:09 pm on December 22, 2014 Permalink | Log in to Reply

        Yes, a large piece of this is utilizing and expanding the tooling setup we have now to enable steps forward. We will have meetings to hash out details as we start moving along this roadmap. Thanks for such a great start!

        • Gary Jones 3:47 pm on December 22, 2014 Permalink | Log in to Reply

          I’d really love to see a separate Make group (and Slack channel) for build tools, code standards, pattern libraries, static analysis of current code etc. Basically everything that falls under development practices or methodologies covering the how, not the what that Make/Core covers.

          I think it’s a big enough topic to garner discussion and expertise that fall outside of just how Core works, which can be influenced by, and report back to Core, but can be applicable to both core and code in the wider WP community. Think how Accessibility and Polyglot aspects have their own groups, and can direct core development, but can also influence the wider community.

          Is that something that can be looked into / how do I convince folks it’s needed?

          • Helen Hou-Sandi 8:01 pm on December 22, 2014 Permalink | Log in to Reply

            My instinct would be to continue to include that where we currently do (Make/Core, for the most part) and split off if it truly proves to be distracting or overpowering. I don’t see why Make/Core couldn’t cover more – I often wish it did.

            I would also be loath to hindering progress on this roadmap, which is already years in the making. There are so many areas that go beyond what specifically needs to be accomplished here – preprocessors, PHP, etc. I am not questioning the material, but rather the committee-first approach.

            • Gary Jones 9:00 pm on December 22, 2014 Permalink

              I don’t see it being a distraction from core, but I do see the rest of core being a distraction from being able to discuss the roadmap and move it forward. Splitting taxonomy terms, Menu Customizer and DFW changes, for instance, have little direct impact on whether SCSS is used for generating wp-admin styles, or which grunt tools to use to do X, or why the code standards need to have Y documented. The former are the outcomes, while the latter is the processes.

              Folks can be in both Slack channels, and follow both Make/ groups, but it allows those who have an interest in standards, Sass, Grunt or other tooling, to have their own focused area.

              WordPress has grown organically, and the items you’ve listed, once achieved, will definitely help the project, but I feel that a project 11.5 years mature shouldn’t need to still be looking at such basics as naming conventions and coding standards. A group (or at least a Slack channel) to drive it forward can have those discussions and present them to the rest of the community for feedback, in the same way that Accessibility and Polyglot groups have established themselves.

            • Aaron Jorbin 9:56 pm on December 22, 2014 Permalink

              “Accessibility and Polyglot groups have established themselves.” The key thing you are pointing out with both of those groups, is that they have established themselves. I don’t think there has been any demonstration that another group dedicated towards tooling has established itself.

              I personally think that the creation of more groups distracts people. Groups should form organically and when they have demonstrated that they are a separate group, we create the space for them not the other way around.

    • Pete Schuster 2:30 pm on December 22, 2014 Permalink | Log in to Reply

      If we’re going to make the switch to SCSS it would be nice to implement a Linter as well to keep things tidy. I also have some proof that property sorting reduces file size as well: http://peteschuster.com/2014/12/reduce-file-size-css-sorting/

    • Helen Hou-Sandi 7:27 pm on December 23, 2014 Permalink | Log in to Reply

      I am following along with/participating in the CSS Chassis project: https://github.com/jquery/css-chassis/, as I feel that this is a great opportunity for us to play nicely with other major projects. I think we will likely influence each other – for instance, the decision has been made to use the BEM naming convention (recognizable by its double dashes and double underscores), which was a specific item discussed at the community summit and something I believe we can adopt as well.

  • Helen Hou-Sandi 6:18 am on October 10, 2014 Permalink
    Tags: , ,   

    Scalable Dropdowns update 

    In our initial meeting on Wednesday (IRC log), we outlined some steps and a fairly aggressive timeline to get ourselves in a place where changes to wp_dropdown_users() (#19867) and wp_dropdown_pages() (#9864) are suitable for patch review.

    To that end, we’ve opened a handful of issues on GitHub for work and discussion, so that we can track completion. These tasks include evaluating various accessibility areas (touch, mobile, keyboard, screen reader), creating a JS wrapper, UI skinning, and page hierarchy representation. Please check them out and participate as you are able and willing. Let’s keep those issues task-oriented, however – any other questions or comments can go here.

     
  • Helen Hou-Sandi 2:53 am on October 8, 2014 Permalink
    Tags: , ,   

    Scalable Dropdowns and More, chat on 2014/10/8 

    In 3.9, I started taking a look at solving some long-standing scaling issues with dropdowns, notably those for users (#19867) and pages (#9864). I arrived at a conclusion about our mixed usage of autocomplete and autosuggest far too late to make it for 3.9, and did not add it to my plate for 4.0, but would like to tackle it again for 4.1.

    We can solve these issues smartly by using a combination of Ajax-powered autocomplete/suggest and smart defaults, e.g. users with the most content pre-loaded for quick access without having to run a search. As a brief overview of where I see us going with this – a roadmap, if you will: user dropdown, page dropdown, current instances of jQuery UI autocomplete (multisite users and new site), tags/nonhierarchical taxonomy UI, more built-in taxonomy UIs (#14877), and possibly more as we discover appropriate places. Not all of this will happen in 4.1 – think of this as not only a solution to long-standing, painful problems, but also a step in a series of many.

    To that end, we will be holding an initial chat at 19:00 UTC on 2014/10/8 to get things moving. @ericlewis and I have begun early development as a plugin – for more, see this particular branch, which experiments with using Select 2 as a JS helper library for the UI.

     
    • Jon Brown 7:03 am on October 8, 2014 Permalink | Log in to Reply

      I’m new and don’t know the history… I am not trying to reopen any debate. I’m wondering though if using Select2 is fairly settled? (Not because I have a personal preference between Select2, Selectize.js and Chosen, but rather I’d like to know how others wiser than me decided between them).

      • Helen Hou-Sandi 8:47 am on October 8, 2014 Permalink | Log in to Reply

        No hard decision has been made – that’s why it’s one branch in the plugin repo. Chosen doesn’t do Ajax/search on its own and Selectize is licensed Apache-only, though.

        • Jon Brown 2:19 pm on October 9, 2014 Permalink | Log in to Reply

          Ah… forgot APL2 is not compat with GPLV2 only compat with GPLV3. Anyway, was just wondering. I’ve used Select2 and Chosen a bunch in that past. Selectize looked like it had better tests and was lighter was all.

      • Dan Griffiths 10:33 am on October 8, 2014 Permalink | Log in to Reply

        Regarless of the licensing issues, Select2 has by far the best feature set of the three.

    • Max Bond 10:07 am on October 8, 2014 Permalink | Log in to Reply

      Don’t focus only on dropdowns!
      WordPress problem is wider – how to select wp data objects (post types entities, taxonomies, users) inside other objects.
      For example I have two custom post types: order and product. And I need to add product to order. Sounds simple, but there is no standard interface for such select! If needed to add user to order – the same interface should be used.
      Autocomplete/suggest – is good, but not enough. May be to use some kind of popup window (like media library)?

      • Helen Hou-Sandi 4:39 pm on October 8, 2014 Permalink | Log in to Reply

        We need to start with fixing long-standing bugs in existing functions, namely wp_dropdown_users() and wp_dropdown_pages() as linked in the Trac tickets above. As I said, there may be more possibilities as we take each step. If you have a citation for autocomplete/suggest not being good enough, I am all ears.

    • Gabriel Reguly 12:33 pm on October 8, 2014 Permalink | Log in to Reply

      I won’t be able to attend the chat, but would love if you do take into account the dropdown for sites in multisite installs.

      http://wpjourno.com/my-sites-toolbar-menu-wordpress-multisite/

      Cheers,
      Gabriel

    • Ben Hansen (ubernaut) 6:47 pm on October 8, 2014 Permalink | Log in to Reply

      sounds great!

  • Helen Hou-Sandi 11:39 am on September 3, 2014 Permalink
    Tags:   

    4.0 release plan update 

    If you’ve been following along with IRC and Trac activity over the last 24 hours, you’ll have noticed that there’s been a lot of it. We’ve had a number of issues pop up, and thus did not reach the targeted freeze of 16:00 UTC on 2014/09/02. If you haven’t been following along, I highly recommend it :)

    Given that, our new release target is shifted back one day to 16:00 UTC on 2014/09/04. We’ll still kick off two hours beforehand with various pre-launch checks and tasks. This means code freeze by 16:00 UTC on 2014/09/03 – just a few short hours from now. I would also like to run a number of those pre-flight checks in the hour or two before freeze to give us an early chance to squash anything that may come up during those. To that end, an RC2 has been built for final testing.

     
  • Helen Hou-Sandi 3:41 am on September 1, 2014 Permalink  

    4.0 release plan and 8/27 meeting summary 

    Per dev chat on 8/27 (summary below), we are targeting a release of 16:00 UTC on 2014/09/03, kicking off at 14:00 UTC on 2014/09/03 in #wordpress-dev. There are a number of steps to go through, including running unit tests, checking build, and testing various update and installation scenarios. We’ll also do a dry run at the same time on Tuesday, 9/2, before we enter a 24 hour code freeze.

    I’d also like to meet at 18:00 UTC on 2014/09/01 in #wordpress-dev to clear out all open tickets for 4.0 and do an RC2. It is a holiday (Labor Day) in the US, but I will be around throughout the day, as will other committers and contributors.

    Summary of 8/27 dev chat (IRC log):

    (More …)

     
  • Helen Hou-Sandi 8:04 pm on August 27, 2014 Permalink
    Tags: ,   

    RC1 is here! Proposed agenda for today’s meeting:

    • What’s come up in the hours since RC1 was released?
    • Keep an eye on support forums and bugs reported against trunk. Great time for triage of non-4.0 tickets as well.
    • Plugin developers: update your readmes and add an icon!
    • Interesting post on wp-hackers. Feedback welcome.
    • Codex page.
    • Any blog posts we need to write for developers?
    • Are there any plugins we need to ship to show off or extend 4.0 features?
    • Release plan.
     
  • Helen Hou-Sandi 7:07 pm on August 25, 2014 Permalink
    Tags: ,   

    I’d like to hold an impromptu scrub of remaining 4.0 tickets in about an hour at 20:00 UTC. @nacin and I triaged most tickets earlier today and feel confident that we can finish everything out and get to RC.

     
  • Helen Hou-Sandi 4:13 pm on August 13, 2014 Permalink
    Tags: ,   

    All hands on deck for 4.0 Beta 4 and RC 1 

    We’ve been pushing really hard to get to a place where a final beta and then RC phase are appropriate for the 4.0 development cycle.

    This impacts a few things:

    • The release date (currently scheduled for August 27, in just two short weeks).
    • Finalizing help and about page text, and thus string freeze (and, therefore, translators).

    With the help of everybody who’s contributed to this release thus far, we’ve done a really great job with the features we’ve been working on and the overall ticket queue for this milestone. All of that said, we need your help to get the following done:

    Needed to reach the final beta

    • #28328: Focus on editing, while editing (editor scrolling improvements). There is a comment that outlines a few things we feel need at least consideration before we consider this release-worthy. @stephdau has been working through patching – testing of patches is greatly appreciated, as are bug reports (as always).
    • #28842: Media Grid: Bulk selection mode. User testing and further feedback have led us to give a separate selection mode another try. @ericlewis has been doing very heavy lifting throughout the cycle on the feature. There is a patch for testing (not for commit) along with some observations on ticket. Once again, testing and UI/UX observations are very welcome. If you would like to help with patching, please let us know and we can coordinate to avoid duplicate efforts.

    Needed before RC1

    • Commit or punt all tickets currently slated for the 4.0 milestone. Anybody can help by testing/writing patches or marking tickets for commit or punt using keywords. If you’re not sure, feel free to ask in IRC, on ticket, or just move to the next one.
    • Triage all tickets reported against trunk. This is especially important in the RC phase, as we need to monitor things reported against trunk for bugs introduced in the cycle, particularly regressions. Many tickets opened against trunk will apply to earlier versions – please change the version field as appropriate to reflect that. It may help to filter out anything already milestoned for 4.0 or Future Release.
    • QA sweeps across browsers and devices, particularly on new features and checking CSS for anything introduced that may not work in IE8 or in some cases IE7. For instance, any usages of CSS calc() need to have a fallback for IE8 and older.

    If you’d like to tackle something you see here and would like a little more direction to get started, please leave a comment below or head over to #wordpress-dev in IRC. One or more core developers is likely to be around at most hours.

    Finally, for today’s dev chat at 2014-08-13 20:00 UTC, let’s take a quick look at the above, note any other blockers we see, and get people assigned to tasks/tickets as we can.

     
    • Robert Chapin 5:54 pm on August 13, 2014 Permalink | Log in to Reply

      I can’t make the meeting but I am subscribed to the Formatting component in case anything comes up. Have a good one. :)

    • Mattias Tengblad 1:01 am on August 14, 2014 Permalink | Log in to Reply

      One HUGE blocker for RC1 is that the translators have ZERO strings to translate yet. String freeze anyone? What so freaking hard with communication between groups? Will look really good to have an all new language packs installer with no up to date languages.

  • Helen Hou-Sandi 7:42 pm on August 6, 2014 Permalink
    Tags: ,   

    Proposed agenda for today’s dev chat:

    Please propose any other items you might have in the comments.

     
    • Stephane Daury (stephdau) 7:48 pm on August 6, 2014 Permalink | Log in to Reply

      #27440 only has one issue left (as of .3 patch, .4 to be discussed), and I could use some help with it: UI for section tabs in small screens: they wrap, and mess the layout up.

      Making that a menu was discussed in last week’s chat, but I found it to be meh (extra clicks, etc) in my tries.
      I had in mind to try what an horizontal scrolling bar (as some native apps do), with a visual cue that there’s stuff to the right/left to scroll to, but the CSS is giving me trouble, and I’m empty handed right now.

    • Nick Halsey 7:51 pm on August 6, 2014 Permalink | Log in to Reply

      #28979 should be finalized one way or another before RC as mixed priorities would require a lot of churn (probably introducing a new section-panel parent class, renaming a file, etc.).

    • quangn 9:36 pm on August 6, 2014 Permalink | Log in to Reply

      I have question how about adding “shuffle” and auto play in the player for audio music? I really miss this feature and I wrote several posts about this and it seems no one replied to me :(

    • Mattias Tengblad 12:20 pm on August 7, 2014 Permalink | Log in to Reply

      For the love of god, think of the children…ehm…I mean the translators. Two ~ weeks left to release? We need information, and strings to translate!

    • rajlaksh 5:38 pm on August 9, 2014 Permalink | Log in to Reply

      Is Categories will become like TAGS System? Easy to browse?

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
Skip to toolbar