WordPress.org

Make WordPress Core

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • K.Adam White 7:58 pm on November 13, 2013 Permalink | Log in to leave a Comment
    Tags: Build Tools, , JSHint   

    Finding and Fixing JavaScript errors with JSHint 

    The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

    JSHint is a tool to check for errors in JavaScript code. As was discussed last week, we’re kicking off a small effort to work through our core JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docs team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

    At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (@username #xxxxx) are already claimed, and being worked on.

    Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

    How to contribute:

    1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
    2. Update your local WordPress SVN to the latest version of WordPress trunk (currently 3.8-alpha).
    3. Create a new ticket on Trac for the file.
      JSHint-related trac ticket settings

      • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
      • Assign the ticket to the “Build Tools” component.
      • Make sure your email is stored in Trac’s preferences

      If you are logged in, you can click this link to automatically open a ticket with the right settings.

    4. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN checkout. If you are working on a large file, consider making multiple patches for each type of change.
    5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

    *Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

    Keeping Discussions Focused:

    Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

    Files needing patches:

    Checked files are now passing JSHint

    See all open tickets in the Build Tools component

    For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

    For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

    grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

    What we’re NOT doing

    The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

    Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.

     

  • Andrew Nacin 5:58 pm on November 13, 2013 Permalink
    Tags:   

    Proposed coding standards change (always require braces) 

    Our current PHP coding standards specify that for if statements, “single line blocks can omit braces for brevity.” All other constructs “should always contain braces as this enhances readability, and allows for fewer line edits for debugging or additional functionality later.” I’d like to propose we always require braces for all blocks.

    One could argue about coding standards all day (not in this comments thread), but allowing braces to be omitted is probably the only thing in our standards that can cause legitimate problems, like making it easier to introduce errors. It also makes code more annoying to patch and less maintainable, and requires larger diffs. And, it’s more work to debug code, as you have to add braces to add debugging lines, then remove them when done. It’s easy to attempt to add a new line inside the conditional and screw it up, which has occurred even a few times in the last few weeks. For example:

    if ( some_conditional() )
    some_new_line();
    return some_function();

    Another catalyst here is our new JavaScript standards. Due to multi-line chaining and other situations, it is basically insane to omit curly braces in JavaScript. It would be nice if our standards matched, making this the right time to raise the issue for PHP. Our coding standards have a general emphasis on whitespace and readability, and the lack of braces do generally make code feel lighter and easier to scan, but I think we’ve reached a breaking point. I’ve surveyed the other lead developers and the consensus was that while omitting braces is elegant, it doesn’t best serve the needs of the project (with many people editing many things often).

    I’d like to discuss this during today’s meeting, and ideally make a decision.

    I will mention that adopting this will mean all new code will receive braces. We can discuss what to do with existing code. Please don’t waste any time on a patch to add braces manually; we’d script it and do it in one commit if that’s the route we decide to take. (There’s more than 8,000 structures lacking braces.) Also worth reading in preparation for a discussion is a section in Linux’s contributor documentation on coding style pitfalls, something I’ve linked to before.

    P.S. This wouldn’t change bracing placement. It’s still like this:

    function func_name() {
    if ( some_conditional() ) {
        echo "Braces shall be 'cuddled,' not pushed to the next line."
    } else {
        echo "For all control structures.";
    }
}

    Update: This proposal was accepted during the Wednesday meeting. I’ve updated the coding standards handbook page. We’ve yet to discuss what we’ll do for old code, but all new and changed code should receive braces.

     

    • Bryan Petty 6:09 pm on November 13, 2013 Permalink

      Just thought I’d point out that this would make our control structure guidelines PSR-2 compatible, not that it should be a deciding factor, but it certainly doesn’t hurt.

      • Ryan McCue 2:13 am on November 14, 2013 Permalink

        We’re still incompatible in numerous other ways, like: tabs instead of spaces (yay tabs!), opening braces for functions/etc being on the same line (yay!) and my old favourite, spaces everywhere (BOOOO). :)

    • Weston Ruter 6:21 pm on November 13, 2013 Permalink

      +1

      Filed a issue to add this to the PHP_CodeSniffer rules: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/issues/124

      By the way, we’ve been working on a script for PHP_CodeSniffer which will only apply the rules to files and the lines in these files that have changed, that is, it will only report errors on uncommitted code. This would make PHP_CodeSniffer suitable for use in WordPress Core, as it would guide developers to apply the rules for new code but leave old code alone. The script is called phpcs-patch: https://github.com/x-team/PHP_CodeSniffer/blob/phpcs-patch/scripts/phpcs-patch

    • nofearinc 6:28 pm on November 13, 2013 Permalink

      That’s incredible improvement given the hundreds of issues with the copy-paste of a second statement added to an if clause getting executed outside.

      As a reminder, we’ve been adhering to this in Java for a long time – http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#449

    • Scott Taylor 6:31 pm on November 13, 2013 Permalink

      I’d grown to like bracelessness, but ok. #thanksobama

      • Mike Schroder 9:55 pm on November 13, 2013 Permalink

        Yeah. I tend to agree that some statements *look* better without the braces.

        But, in terms of core, it seems safer to begin requiring them — at the very least for new code.

    • Peter Chester 6:36 pm on November 13, 2013 Permalink

      +1 I’ve always felt that explicit braces improve legibility.

    • Ian Dunn 6:40 pm on November 13, 2013 Permalink

      +1 because of consistency (internally and with the JS guide), and not having to add braces for debugging and then remove them.

    • Beau Lebens 6:47 pm on November 13, 2013 Permalink

      I’d definitely agree with this. My 2 biggest reasons would be consistency with JS, and ability to add/remove debug info easily without introducing bugs.

    • Tom Auger 6:47 pm on November 13, 2013 Permalink

      +1 even though I like the no braces construct myself, I definitely agree for all the reasons Nacin lists.

      • Tom Auger 6:50 pm on November 13, 2013 Permalink

        Although, what about allowing 1-liners, like:
        if ( $braceless_condition ) echo “1 – liner only”;

      • Franz Josef Kaiser 9:13 pm on November 13, 2013 Permalink

        And what about one-liners like this one?

        defined( 'ABSPATH' ) OR exit;

      • Andrew Nacin 11:06 pm on November 13, 2013 Permalink

        But this whole thing was about taking one-line conditions and always requiring braces. One line, no line break was against our current standards and would continue to be against these.

        A construct like defined( 'WPINC' ) or exit; remains OK — of course, in limited use, pretty much only for this right here.

    • Stefano Aglietti 6:55 pm on November 13, 2013 Permalink

      IN my day developping of theme plugins etc I qlways add braces even for single line i prefere, less problem if code evolves and editor i use (PHPstorm show better the code and it show up clearer. +1 to Nacin proposal

    • Marcus 7:00 pm on November 13, 2013 Permalink

      Yes please!

      Lack of braces is one thing I really dislike about the WP coding structure but have learnt to live with.

      I use braces by habit and aside from easier readability, it avoids copy/paste errors or editing code. Would love to see that practice in core too!

      As Tom Auger suggested, I think one liners are acceptable and do use this approach these days, mostly thanks to the code in core :)

    • Ryan Hellyer 7:16 pm on November 13, 2013 Permalink

      I recall finding conditionals very confusing when I first started out. I immediately grok’d how braces worked, but “if ( bla == blob ) : ” confused me, and omitting braces or and endif REALLY confused me.

      I’ve grown to not care about this issue, but I suspect I’m not the only person who got flummoxed by this when they first started out.

      I started using braces for (almost) everything about a year ago, but had been omitting them for a long time as I thought they were the recommended practice since I saw them in core all the time.

    • Per Soderlind 7:27 pm on November 13, 2013 Permalink

      +1, I allways use braces, been using them since I learned C in the 80ies, even for 1-liners

    • Doug Wollison 7:32 pm on November 13, 2013 Permalink

      +1, especially on the consistency with JS angle; might as well get them as close as possible.

    • Jeff Rose 7:32 pm on November 13, 2013 Permalink

      +1 I’m a relative newb, but I much prefer the explicit braces and consistency

    • Paul Gibbs 8:11 pm on November 13, 2013 Permalink

      I support leaving the code standards as they are. I prefer leaving braces out on short, simple, and uncomplicated IFs because there’s less visual noise to read when you are scanning code; it makes the code more readable, as is briefly alluded to in the post.

      It is always possible for accidents to occur when writing or reviewing code; without leaning too heavily on the example given, any codebase will still occasionally receive other similar, easily-overlooked errors. Requiring braces will just change the type of problems and their consequences. I don’t see a net win here.

      Using IDEs for development can also make it easier to debug or inspect values at certain points in execution with breakpoints. It’s something I am trying to do more often in my own work, because it stops me making any changes to the codebase that I’m rushing through, perhaps making quick and messy changes for debugging! Sometimes a debugger is a better tool than print-based debugging, though of course, the inverse is also true.

      • Ryan McCue 2:15 am on November 14, 2013 Permalink

        One of the other reasons it’s nice is that it reduces noise in patches. Adding a line to a single line if means changing 3 lines, which is visual noise when you’re reviewing. I like excluding them occasionally, but the diff noise is what ruins it for me.

    • Joan Boluda 8:21 pm on November 13, 2013 Permalink

      +1 because of consistency

    • John Blackbourn (johnbillion) 8:44 pm on November 13, 2013 Permalink

      I’d like to discuss this during today’s meeting

      I think we have better things to discuss. Please just do it and save everyone a mostly pointless conversation.

      • mattyrob 9:43 pm on November 13, 2013 Permalink

        +1 to that ;) And the original idea too.

    • Matt van Andel 9:17 pm on November 13, 2013 Permalink

      I have but one thing to say about this…

      YES

    • Lance Willett 9:50 pm on November 13, 2013 Permalink

      +1 even though I’m used to it, the reasons you mentioned outweigh the habitual.

    • Chip Bennett 10:41 pm on November 13, 2013 Permalink

      +1, which, coming from the resident pedant, should come as no surprise. :)

    • Mike Schinkel 10:42 pm on November 13, 2013 Permalink

      Like Matt van Andel said:

      YES!

      This will make it possible to set breakpoints for debugging on all lines of code with PhpStorm (and other PHP IDE debuggers.)

      And if you are looking for the first candidate for this, please update template-loader.php with this new standard, or bless the task and I’ll do it.

    • Arnan de Gans 11:04 pm on November 13, 2013 Permalink

      I agree with this idea :) plugin and theme makers should do this also.

    • Robert Chapin 12:43 am on November 14, 2013 Permalink

      Braceless ifs always bothered me, not because of inserting extra lines, but because PHP also supports two braceless ‘else’ syntaxes that confuse the hell out of me.

    • Brad Davis 12:45 am on November 14, 2013 Permalink

      +1.

    • jarednova 1:37 am on November 14, 2013 Permalink

      +1. Braceless-ness is one of those “timesaving” things that actually costs more time. Clarity > Brevity

    • photocrati 3:06 am on November 14, 2013 Permalink

      You’re just kickin’ in an open door with this suggestion …

    • Edward Caissie 3:11 am on November 14, 2013 Permalink

      As my alter-ego said … you’re kickin’ in an open door with this suggestion.

    • Andrew Nacin 4:21 am on November 14, 2013 Permalink

      This proposal was accepted during the Wednesday meeting. I’ve updated the coding standards handbook page. We’ve yet to discuss what we’ll do for old code, but all new and changed code should receive braces.

    • Nashwan Doaqan 11:01 am on November 14, 2013 Permalink

      +1 even though I’m used to it, I will update all my plugins code :)

    • Tom McFarlin 1:58 pm on November 14, 2013 Permalink

      +1.

    • contempoinc 6:12 pm on November 14, 2013 Permalink

      +1

    • Danny van Kooten 6:33 pm on November 14, 2013 Permalink

      +1

    • Barry Kooij 6:48 pm on November 14, 2013 Permalink

      +1

    • dimitrov.adrian 8:19 am on November 15, 2013 Permalink

      This is good approach, but I think that this is right time to suggest some more things. It’s about the space usage.

      my_function( $param1, func_param( $param2 ) );

      why just not

      my_function($param1, func_param($param2));

      IMO in most cases this make code more hard reading

      Also, I think using of predefined constats (true, false and null) should be in uppercase – TRUE, FALSE and NULL

      In this order I think that code standards of Drupal (https://drupal.org/coding-standards) can help here, as they try to follow PEAR code standards.

      • Christian Foellmann 10:40 am on November 15, 2013 Permalink

        I dont think we should change one of the most basic conventions of WP coding standards.

      • Andrew Nacin 1:50 pm on November 15, 2013 Permalink

        Sorry, I can’t ever see these rules being changed. Long live whitespace. Let the code breathe. :-)

    • Christian Foellmann 10:36 am on November 15, 2013 Permalink

      +1 for “always require braces”

    • Gregory Karpinsky 12:10 pm on November 15, 2013 Permalink

      +100000!!! Finally!

  • Lance Willett 6:11 pm on November 12, 2013 Permalink | Log in to leave a Comment
    Tags: , ,   

    Twenty Fourteen Project Update 

    Crunch time! We’re working hard to make sure everything’s ready for 3.8 release. We’ve listened to all your feedback, thank you—including lots from last week’s dev chat. We’ve made significant improvements in the last week.

    Many improvements

    Author widget

    Too late to get it into 3.8 dev? It’s fairly light and can merge right away.

    Last week at 3.8 features-plugin meeting we forgot to suggest this; we’d worked on it as a plugin first, see #24856: “Authors widget to highlight authors.”

    This is a new widget for any theme to use, but we’d planned to show it off with Twenty Fourteen because as a magazine theme it’ll feature and show off multiple authors.

    On our radar

    • Strategy for 3.7 and earlier non-MP6 handling #25906
    • Accessibility feedback on the slider
    • More work on contextual help and the user experience with Twenty Fourteen, maybe including user testing and research
    • Launching the theme on WordPress.com to get early feedback from real usage
    • Code review with core dev team
     

    • jeffr0 6:14 pm on November 12, 2013 Permalink | Log in to Reply

      Did you folks already have your meeting today?

      • Nick Halsey 6:18 pm on November 12, 2013 Permalink | Log in to Reply

        We’ve mostly just been looking at a few remaining things casually, you could definitely jump in with any questions/comments/feedback now (in #wordpress-themes).

      • VenturaVan 6:50 pm on November 12, 2013 Permalink | Log in to Reply

        Can anyone tell me if there is any work being done on colorizing the menu system? I am sooo tires of having to pay for custom plugins that sometimes break to make my menu’s colorful. Top level one color, second level another, third level another, etc. etc and being able to change those per category or per page.

        • Lance Willett 7:12 pm on November 12, 2013 Permalink | Log in to Reply

          Colorizing the menu isn’t part of the scope for this theme. The Accent Color option allows to change from the default green hue, though.

  • Scott Taylor 4:06 pm on November 12, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Featured Content: Epilogue 

    If you’ve been following along with 3.8/Twenty Fourteen development, you probably know that Featured Content is being handled by the theme now. It is being moved to the Customizer. This approach is wildly different that what I was doing in the plugin, and I am ok with that. Their approach is lighter weight and might be all a theme needs to display a section of featured posts.

    My original idea after @obenland approached me to work on it was way more complex, and it was something  that might not belong in core. Or it might, but the plugin didn’t make a compelling case – once again, no biggie.

    What did we learn from this?
    Having multiple active developers is a must. 15 people had commit, and our meetings had a healthy share of lurkers, but we only had one person doing development. I became the bottleneck for everything, which was enjoyed by no one.

    I like the idea of using plugin development to drive feature development. For plugins to be successful projects, I think the teams working on them need to be staffed properly. I think our team went into like “oh cool, we’ll all kinda work on it and then it will happen” – wasn’t the case. We could have benefited from more planning and tasking.

    The Future
    If anyone would like to continue working on the plugin, please do. I would prefer to focus on core development instead.

     

    • Lance Willett 5:26 pm on November 12, 2013 Permalink | Log in to Reply

      I look forward to seeing this come back in a future “features-as-plugins” sprint.

      • @ubernaut 5:50 pm on November 12, 2013 Permalink | Log in to Reply

        agreed think that it’s a crucial feature for any content driven site and every theme seems to have it’s own solution, would be good i think to have something more universal.

    • Manny Fleurmond 2:13 pm on November 15, 2013 Permalink | Log in to Reply

      Wouldn’t it have made sense to use widgets to do this?

      • shaunandrews 2:19 pm on November 15, 2013 Permalink | Log in to Reply

        I think so, but all I can think about these days is widgets. I think a “Featured Content” widget would have (and still does) make a lot of sense.

  • George Stephanis 10:17 pm on November 11, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    The Search Initiative 

    The Search Initiative

    IRC Chat Log

    In Attendance:

    • George Stephanis
    • Ryan Boren
    • Samuel Sidler
    • Mark Jaquith
    • Helen Sandi
    • Sarah Goodling
    • Matt Mullenweg
    • Andrew Nacin

    We opted to begin by reevaluating what pain points we believed there currently were in the WordPress admin around search.

    These are just what we came up with in the chat, please comment afterwards with any additional issues you’d like to see considered. Some of these are pretty big issues, and could easily be spun off into seperate projects. This looks like it is shaping up to be a significantly larger endeavor than was initially run as Omnisearch.

    Current Problems to Solve (The Status Quo) (Because the status is NOT quo)

    1. We have a lot of search forms in the admin, and it’s troublesome to have to find / navigate to the type of thing you want to search before actually searching it. (#)
    2. When searching, often it’s difficult to know / overly vague why a specific result has been included in the result set. (#)
    3. Not all relevant information is searched. I may have relevant data stored in a postmeta field, but it’s not indexed for searching. (#)
    4. When searching, and no results are found, the user hits a ‘dead end’ — no suggestions or path forward is offered. (#)
    5. Navigation is often tricky to find a menu item (seen time after time in user testing videos). Possibly suggest admin pages as the user is typing their query? (#) — Related plugins: Jarvis and WP-Butler
    6. We don’t currently support syntactically-aware search queries. “Comments by [user]“, “Posts in [category]” etc. (#)
    7. There is currently an inconsistency in the adminbar search field. It displays on the front-end of the site, but not on the admin side — due to WordPress not having a unified search results page to send people to on the back-end. (#)

    I feel that 1, 4, and 7 are the most similar and the solution for both would be more a single unit, whereas 2, 3, 5, and 6 are more distinct and could be done in parallel or in subsequent iterations.

    Possible road forward:

    Have a Global Search Page, with some sort of tabbed interface. There would likely need to be an ‘Overview’ tab, and then for each different data type being searched, its own tab. Generic search forms (like the adminbar search) would land on the overview, but if the initial search form designated which bit of content they’d like to search (for example, using the search form on the admin posts page), send them directly to its respective tab, the content of which would be akin to the current search results pages currently dispersed throughout the admin.

    We would be able to add in the adminbar search form to the admin (yay consistency) and even auto-suggest based on links off of the current page (akin to Jarvis or WP-Butler) — or leave that to plugin territory.

    Parallel projects on the rest would be terrific, as I don’t personally see them as interdependent. They could be iterations or new groups could spring up to tackle them.

    That’s what I’ve got, now I’d love to hear your use cases, feedback, and where you’d like to see this headed. Let’s get the feedback in early this time, folks! :)

     

    • Scott Kingsley Clark 1:22 am on November 12, 2013 Permalink | Log in to Reply

      I built the Filters plugin to expand on providing a better UX for searching and filtering on multiple fields and taxonomies at once. It uses Thickbox inline but I plan on integrating the Media Modal possibly instead, for a nicer UI with a less buggy popup.

      http://wordpress.org/plugins/filters/

      I would hope that any solution that is built, can support filtering my fields and taxonomies in a better way than it is now.

      • George Stephanis 3:38 pm on November 12, 2013 Permalink | Log in to Reply

        We’d certainly welcome your input as this develops. As someone with prior experience building an addition to the search experience, it’d be invaluable input.

    • Dwain Maralack 6:09 am on November 12, 2013 Permalink | Log in to Reply

      I love the global Admin search bar and think Ajax search should be built in as the has become the standard.

    • RicaNeaga 2:49 pm on November 12, 2013 Permalink | Log in to Reply

      Please consider if a third-party search api is a viable solution (to be included / implemented alongside wordpress installation).

      For example vbulletin now bundles sphinxsearch.com , and they say for large websites (with large databases) this addition is a ”performance enhancement that will allow you to offload search from your MySQL database”.

      • George Stephanis 3:35 pm on November 12, 2013 Permalink | Log in to Reply

        I don’t believe it’s something that we would bundle with core, but — as I remarked above — the hooks will certainly be in place that a third-party provider could provide a plugin to replace or supplement existing results if desired.

  • Matt Thomas 7:33 pm on November 11, 2013 Permalink | Log in to leave a Comment
    Tags: , fonts, open sans   

    Open Sans, bundling vs. linking 

    In Wednesday’s 3.8 planning meeting we discussed hotlinking vs bundling Open Sans. MP6 followed Twenty Twelve’s example by linking to Google Webfonts, but the consensus from Wednesday’s chat was that bundling would be preferable.

    I began experimenting with this last week; first determining which font formats were necessary to include. I settled on WOFF and SVG as the two formats that would cover every browser we’re aiming to support. I left out TTF and EOT as they add only marginal browser support (IE8), but would add significant weight to the WordPress download. We do include TTF and EOT versions of Dashicons, since loading those icons is essential to usability in a way that loading Open Sans is not.

    The bundled Open Sans webfonts come from FontSquirrel. The Western Latin and Basic Latin subsets are small and include enough characters for English language support. Those subsets do not include a full set of glyphs for other languages, however (they’re available as separate downloads). There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers. The Western Latin and Basic Latin subsets can cause missing characters (spaces or boxes) to appear in text using accented characters, which is a significant usability concern.

    Google Webfonts solves both the character set and the font format problems by intelligently loading the font format and the character subset that’s needed for a particular browser and a particular website, and nothing more. For us to bundle Open Sans with WordPress, we need a way to accomplish that without adding significant heft to the core WP download. I’m starting this P2 thread to open up the discussion on how we might do that.

     

    • Matt Mullenweg 7:43 pm on November 11, 2013 Permalink | Log in to Reply

      It’s also worth noting if we can solve this in a standalone way (the script not loading any of the rest of WP) we avoid licensing issues and also solve a general problem many people across the web have.

      Also keep in mind if this takes longer than a few days the right answer for 3.8 might be linking in core and releasing a plugin for people that bundles for people that don’t like Google.

      • Piet 4:28 am on November 12, 2013 Permalink | Log in to Reply

        I think it doesn’t have so much to do with liking or not liking Google. There are certain countries where Google is blocked and that includes loading their fonts. For all sites I built (I live in China), I bundle fonts, because only then I can be sure that these fonts load.
        That might be another argument pro-bundling :)

    • Doug Wollison 8:41 pm on November 11, 2013 Permalink | Log in to Reply

      Regarding the missing characters, don’t just about all browsers fallback to the next font in the font-family list for those characters?

    • mindctrl 8:46 pm on November 11, 2013 Permalink | Log in to Reply

      Relying on a third party for fonts in core doesn’t make me want to do cartwheels. It’s a backdoor analytics of sorts, and a privacy concern. The increased file size is the lesser of two evils. Neither option is ideal.

      I love Open Sans, but given the two options, I’d rather see Arial. *runs for cover*. I just tested swapping out Open Sans for Arial in trunk, and it’s really not that bad. Theming the WP admin/MP6 via plugins would be a great way for people to opt into hosted font solutions.

      • Doug Wollison 9:21 pm on November 11, 2013 Permalink | Log in to Reply

        Or, the better compromise; Helvetica (Neue if possible), finally falling back to Arial if things get desperate.

        • mindctrl 9:26 pm on November 11, 2013 Permalink | Log in to Reply

          I thought the same thing originally. Helvetica Neue isn’t that bad, but it’s also not standard on a number of platforms. Neither is Helvetica. This was news to me. I don’t know of a definitive list online, but this one from MailChimp is helpful, and the reason I said and tried Arial. http://templates.mailchimp.com/design/typography

          • mindctrl 9:27 pm on November 11, 2013 Permalink | Log in to Reply

            Sorry, actually standard Helvetica is.

            • jwarren 11:09 am on November 13, 2013 Permalink

              If we’re going with system fonts, it should probably just be standard ‘san-serif’, which will be Helvetica on OSX, Arial on Windows, and whatever has been deemed appropriate on the Linux distro of choice. It also allows people and browsers to override that easily for their own purposes – perhaps a different language, perhaps extra visual clarity, perhaps an unusual display technologo… who knows?

    • Robert Dall 9:41 pm on November 11, 2013 Permalink | Log in to Reply

      I have never really like relying on a third party service to do what could be done internally.

      Also what if you are developing locally without access to the internet?

      Regardless of who provides the free service. One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Now it would be easy to swap it out but why rely on something like that anyways.

      • Matt Thomas 9:50 pm on November 11, 2013 Permalink | Log in to Reply

        To be clear, we’re talking about linking to Google Fonts for Open Sans just until we can solve this in a standalone way, as @matt mentioned above.

        If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

    • Ryan Hellyer 10:04 pm on November 11, 2013 Permalink | Log in to Reply

      I suspect that bundling scripts into WordPress core will create privacy concerns for many people. The ability to perform analytics via them will disturb a small segment of the user-base.

      It may even be illegal in some countries. Germany springs to mind in regards to that. They’re already super ticked off about being spied on at the moment, so I think it might be best if WordPress doesn’t join the party too.

      And yes, you can install a plugin to force them to be self-hosted, but many people will just unwittingly hit the “update” button without ever realising that they’re opening themselves up to privacy issues.

      • Doug Wollison 10:10 pm on November 11, 2013 Permalink | Log in to Reply

        What if we take a progressive enhancement approach? By default, we wouldn’t actually load Open Sans from anywhere, and instead just falls back to whatever font it can. Then we offer plugins (or packaged right in the core) options for self hosted or google hosted.

      • daveshine (David Decker) 11:49 pm on November 11, 2013 Permalink | Log in to Reply

        Almost any modern theme loads Google Fonts already, including some of the default themes, plugins not counted…

        I have absolutely nothing against loading Open Sans from Google, and find it a rather good option to do so.

        Yes, there are lot of issues with privacy that should be done better – in my opinion this topic here falls not amongst them…. just my personal view.

        Thanks, Dave from Germany :)

    • Dion Hulse 11:14 pm on November 11, 2013 Permalink | Log in to Reply

      There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers.

      If we actually want to use Open Sans for WordPress, this is unfortunately what we have to do.

      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic) weighs in at 576K uncompressed (92K WOFF, 484K SVG), 174K compressed.
      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 4.5MB uncompressed (345K WOFF, 4.2MB SVG), 826K compressed.

      The SVG’s will compress well as they’re just text, WOFF is already compressed. We could have a light-weight PHP script that served compressed documents intelligently depending upon the client (selectively adding Charsets based on WPLANG / browser UA), but this has caching issues amongst other things.

      If we actually look at what the fonts are for though…

      • WOFF is the primary font, it’s supported by most browsers.
      • SVG is included for iOS 3.2-4.3 support, and for Android Browser 4.0-4.3.

      Given the significant size of SVG fonts, it makes me question if we should be using them at all, it doesn’t add much extra browser support.

      An alternative is shipping with WOFF+TTF fonts – that would add support for iOS 4.2-4.3 (iOS 3.2 misses out), and Android 2.2-4.3 (SVG only works for 4.0-4.3).

      • Open Sans (WOFF+TTF for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 1,000K uncompressed (345K WOFF, 661KB TTF), 689K compressed.

      or.. just drop Open Sans for those mobile clients.. since it really doesn’t seem worth it.. WOFF supports most desktop browsers and modern mobile devices, and we should have a GOOD font fallback list for unsupported browsers (which we don’t currently have with MP6, but we did previously have in WP 3.6).

      • Dion Hulse 11:22 pm on November 11, 2013 Permalink | Log in to Reply

        I also missed that SVG is also for Mac Safari 3.2-5.0, not just for iOS. TTF is supported in Safari 3.1-5.0 as well.
        TTF/SVG is also needed for older Opera versions (desktop and mobile, and some gaming systems), but WOFF is supported for v11+ so that doesn’t seem like a deal breaker at all (coming from an Opera user..)

      • Matt Thomas 11:48 pm on November 11, 2013 Permalink | Log in to Reply

        I don’t recommend using the un-subsetted font for any solution because of the extra page weight that every user would incur. Intelligently loading the correct subset for the specified language is the best possible user experience, whether it’s linked to from Google fonts or we implement our own solution that accomplishes the same result. Just for comparison, this is the size difference for a single weight and style of Open Sans (we need four: regular, italic, semibold, and semibold italic).

        • English subset, WOFF: 13 KB
        • Czech subset, WOFF: 17 KB
        • Full charset, WOFF: 85 KB
        • English subset, SVG: 32 KB
        • Czech subset, SVG: 70 KB
        • Full charset, SVG: 1.1 MB

        • Dion Hulse 12:01 am on November 12, 2013 Permalink | Log in to Reply

          So yes, I’d never suggest SVG for this.. ever..

          WOFF however, we can get away with including the full set, the extra page load isn’t significant once it’s in the cache.

          Most web services will get away with only loading one subset as they know what the characters on the page are, WordPress doesn’t really know the answer to this, French accented characters can appear in an English post, etc.. so relying upon WPLANG is a rather bad idea for this.

          One method would be to have Javascript detect the characters on the page and load the english by default, and optionally load the larger CSS if it spots any of those characters..

          Even Google Fonts requires you to specify which subsets you want to load, it can’t automatically guess what’s on the page.. so it’ll have the same page load issues (except that you gain benefit from their extra-special browser compression and CDN).

    • davelab6 5:30 am on November 12, 2013 Permalink | Log in to Reply

      Disclaimer: I consult for Google, Adobe and other companies on web fonts and libre fonts issues, but I represent only myself. This is my own personal opinion.

      One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Anyone can see that Google uses the Fonts API for its own web apps and web pages. Since the fonts are libre licensed, if that day ever comes, switching is possible.

      If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

      If you’re working locally, you can install the fonts, and if the CSS includes them with ‘local’ (as the Google Fonts API css does) then they’ll load :)

      For WordPress to self host the fonts, in a way that matches the fonts served by Google’s Fonts API, you’ll want to subset them by language, and also have versions with the hinting removed to serve to browsers on platforms that don’t use hints, and perhaps also CFF versions for platforms with good CFF rendering. Since WordPress doesn’t have a dynamic font subsetter, you’ll need a set of language subsets and a set of hint subsets.

      WOFF, SVG, TTF, EOT is needed for full browser support, in descending order of importance. If you leave out formats, you will leave out users. Maybe that matters, maybe it doesn’t.

      By using the Google Fonts API you support all users on all platforms. The API doesn’t carry a cookie, so there aren’t the same privacy implications.

    • jwarren 11:14 am on November 13, 2013 Permalink | Log in to Reply

      I would suggest that bundling would be ideal – who know what strange systems WordPress could be running on if/when Google eventually deprecates their fonts service? It also keeps the experience consistent for any isolated environments. Local development away from a consistent internet connection is not an infrequent occurrence, and the fewer 404s, the better.

  • K.Adam White 9:48 pm on November 5, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    JavaScript Coding Standards 

    The PHP files in WordPress core become cleaner and easier to read with every release, thanks in part to our standards for PHP code style. Our JavaScript, on the other hand, hasn’t gotten nearly enough love. This post is intended to open up the recent discussion around JavaScript style to the greater community so we can make up for lost time.

    Don’t we already have a style guide for JavaScript?

    Back in March, @tommcfarlin added a set of coding standards for JavaScript to the developer handbook. These WordPress JS coding standards are a great work-in-progress, but weren’t fully comprehensive (leading to some comment threads clarifying various areas). More importantly, without any clear implementation plan the style guide failed to gain traction.

    At WordCamp Boston’s core contributor day I revisited this style guide with @mattwiebe and Corey Frang (@gnarf37). It is important to identify *and implement* conventions for JS style ASAP because syntax issues in the JS within WordPress may hide latent bugs, and inconsistent code discourages contribution. Focusing on implementation lead us to look for an existing, proven JS style guide with a .jshintrc file (a set of configuration options for the JSHint code quality tool) which we could adopt largely as-is: Getting JSHint in place lets us see the biggest issues in our JS, so we can begin tackling them incrementally (perhaps in the same manner as the inline docs effort).

    After looking at Idiomatic.js and several other widely-adopted JS style guides, we feel the jQuery Foundation’s jQuery Core JavaScript Style Guide guide is the closest match for what we need in WordPress.

    Adopting the jQuery Core JavaScript Style Guide

    jQuery’s guide shared WordPress core’s love of white space—the same “when in doubt, space it out” mantra from the existing JS style page. Moreover, jQuery’s code conventions have been referenced in trac tickets as an example of how we should be writing our code. Adopting their guide wholesale capitalizes on our stylistic similarities, and will let us adopt their .jshintrc and any future code quality tools they write with minimal changes.
    (More …)

     

    • Pbearne 9:55 pm on November 5, 2013 Permalink | Log in to Reply

      I will be happy do a bit of this.

    • deltafactory 9:57 pm on November 5, 2013 Permalink | Log in to Reply

      I’ve been thinking about threequals and curly-braces since Boston. It’s hard to break the habit.

      I’d like to help with the cleanup effort. It would benefit me to familiarize myself with more of the JS bits of WordPress.

    • Mike Bijon 9:58 pm on November 5, 2013 Permalink | Log in to Reply

      After reading the summary in email, my only concern was jQuery’s use of double-quotes vs. ours … seeing the longer article, that’s handled and I can’t think of any reasons to object.

      On the + side, adopting jQuery’s standards wholesale should reduce maintenance & debate. Plus, getting started sooner than later to *any* standard should help speed JS work & maybe help a few overly-debated JS tickets in Trac.

      Looking forward to seeing the sprint schedules

    • adamsilverstein 10:27 pm on November 5, 2013 Permalink | Log in to Reply

      Great post, thanks! I will try to make the meeting tomorrow and assist in the cleanup effort.

    • Matt Wiebe 10:46 pm on November 5, 2013 Permalink | Log in to Reply

      I have another (virtual) meeting at the same time, but I should be able to chime in.

      Thanks for pushing this forwards @kadamwhite :)

    • ericsherred 10:59 pm on November 5, 2013 Permalink | Log in to Reply

      Sounds like fun to me.

    • Dion Hulse 12:07 am on November 6, 2013 Permalink | Log in to Reply

      Wouldn’t it be better for us to standardise on for ( var i = 0; i < 100; i++ ) { instead of including var outside of the iterator? IIRC, including it outside was for some rather old browsers that we no longer (and probably haven’t for a long time) supported.

      • Andrew Ozz 1:12 am on November 6, 2013 Permalink | Log in to Reply

        As far as I remember defining all vars at the beginning of the scope mimics the actual way the script is parsed. Don’t think defining vars in the middle or end was a problem in any browser.

        • Dion Hulse 1:19 am on November 6, 2013 Permalink | Log in to Reply

          I thought I’d heard a rumour of an early IE bug.. but you’re probably right, defining it earlier is most likely only a parsing optimization, something we probably don’t need to worry about.

        • Tom McFarlin 1:52 am on November 6, 2013 Permalink | Log in to Reply

          +1 to this.

          Including all var declarations at the beginning of the function is how the script is parsed, and for those who are fans of JSLint, you’ll notice that combining all var declarations together is preferred[0].

          0.http://www.jslint.com/msgs.html

        • K.Adam White 2:14 am on November 6, 2013 Permalink | Log in to Reply

          As Tom notes, Andrew is correct—Variable declarations are “hoisted” to the top of the function’s scope, so declaring all your variables first is a best practice (it unifies the code’s visual structure with how it is parsed by the JS engine). There’s actually a “onevar” parameter in JSHint to enforce this style.

      • WraithKenny 2:10 am on November 6, 2013 Permalink | Log in to Reply

        I think it’s better, considering `for ( i = 0; i < 100; i++ ) { … } … var i = 2; alert( i );` would be confusing ('100') because of hoisting.

    • Andrew Ozz 1:47 am on November 6, 2013 Permalink | Log in to Reply

      Re-reading jQuery Core JavaScript Style Guide again: apart from the single/double quotes, other differences are the lack of indentation for `case` in `switch` and the hard limit to 100 characters per line (counting tabs as 4 chars). All of the rest more or less match our PHP and current JS coding standards. We also (used to?) have few more, like the strong discouragement of using nested ternary operators.

      So the question is: should we adopt the jQuery standard “wholesale” and depart from our PHP coding standard or should we continue to keep our PHP and JS coding standards as close as possible?

      • Tom McFarlin 1:58 am on November 6, 2013 Permalink | Log in to Reply

        I’m for the adoption of jQuery standards as much as possible; however, I do err on the side of keeping the JavaScript closely-related to our PHP coding standards (which is what I tried to do with the first draft of the standards).

        The reason being is that I don’t think we, as developers, should have to maintain two different set of standards.

        When working on client-side code, I often find myself thinking What’s the server-side standard for this, again? and then I try to apply that.

        Because I – and I’m sure most of us – are so familiar with the PHP standards, perhaps we should implement a “when it doubt, default to PHP standards.”

      • K.Adam White 2:26 am on November 6, 2013 Permalink | Log in to Reply

        I’m of a case-by-case mind on this. For example, I’ve encountered very few situations where >100 characters in a line were truly needed (and not just a symptom of hard-to-read or overly-nested code), so I’d be inclined to keep that. On the flip side, I’m all for keeping indentation rules consistent with PHP.

        Thanks for raising these questions, this is exactly what we need! Both here and during tomorrow’s chat I hope to identify any other differences between our PHP style and the proposed guide, and make decisions about which way to go. We’ve already identified a few areas in which we want to go a different way than jQuery. It’s a useful set of default behaviors, but what style guide we adopt isn’t what’s important—what is important is that consistency.

        • Andrew Ozz 2:47 am on November 6, 2013 Permalink | Log in to Reply

          Yes, the “around 80, max 100 chars” limit might eventually surface when something has many levels of indentation (5 – 6 tabs). This is not so hard to hit with longer jQuery chains which should probably be broken on multiple lines. Thinking it may be nice to have it as a rule in the PHP coding standard too, just not sure if it needs to be enforced.

    • Tom McFarlin 2:02 am on November 6, 2013 Permalink | Log in to Reply

      I’m going to try to make it to the meeting – what server and channel will the meeting take place?

      • K.Adam White 2:12 am on November 6, 2013 Permalink | Log in to Reply

        Good point, that’s something people need to know: Freenode, right in #wordpress-dev. (Note: That time was selected because I was not aware of any conflicting meetings; If anybody has a meeting in #wordpress-dev scheduled at that time, please let us know and we’ll get another room!)

    • Paul Clark 4:09 am on November 6, 2013 Permalink | Log in to Reply

      Count me in for a JSHint sprint!

    • Gary Jones 9:22 am on November 6, 2013 Permalink | Log in to Reply

      Not sure I can make it tonight, so I’m leaving my thoughts here that hopefully someone can take into consideration during the meeting.

      General adoption of the jQuery standards: +1
      Two exceptions to those standards: +1

      Would like to see a push towards named rather than anonymous functions = more self-documenting code, fewer nested levels -> avoid hitting line limits, reduce complexity.

      Consider use of ‘es3′ option in .jshintrc, since WP still needs to support IE8-9, and that will catch use of reserved words being used as properties with dot notation etc.

      I’m up for helping out with some JS tidying.

    • K.Adam White 1:00 am on November 10, 2013 Permalink | Log in to Reply

      Just a heads-up for everybody waiting for an update on this: Hang tight for a day or two, I’m working with @kpdesign to get the JS Standards handbook page updated and up to our standards.

    • Lance Willett 3:36 am on November 12, 2013 Permalink | Log in to Reply

      Thanks for your work on this—more vigorous standards and cleaner code FTW.

  • Helen Hou-Sandi 8:18 pm on November 5, 2013 Permalink | Log in to leave a Comment  

    #22862: Consider a CSS preprocessor 

    In #22862, it was proposed that core move to using a CSS preprocessor. Given that we now have the appropriate tooling in place and MP6 has been greenlighted for preparation to merge into core, it is time we hash this out: which, if any, CSS preprocessor should we use, why that particular one, what does implementing it take, and what does the contribution process look like? Some of this discussion has already taken place on-ticket, which is great, including a ton of proof-of-concept patching by @wonderboymusic.

    For further reference, MP6 currently uses SCSS for its color schemes, with a branch that demonstrates what it would look like in LESS. Many thanks to @ryelle for maintaining the LESS branch. By no means does this dictate what happens in core itself, but it is certainly an influence and a great data point.

     

    • Helen Hou-Sandi 8:18 pm on November 5, 2013 Permalink | Log in to Reply

      Here’s my personal opinion:

      Current admin CSS is heavily ID-based, generally overqualified, and insanely clunky to maintain after having been merged into one giant sheet (see #18314). I see very little benefit in putting effort into truly converting wp-admin.css in its current state (sorry, @wonderboymusic), especially given back-compat concerns. What I do think we can benefit from is going back to separate, modular files, and taking advantage of a build process to concatenate them for actual use. Yes, I do know that a preprocessor can do that in a build process, too. :)

      I imagine a build process could do something like this:

      1. For the purposes of SCRIPT_DEBUG and people who start in browser inspector tools, concatenate all non-color admin CSS files into one large unminified wp-admin.css, with comments added that denote where the development files are located and where each section starts to help with patching. If there’s a standard that web inspectors use or are beginning to adopt (e.g. source maps), we should take advantage of that.
      2. For production usage, minify the concatenated version, as it does now.

        3. Basically, the current wp-admin.css and wp-admin.min.css would still exist and essentially be as they are now, but patches would be against smaller, easier to digest files. This does raise the barrier to contributing actual patch files, but I think we should be open to helping people create patches out of notes from something like a web inspector (which does occasionally happen now, too, for what it’s worth).

        Bonus: we could also take advantage of an awesome tool like Autoprefixer (https://github.com/ai/autoprefixer) to automate that part of the CSS development process, rather than adding and removing vendor prefixes manually, and still missing them sometimes. Again, yes, I know preprocessors can do this with mixins (which have to be written/maintained) or libraries like Compass.

        Color schemes are pretty awesome with use of a preprocessor, as I’ve long suspected. We should do that as a starting point.

        In general, I think that a conversion can also espouse the iterative improvement philosophy – in this case, we can start with color schemes and really test out our tools and development process (including better documentation) in practice. In time, we may/probably will find areas where moving a file/component to being processed makes sense.

        Finally, I still have no preference when it comes to LESS vs. Sass. They don’t seem fundamentally different to me, even in practice. Sass in the form of scss seems to be gaining momentum in general.

      • Aaron Jorbin 8:37 pm on November 5, 2013 Permalink | Log in to Reply

        I love the idea of autoprefixer and concatenation as a first step. I’m happy to work on the grunt tasks for this if you want me to mock something up.

      • Scott Taylor 8:49 pm on November 5, 2013 Permalink | Log in to Reply

        Concatenation would be killer – as long as that 2 million line file is broken, I am happy.

        Outside of that, I don’t plan on doing any CSS, so it doesn’t *really* matter to me which is picked. I prefer LESS, and it’s what we use at the Times, but whatevs.

      • kkalvaa 10:22 pm on November 5, 2013 Permalink | Log in to Reply

        When you say “truly converting wp-admin.css” are you refering to changing to class based selectors? Or even going for OOCSS/SMACS/BEM?

    • nofearinc 8:21 pm on November 5, 2013 Permalink | Log in to Reply

      I like Sass as being backwards compatible with CSS, i.e. it would make no difference (in theory) if all the CSS is moved to Sass and it would require no conversion for starters, however enhancements and simplification would probably drastically improve the level of maintenance.

      Decoupling the file to smaller chunks and just combining on generation is also a good option.

      • Helen Hou-Sandi 8:34 pm on November 5, 2013 Permalink | Log in to Reply

        FWIW, I think LESS has the same compatibility without actual alterations.

        • nofearinc 8:43 pm on November 5, 2013 Permalink | Log in to Reply

          Wasn’t sure, last time I checked it wasn’t complete, but I might as well be wrong (or it could have been updated).

          • Andrey "Rarst" Savchenko 8:12 am on November 6, 2013 Permalink | Log in to Reply

            Wasn’t complete how? LESS maintained that valid CSS is valid LESS as far as I can remember, as well as getting plain non-compile CSS imports later.

            I cannot make sense where the lack of compat complaint keeps coming from, as far as I know it was never an issue (unlike SASS with their first syntax).

          • Remkus de Vries 8:26 am on November 6, 2013 Permalink | Log in to Reply

            you should see what LESS 1.5 had added to the mix; it’s quite complete nowadays.

    • nphaskins 8:24 pm on November 5, 2013 Permalink | Log in to Reply

      +100

      LESS is a little friendlier and easier to learn vs SASS IMO. I use LESS with every project. I’d also like to point out that Bootstrap opted for LESS instead of SASS.

      With this type of approach we can really start to get real color automation in place. Example, choose a base color and like items are styled appropriately. This lets devs cut down on options as well.

    • Jeff Behnke 8:30 pm on November 5, 2013 Permalink | Log in to Reply

      I think this will end up a opinionated discussion, since its going to be what ever the commentator is used to.
      Not sure how to solve that. (Voting) ?
      I agree that Sass in the form of scss is picking up speed. I actually prefer it over Less, but again thats an opinion.

      • Helen Hou-Sandi 8:33 pm on November 5, 2013 Permalink | Log in to Reply

        I sat on this post for weeks (months?) because I stress about starting wars of opinion :) Voting sounds nice, but I don’t think a vote would be a final decision, so it’s sort of misleading. We’ll just parse general sentiments out of comments, I suppose.

    • Travis Northcutt 8:50 pm on November 5, 2013 Permalink | Log in to Reply

      As many have noted, this is largely a personal opinion thing. However, for anyone who isn’t already familiar with one or the other or both, the following comparisons may prove informative:

      http://css-tricks.com/sass-vs-less/
      https://gist.github.com/chriseppstein/674726

    • Pbearne 8:53 pm on November 5, 2013 Permalink | Log in to Reply

      It may come down that we are PHP programmers and know where the $ key is!

      Pick one and import the current CSS and break out overtime ;-)

    • PeterRKnight 8:59 pm on November 5, 2013 Permalink | Log in to Reply

      I think Less is the more accessible of the two with more familiar looking syntax, also Lessphp is an excellent library to use and is extendable.

      • Bryan Petty 9:13 pm on November 5, 2013 Permalink | Log in to Reply

        When you say “accessible”, what do you mean?

        Also, note that when @helen mentions “appropriate tooling”, she’s referring to our Grunt build system, which would end up either using grunt-contrib-less for LESS, or grunt-sass for SCSS. LessPHP isn’t even necessary or being discussed anymore as we aren’t talking about bundling a compiler with WP anymore (Grunt has made this fairly pointless).

        • PeterRKnight 12:26 am on November 6, 2013 Permalink | Log in to Reply

          I admit to not being fully up to date on the latest SCSS/Sass syntax, I remember it looking more like a programming language in places (which a lot of people think is a pro). Further, what I like about using LessPHP is that it can compile on the server and plugin developers can extend it. Compiling via grunt or otherwise require dependencies that makes things less accessible (installing ruby/node.js etc). Having said that, I’m not sure how much these arguments apply to what’s being discussed here. I just chimed in because I’m superhappy with my lessphp workflow.

    • Amy Hendrix (sabreuse) 9:05 pm on November 5, 2013 Permalink | Log in to Reply

      Just to get clear before we get further into I Like Chocolate vs. I Like Peanut Butter, I’m pretty sure that adopting Sass would mean using SCSS syntax, not old-style (indented) Sass. It’s been the default in Sass for several years now, and is essentially the only thing being used any more except by a few HAML and Ruby fan holdouts.

      In that case, the “syntax is more accessible” and “easier to learn” arguments are basically moot. Both of them use a “Looks like CSS with some variables and stuff mixed in” syntax.

      That said, I prefer Chocolate. Err, Sass. Mostly because it’s what I already use.

    • Chris Van Patten 9:12 pm on November 5, 2013 Permalink | Log in to Reply

      I would like to voice a *strong* preference toward Sass, specifically using the default SCSS syntax. Syntactically, Sass w/ SCSS is really quite similar to LESS, although this article from Chris Coyier outlines the differences (and he ultimately says to use Sass).

      This is totally an opinion and based on my own perceptions (I’m not trying to incite a flamewar!), but Sass strikes me as more actively (and more seriously) developed. They have an intense focus on stability and maturity.

      Again, this is based on my own (biased) perceptions, but I also don’t see any serious professional front-end devs recommending LESS, and I can’t name anyone in my circle of front-end developers using LESS on a day-to-day basis. I’m sure they’re out there, but Sass seems to be the overwhelming choice for the front-end developers I know and trust.

      I realize this is largely an emotional response to a technical issue, but Sass just *feels* right to me, in a way that LESS does not. And—not to get too precious about the tools or anything—I would be much more likely to contribute to a Sass-based Core than LESS-based Core (for whatever little that’s worth, natch).

      • Bryan Petty 9:19 pm on November 5, 2013 Permalink | Log in to Reply

        I’ve already voiced my opinion pretty clearly on #22862, but I also agree with @chrisvanpatten.

      • Chris Van Patten 9:21 pm on November 5, 2013 Permalink | Log in to Reply

        I’d also add to this that if you look at the major open source projects that the big front-end devs are working on there is a clear consensus around building with Sass.

        For example, see this discussion on Github discussion a pre-processor to use for Effekt.css. The consensus overwhelmingly tipped toward Sass (and very quickly too).

        That’s *not* to say that Sass is the right choice for WordPress just because everyone else is doing it, but I think it does show that the industry is definitely heading in a Sassy direction.

      • CreativeNotice 9:42 pm on November 5, 2013 Permalink | Log in to Reply

        Agree completely. The only project I utilize that uses LESS is Bootstrap and even there I use the SCSS version provided by the folks maintaining Yeoman.

    • Paul Clark 9:28 pm on November 5, 2013 Permalink | Log in to Reply

      I’m with @chrisvanpatten on this — SASS — with SCSS syntax and no Compass. My reasons are:

      • SCSS shares variable syntax with PHP, so more conceptual overlap for beginners (Less uses Ruby syntax).
      • For advanced users, SCSS can be extended with Compass, which requires a bit more setup, but may be useful for some specialized purposes.
      • For team projects, I generally discourage the use of Compass, only because of decreased portability. Again, if there’s an extension that saves much time (or is only used for prototyping), that may override that.

      Quicker learning curve for beginning PHP developers and more extensibility for advanced users makes a clear case for SASS over LESS in my mind.

      • Chris Van Patten 10:19 pm on November 5, 2013 Permalink | Log in to Reply

        I’m a big fan of Compass (we use it at my company) but I’d tend to agree that it isn’t right for a project like WordPress. I think it would add too much overhead and increase the barrier to entry for new contributors.

      • Taylor Dewey 10:26 pm on November 5, 2013 Permalink | Log in to Reply

        I agree that Compass doesn’t have much of a place in WordPress core. I don’t think that it, in and of itself, should be seen as a +1 for SASS. However, the fact that a library like Compass can be built, may indicate deeper core extensibility. This is something WordPress core is unlikely to need or use in the short term (I can’t see us writing ruby gems to do anything in the short-term), but it’s presence is a comfort to the developer side of me.

    • Taylor Dewey 9:33 pm on November 5, 2013 Permalink | Log in to Reply

      sourcemaps are pretty (very) awesome as a dev tool, but may be difficult to implement by hand (the syntax is ugly and requires a sourcemap file to be generated). I believe both Sass and LESS have sourcemap support in trunk, but not stable at the moment. FWIW, sourcemap support could potentially extend to concatenated javascript.

      +1 for first steps being to break up the files and trial a preprocessor with color schemes.

      +1 for Sass / .scss syntax (yeah, it’s what I’m familiar with… there was a reason once…)

      As much as I’d love to see everything fixed — there’s a very real potential to preprocess our way into something even worse. IMO, there are a lot more best practices to keep in mind when using a preprocessor. Let’s focus on step 1 — and figure out the rest of the roadmap as people (core contributors, committers, etc) become familiar with the tool and folder/file structure.

    • CreativeNotice 9:34 pm on November 5, 2013 Permalink | Log in to Reply

      I’m also a fan of SASS w/ SCSS.

      It might be best to develop a set of requirements you need met by preprocessing and see which best meets those. Otherwise you end up with a game of tug ‘o war; consensus does not always provide the best solution.

    • Andrew Woods 10:01 pm on November 5, 2013 Permalink | Log in to Reply

      Recommendation: SASS using SCSS syntax

      Both are useful, and everyone should be using a preprocessor to manage their CSS. IMHO, SASS using SCSS is the better choice. From what I’ve seen SASS is used more by the Design community. There are also more tools that support SASS. the ‘compass watch’ command is invaluable and comes as part of SASS upon install. I’ve used both LESS and SASS. Even thought I’ve used LESS successfully on projects, I think SASS’ SCSS syntax provides more clarity. I think that helps with the on-boarding of new team members.

      • Taylor Dewey 10:20 pm on November 5, 2013 Permalink | Log in to Reply

        ‘compass watch’ would only be valuable if we adopted Compass + sass — which isn’t neccessarily on the table. Furthermore, we’d be processing sass using the grunt-contrib-sass plugin for Grunt. This way we can also benefit from additional processing on the resulting css file (e.g. autoprefixr). Since we’re in the context of grunt, the grunt-contrib-watch command will be quite flexible.

        I would, however, love to see an example of how scss is more clear than LESS. Is it just the $ variables being familiar to php devs, or is there something else?

    • kkalvaa 10:19 pm on November 5, 2013 Permalink | Log in to Reply

      I’m also a fan of sass/scss over less.

      I used to favour less, mostly due to it being easier to set up (less.js mainly), but i’ve changed my mind lately and now prefer sass. Sass seems to have a better defined goal and the newly redesigned website makes it quite a bit easier to read documentation. Also I’ve been finding more interesting projects released i sass than less lately (though that might be my bias).

    • Matt Wiebe 10:33 pm on November 5, 2013 Permalink | Log in to Reply

      The big thing here is to use one. Variables will make abstracting colour schemes far easier. Partials promote code organization and abstraction, allowing more and better collaboration.

      My only personal preference here is for Sass with the old whitespace-sensitive syntax, but even the Sass project understood that’s a non-starter when they introduced the now-default SCSS syntax. Much of the “LESS is easier” sentiment stems from this now-irrelevant item, as SCSS syntax provides you with familiar curly braces. (The other reason is that the LESS website was prettier. The Sass site was recently redesigned and this will no longer be an issue.)

      Sass and LESS are largely functionally equivalent, but here is why Sass is a better choice:

      1. The Sass project is under much more active development. Sourcemaps came to Sass first. Chrome devtools supported Sass first. There’s active work on libsass, a C-based Sass implementation that supports bindings for any language, like PHP and JS.
      2. Sass has a very active community; from frameworks like Compass and Bourbon, to simple (and not-so-simple) functions: https://github.com/Team-Sass I would not recommend using a framework, but active communities are one of the best ways to evaluate which technology to support.
      3. Any comparison list will show that Sass simply does more. It is more fully featured, particularly their extends functionality. (LESS now has extends as well, but Sass’s implementation is more mature and fully-featured)
      4. I was going to rant here about LESS’s homepage promoting client-side compiling on their home page, but they recently (finally) changed that. Good on them!

      • WraithKenny 1:56 am on November 6, 2013 Permalink | Log in to Reply

        I don’t think it’s clear that Sass has a larger, more active community or development. LESS has Twitter’s Bootstrap (and about a million projects based on it) among others and less.js core seems to have gotten a new stable of (really active) maintainers.

        The other point is of the programing language logic features of Sass versus the intentional avoidance of those in Less.js, which is also a feature (less went with gaurds). I don’t see WordPress using, or rolling it’s own, Compass, so I think the Less.js feature of not having complex programing logic in CSS preprocessing, is a actually a better fit.

        Other then that (and that in the WordPress build system, LESS doesn’t have extra dependencies like Ruby for compiling) feature wise, LESS and Sass are essentially the same.

        (Also, the ability of manually compiling LESS client side certainly has it’s uses, and is a great feature.)

        • WraithKenny 4:05 am on November 6, 2013 Permalink | Log in to Reply

          Turns out you can do complex logic and loops and whatnot in less.js, but the philosophy is that you probably shouldn’t…it’s just css after all.

        • Matt Wiebe 8:31 pm on November 6, 2013 Permalink | Log in to Reply

          Bootstrap is one project, albeit a massively successful one. One project (and its derivatives) does not a community make. Sass’s community is both broader and deeper.

          I don’t see WordPress using, or rolling it’s own, Compass, so I think the Less.js feature of not having complex programing logic in CSS preprocessing, is a actually a better fit.

          If we’re going to the trouble of using a preprocessor, I think that having the most powerful one is the better choice. We don’t have to use all that power, and I’m sure we won’t, at first. But we’ll be happy it’s there if/when we want it.

          I don’t just say this to cheer on my language of choice. There’s loads of people who start with LESS and end up with Sass. (Like Andy Clarke, who was vocally anti-Sass before that.) I have honestly never seen a single person move in the other direction. This tells me something.

    • Matt Wiebe 10:35 pm on November 5, 2013 Permalink | Log in to Reply

      Complete pedantry aside: Sass is not all caps. LESS and SCSS are.

    • OC2PS 10:36 pm on November 5, 2013 Permalink | Log in to Reply

      Does it matter that SASS is written in Ruby? Specifically, would that mean that Ruby would become a dependency for WordPress?

      Remember, while Ruby is expanding like nobody’s business, it is still not available on most hosting servers.

      • Taylor Dewey 10:43 pm on November 5, 2013 Permalink | Log in to Reply

        That’s a good point to make: Sass does have a *development* dependency of Ruby and the Sass Ruby gem.

        We also have a development dependency in this workflow (no matter if we go Sass, LESS, or even just separate CSS files) of Node, NPM, and Grunt.

        • Matt Wiebe 10:48 pm on November 5, 2013 Permalink | Log in to Reply

          Yes. That being said, it would be killer to have server-side compilation in the future (with appropriate caching etc)

          • Helen Hou-Sandi 10:57 pm on November 5, 2013 Permalink | Log in to Reply

            A script would take care of running the build that’s used for packages and the core repo, just as it already does for minified/uglified files. Otherwise: grunt watch, yo.

            • Matt Wiebe 8:21 pm on November 6, 2013 Permalink

              Yes, but that’s just for core. Let’s imagine a world where asset concat/minification for all enqueued styles/scripts happened on every page. I like that world.

        • Helen Hou-Sandi 10:56 pm on November 5, 2013 Permalink | Log in to Reply

          Develop repo already uses Grunt. I guess you don’t *have* to run out of build right now, though (I don’t, actually, I run out of src).

        • WraithKenny 11:29 pm on November 5, 2013 Permalink | Log in to Reply

          What’s that mean, “*development* dependency?” You do need Ruby installed to compile Sass. If Node, NPM and Grunt are the dependencies of the workflow, then LESS has no further dependency, but Sass (SCSS) does, right?

          • WraithKenny 11:30 pm on November 5, 2013 Permalink | Log in to Reply

            In my experience, setting up Ruby on a Windows environment is a pain, but installing Node/NPM was super simple.

          • Taylor Dewey 12:25 am on November 6, 2013 Permalink | Log in to Reply

            I was emphasizing that the dependencies are for those developing core — not for those using the product. As you mentioned, LESS would have no further development dependency beyond what is already in place (node/npm/grunt). Sass has the additional requirement of ruby/sass.

            Think we’re on the same page here.

            • Bryan Petty 4:32 am on November 6, 2013 Permalink

              On the same page, except that using Sass from Grunt does not actually require Ruby, not even as a “development dependency”, see below.

      • Helen Hou-Sandi 10:54 pm on November 5, 2013 Permalink | Log in to Reply

        Yes, it does mean requiring Ruby for development and build, but there’s not really a good reason to be running the develop repo on a host somewhere – you’d want to either use the old core repo that receives built files or a regular old package, both of which include and use compiled files (see, for instance, our unminified vs. minified CSS and JS). Doing a build would be done because you’re using the develop repo, which as its name indicates, is for developing WordPress core itself. A typical user or hosting environment shouldn’t be subject to any changes.

        • Bryan Petty 12:21 am on November 6, 2013 Permalink | Log in to Reply

          Actually, it doesn’t require Ruby if we use grunt-sass instead of grunt-contrib-sass (many projects have made this migration already) as I’ve mentioned in #22862 already, and as referenced by @mattwiebe here earlier.

          • WraithKenny 3:48 pm on November 6, 2013 Permalink | Log in to Reply

            Well, that’s nifty. I’ll definitely check that out.

          • Taylor Dewey 8:54 pm on November 6, 2013 Permalink | Log in to Reply

            I’m actually very interested in trying this out (libsass is supposed to be superfast), but it’s something to keep in mind, but it is considered “under development”

            Thanks for bringing it up.

    • Doug Wollison 11:19 pm on November 5, 2013 Permalink | Log in to Reply

      I say SASS.

      1 major advantage: if/then/else and for/while/each statements. It’s more of a programming language than LESS. There’s nothing super complicated about either language once you get past the nested styling and variables. Also, I feel SASS as a slightly more informative syntax and can give you a better idea of what’s going on in the code.

      Granted, SASS runs on Ruby/Gems, which I always seem to have trouble installing properly, but as long as somebody provides a decent how-to for setting it up on a dev server, we should be fine.

      • WraithKenny 11:32 pm on November 5, 2013 Permalink | Log in to Reply

        As far as I understand it, Windows is not supported by Ruby. They suggest using a 3rd party library to get it working.

        • Taylor Dewey 12:28 am on November 6, 2013 Permalink | Log in to Reply

          It doesn’t appear Ruby itself supports anything beyond compiling it yourself. All the third party tools to install are “not supported”

          That said, for Windows they suggest: http://rubyinstaller.org/ — would love to hear someone’s experience with it.

          • CreativeNotice 2:26 pm on November 6, 2013 Permalink | Log in to Reply

            I used the rubyinstaller last month, it ran like any other windows installer. No configuration needed post install if I remember correctly.

      • Mel Choyce 1:47 am on November 6, 2013 Permalink | Log in to Reply

        Do you have some examples where using if/then/else and for/while/each statements in Sass could be helpful? Just curious because I haven’t seen them used before. :)

    • Andrew Ozz 12:57 am on November 6, 2013 Permalink | Log in to Reply

      I’m still not 100% sold on the advantage of using a CSS preprocessor. Starting a new project and implementing a preprocessor is quite nice, importing and redefining 10 years worth of incremental (unorganized, often accidental) CSS is a nightmare :)

      Don’t get me wrong: as a coder I’d prefer to be able to use at least variables and conditionals in CSS, loops would be nice too.

      Advantages of using a CSS preprocessor:

      • Changing something in one place would automatically change it in many places in the final stylesheet.
      • (Can’t really think of another… The above is pretty nice though.)

      Disadvantages:

      • Requiring all contributors that want to be able to build trunk, to install another application or bunch of applications (for SASS).
      • Rising the bar for all contributors that may consider contributing CSS.
      • Making it (much) harder to debug CSS in a browser console.
      • Making it harder to test CSS patches.
      • Will be exposed to regressions in the build tools (that’s a big one…) and differences in the output for different versions of the tools.

      Requiring every patch that touches CSS to include both the changes to the preprocessor file and the actual wp-admin.css would make it easy to test but would increase the chance of differences in the final build.

      • Dion Hulse 1:28 am on November 6, 2013 Permalink | Log in to Reply

        Prefix: I’m using SCSS below, but I’ve only ever used LESS.. so it’s really just a placeholder.

        So far the ideas mentioned seem to suggest to me that:

        • We’d have .scss files in /src/
        • We’d have built .css files in /src/ (ie. We’d have a CSS file for each SCSS file)
        • We’d have concat’d and minimised .css files in /build/
        • We’d have Sourcemaps in /buid/ pointing to the exact location in the SCSS file that the rule came from
        • We’d have a grunt task to convert the SCSS to CSS in /src/

        Due to the higher bar of entry, we’d probably:

        • Willingly accept patches against the .css files in either /build/ or /src/ and convert them to .SCSS patches

        Migrating old CSS would happen as it’s rewritten or altered, there would be no need to suddenly change all of our code to SCSS-style.. with MP6 being added in 3.8, it seems like 90% of our admin CSS is going to be re-written or modularized anyway, so it’s not such an issue.

        Sourcemaps make debugging in browsers much easier (I recently tried debugging a sites compressed JS, only to suddenly be looking at the exact character in the uncompressed/non-ugly code, Sourcemaps work great).

        As for regressions in the tooling, yes we’d be susceptible to those too, but as has been shown by 3.7.1, we’re already susceptible to them and it drives home that all testing should be done on a /build/ and development done on a /src/.

        • Andrew Ozz 3:33 am on November 6, 2013 Permalink | Log in to Reply

          Yes, that’s pretty much how I imagine the implementation too. The “(much) harder to debug CSS in a browser console” is mostly a concern about somebody trying to debug a client site remotely, or trying to pinpoint a problem described in a forum post. Especially in older browsers where sourcemaps wouldn’t be helpful.

          …it drives home that all testing should be done on a /build/ and development done on a /src/.

          Right, but the bug in 3.7 was caused by a regression in the newest tool version, while testing was done with earlier versions. I’m pretty sure we won’t let that happen again. Finding a way to “lock” the build tools versions and force an upgrade when needed would be best.

      • WraithKenny 1:33 am on November 6, 2013 Permalink | Log in to Reply

        Another often overlooked advantage of a preprocessor is that using nested rules and mixins naturally organize rules, uncovering and preventing many problems with redundant and conflicting rules. Maintainability and Reuseability are Huge advantages.

        To address your concerns:

        • Building the css *can* be a separate process for css contributors (for testing at least, the css core would use and ship would be from the automated build process, only). For example, Sublime Text can be easily set up to build LESS with a key stroke; the tutorial on that is simple.
        • Using a preprocessor is becoming a basic and expected entry-level skill for working with css.
        • Chrome and LESS (and Sass, I think) now support Source Maps (it’s not beta anymore). This makes it just as easy to find the file and line number of the source, using Dev Tools (no plugin needed).
        • patch and build wouldn’t be too hard for contributors, if they have the requisite basic entry-level skill mentioned above.(Alternatively, I did put a proof of concept plugin on the Ticket that could ultimately edit, compile, and show LESS changes live in the browser. There’s no technical reason the plugin couldn’t be extended to accept and output diff files.)
        • I don’t have an answer to this one, but I’m not convince it’s a big problem. Core will use Grunt, with a specific version of the preprocessor, so with care, it shouldn’t be a big deal. The preprocessors simply aren’t as complicated as a language like php or javascript. Any regression is easy to notice, and has no security implication that I can think of, and easily corrected.

        I don’t think requiring the compiled css in the patch is the right way to go.

        • Andrew Ozz 3:49 am on November 6, 2013 Permalink | Log in to Reply

          …using nested rules and mixins naturally organize rules, uncovering and preventing many problems with redundant and conflicting rules. Maintainability and Reuseability are Huge advantages

          Right, that should have been point two in my comment above.

          I don’t think requiring the compiled css in the patch is the right way to go.

          My concern is mostly about people who want to test (bigger) patches that contain CSS. Not sure if we should require them to be able to generate the stylesheets.

          • WraithKenny 3:59 am on November 6, 2013 Permalink | Log in to Reply

            Maybe a “companion” patch that just contains the .css changes? It’d be a courtesy patch that wouldn’t be commited, but is just available for testing, for use by folks who can compile the css.

    • Brendyn Montgomery 1:16 am on November 6, 2013 Permalink | Log in to Reply

      We use Sass (specifically .scss) in all our projects and so would have a preference for it over LESS.

      I love the idea of a preprocesser being built into the core, especially if it could be extended to include other addtions if a developer wants it (we also use SUSY grids, breakpoint and compass on all developement projects).

      Could it be implemented in such a way as to be an optional flag in the wp-config.php that defaulted to off? That might get around the issues of old CSS that could be problematic or people not wanting to use it for any reason?

      Another major advantage of Sass (can’t speak for Less) is that you can define the output to be compressed which will strip all the white space and comments out of the CSS and reduce file size. That means that you can be really verbose with comments in the Scss file and then know that this isn’t going to effect the size of the .css file.

    • fightthecurrent 1:47 am on November 6, 2013 Permalink | Log in to Reply

      I’m definitely in support of sass. Plenty of valid arguments have already been made :)

    • Till KrĂĽss 3:38 am on November 6, 2013 Permalink | Log in to Reply

      I prefer Sass (SCSS syntax) over LESS.

      LESS is a good CSS preprocessor, but Sass is IMO simply better. It has a cleaner syntax, it supports conditionals & control structures like loops and variable defaults which LESS doesn’t or in a bad way. Plus Sass supports one-dimensional lists and with 3.3 multi-dimensional lists.

    • Remkus de Vries 8:31 am on November 6, 2013 Permalink | Log in to Reply

      I personally prefer LESS over SCSS, but surely this is influenced by my experience with Twitter Bootstrap. Does anyone remember why they opted for LESS at the time?

    • Nashwan Doaqan 9:11 am on November 6, 2013 Permalink | Log in to Reply

      I use LESS in all of my projects, never used SCSS before.. LESS gives me all what I need and I didn’t get a reason why I should learn SCSS!

    • Gary Jones 9:26 am on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS. When I looked at the differences a while ago, Sass as SCSS just had more development features and flexibility (i.e. you could do a little more with it as it was more powerful). When everything is generally status quo, having the *option* to use one of the advanced features at some future point should be a valid consideration.

      • Christian Foellmann 10:47 am on November 6, 2013 Permalink | Log in to Reply

        +1 for SCSS. I am with Gary on this. SCSS seems to be more powerful and thereby more future-proof.
        I really love the idea of using a CSS preprocessor and I think the concept of both is so similar that people familiar with LESS can switch pretty easily.

    • Josh Eaton 1:36 pm on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS

    • atadams 3:40 pm on November 6, 2013 Permalink | Log in to Reply

      +1 for SCSS.

      I think it should be pointed out that Linkedin has hired Chris Eppstein to maintain Sass (and Compass). Having a dedicated developer is a big plus. I don’t know if LESS has anyone comparable.

    • Pbearne 4:13 pm on November 6, 2013 Permalink | Log in to Reply

      I have thinking a bit about this and wondered if we should ..

      leave the current css tools (wp_enqueue_style) and add a whole new stack

      wp_enqueue_sass to add files
      wp_enqueue_sass_folder for all file in folder
      wp_enqueue_sass_fagment do just pass string of scss

      if debug on we compile every page load otherwise we cache a single css file and rebuild on plug-in / theme activated / deactivated etc. (add wp_complie_sass() so it can be called)

      I see the need for filters pre_complie_sass and post_compile_sass

      If do this plugin’s and themes can convert as they see fit

      let’s also fix/add conditional CSS and possible provide a ordering options

      does this make sense?

      • Helen Hou-Sandi 4:24 pm on November 6, 2013 Permalink | Log in to Reply

        I don’t think core should be compiling CSS on the fly. We already use a Grunt-based build process – this would be an extension of that.

        • Pbearne 4:45 pm on November 6, 2013 Permalink | Log in to Reply

          I can see that makes sense.

          Sorry to get it clear in my head are talking about adding a server side compiler or just a developer grunt script?

          What I believe we need is a server side compiler as will get more adoption in the community.

          So do we end up with 2 css files wp-admin core and plug-in’s

          Part of the benefit of sass is the reduction of css files I feel we should pursue this benefit as best we can.

          • Taylor Dewey 9:11 pm on November 6, 2013 Permalink | Log in to Reply

            The plan so far would be to use Grunt to process (if necessary), concat, and minify css files. So a developer build process using grunt.

            Server side concat and minification is an entirely different discussion that wouldn’t be influenced by our preprocessor usage.

            Server side processing is also a different discussion and shouldn’t influence our decision to use a preprocessor or not (nor which one).

            Reducing http requests is a noble goal—but has no relationship to this thread.

    • Shea Bunge 11:30 pm on November 6, 2013 Permalink | Log in to Reply

      I used to use Less before switching to Sass’s SCSS syntax. One of the main things that held me back was implementation, but this wouldn’t be an issue as we are using Grunt.

      Aside from Compass, I enjoy how much more powerful Sass is over Less. For one thing, Sass supports nested properties:

      body {
	background: {
		color: red;
		image: url( 'foo.png' );
		size: 42px 42px;
		position: top right;
	}
}

      Sass also supports nested media queries – an invaluable feature, IMO.

      body {
	background-color: blue;

	@media screen and (min-width: 130px) {
		background-color: green;
	}
}

      In Less, the above code would have to look like: 

      body {
	background-color: blue;
}

@media screen and (min-width: 130px) {
	body {
		background-color: green;
	}
}

      Sass also supports much more advanced logic and control than Less.

    • Shea Bunge 11:33 pm on November 6, 2013 Permalink | Log in to Reply

      Additionally, I would also like to suggest using the excellent Autoprefixer tool for automatically adding necessary CSS prefixes. There is also an Autoprefixer Grunt task available.

  • George Stephanis 10:35 pm on November 4, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Upcoming Global Admin Search (nĂ©e Omnisearch) Meeting 

    After the feedback in the merge chat today, it looks like we’ve got a bit more work to do on the global search spine.

    Based on a quick survey, it looks like Monday, November 11, 20:00 UTC (3pm EST) is likely to be the best time for the most people.

    As we’ve done before, we’ll meet in #wordpress-core-plugins on Freenode, and I’ll give a shout in advance on #wordpress-dev for anyone that may be lurking in there.

    Putting up the bat-signal:

    Other folks who spoke up during the merge chat that I’d love to have join us:

     

  • shaunandrews 7:25 pm on November 4, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Widgets Area Chooser – 3.8 Proposal 

    Placing widgets with drag-and-drop can be tedious and annoying — especially if you have lots of sidebars on which to drop widgets. The Widgets team has been working on a few solutions (for this problem, and more), including redesigning the wp-admin widgets interface and adding the ability to manage widgets from within the customizer. These projects are still ongoing, and not ready for 3.8. However, along the way we’ve found a few incremental changes which improve the overall experience of working with widgets. Some of these improvements have made their way into MP6. Others involve more functional changes which don’t belong in MP6. This plugin is one of those improvements.

    The Widgets Area Chooser is available at: http://wordpress.org/plugins/widget-area-chooser/

    The Problem
    Dragging widgets from the available widgets in the top-left, to a sidebar “below the fold” is hard. Almost impossible. Dragging widgets on a touch screen device is also difficult.

    The Solution
    Clicking (or tapping) on an available widget brings up a list of available sidebars that you can place the widget in to — its pretty simple, and works great on touch devices.

    Accessibility
    There’s also the accessibility problems that drag-and-drop introduces, which necessitates the need for the separate (and often neglected) Accessibility Mode. This plugin provides a much easier way for those with screen readers to add new widgets without having to drag-and-drop. In fact, this could be the first step towards removing the need for an Accessibility Mode for widgets.

    Demonstration
    Here’s what the chooser looks like:

    Here’s a quick video of the plugin in action:

    Please let us know what you think!

     

    • william.deangelis 7:37 pm on November 4, 2013 Permalink | Log in to Reply

      Not bad. I assume that on mobile each of those two panels would be its own screen? If that’s the case then I say wicked. Go for it!

    • Jeff Behnke 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      I like it. Solves the problems that need solving in the widget admin.

    • Bryan Petty 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      Just wanted to say that I’m excited that you’re working on this @shaunandrews, and it’s coming along nicely.

      I’m still curious how well this UI handles with 3-5 widget areas, and maybe 50+ available widgets, and what happens with the stored/saved widget settings, but this really is a great start.

      • shaunandrews 1:43 am on November 5, 2013 Permalink | Log in to Reply

        Hey Bryan, thanks for the kind words — I’m super excited to be working on this!

        I think you may be getting the Widgets Area Chooser (WAC) plugin confused with the general layout updates as part of MP6 and the separate widgets project. This post is focused solely on the WAC plugin, which lets you click-to-add a new widget.

    • and0r1995 8:25 pm on November 4, 2013 Permalink | Log in to Reply

      I don’t know, I like the idea and stuff, but I personally prefer the drag and drop, Although when there are a lot of widget areas it’s a bit annoying.

    • Marcus 8:36 pm on November 4, 2013 Permalink | Log in to Reply

      I like this, already an improvement, nicely done!

      Aside from @bpetty ‘s point, another (minor) idea/tweak also is for UX just clicking on the area to place a widget instead of click area > add widget will save a click for non-default widget areas. The cancel button should probably still remain.

      • shaunandrews 1:47 am on November 5, 2013 Permalink | Log in to Reply

        …just clicking on the area to place a widget…

        I thought about that initially, primarily because it was one less new UI element to show on the screen — the widget areas are already there, just let the user click on them to add the selected widget. This caused two problems:
        1) It wasn’t immediately obvious what to click.
        2) It didn’t really solve the problem of the widget area being off the screen.

        If you have an idea on how to make this all better, please don’t hesitate to sketch it out and/or attend our chat on Monday at 20:00 UTC. Your thoughts and feedback is greatly appreciated. Thanks!

        • Luke McDonald 6:25 pm on November 8, 2013 Permalink | Log in to Reply

          My initial thought when trying this out for the first time was I would click on the widget area I wanted and the widget would be added to that area. I was testing on a theme that had 7 or 8 widget locations, which is why I didn’t see the “Add Widget” button below the chooser list.

          That said, for me it was *obvious* what to click, and I think it would be for many others too. It seems this functionality should replicate that of a select menu or your typical drop-down menu. In both cases, once you select an item, an action takes place.

          If it’s not immediately obvious for users the first time, it will be the next time they do it. I think after someone knows how it works, it would be preferred not to have to make an extra click or even scroll down to the “Add widget” button in cases where there are many widget areas.

    • mbootsman 9:17 pm on November 4, 2013 Permalink | Log in to Reply

      Major UI improvement. Thanks for developing this!

      • shaunandrews 1:49 am on November 5, 2013 Permalink | Log in to Reply

        Thanks for trying it — hope you like it. Please let me know if you find any problems, or have any suggestions for improvements.

    • Dan Milward 2:59 am on November 5, 2013 Permalink | Log in to Reply

      Awesome work man. I don’t know why but on one of my test sites the list of available widgets is on the right hand side of the screen instead of the left hand side of the screen. Its pretty weird.

      Also I hope the menus screen gets a similar overhaul.

      • shaunandrews 3:16 am on November 5, 2013 Permalink | Log in to Reply

        Perhaps you’re using an older version of MP6? Can you provide version details for WordPress, MP6, and the Widgets Area Chooser plugin? Also, what browser and OS? A screenshot would go a long ways as well.

    • Grant Palin 5:17 am on November 5, 2013 Permalink | Log in to Reply

      I like it. I’ve found the drag and drop setup a bit finicky before, and the click, click, click seems a usability improvement, especially when multiple widget areas are involved. Plus the UI fits nicely with the MP6 theme.

    • HerrLlama 11:19 am on November 6, 2013 Permalink | Log in to Reply

      I don’t like it. The UI is nice tough, but the usability is … well how could I say it neat? … a piece of crap. Now I drag and drop the widget on the wanted position in the wanted widget area. With this “improvment” I have to click on the widget, then I have to choose the area and than click I have to click the add button. But after all that I have to drag and drop the widget on the right position. Seriously, that makes it more complicate than it could be.

      • shaunandrews 2:51 pm on November 6, 2013 Permalink | Log in to Reply

        You can still drag-and-drop widgets in to place. You don’t have to click.

        • HerrLlama 3:57 pm on November 6, 2013 Permalink | Log in to Reply

          Yes, I already read this, but your proposal is a way more to confuse the users. WordPress itself said that they wanted to implement decisions, not options. It would help if we don’t work on the frontend for the widgets and create an API (e.g. add_widget_to_sidebar( $widget_type, $sidebar ) or stuff like that) which actually works.

          I agree, that the UI needs some improvements, but there are plenty of different screens of editing things (tags, posts, menus, widgets, options, etc) which also confuses the users. I think we should focus on a consistent backend before we implement new things. If not, I think that is a major problem of WordPress. Have you ever been to a Typo3 backend? Everything looks like it is in one pour.

          And also: Sorry for beeing rude, but I’m german ;)

      • Helen Hou-Sandi 3:20 pm on November 6, 2013 Permalink | Log in to Reply

        As @shaunandrews noted, this does not replace drag and drop; it provides an alternate method for those who can’t or don’t want to drag and drop for whatever reason. Also, you are being rude, and that is unnecessary.

      • Matt Thomas 6:19 pm on November 7, 2013 Permalink | Log in to Reply

        I would recommend re-reading the original proposal. Managing widgets is currently not possible on a mobile device because drag-and-drop is the only supported method of adding or removing widgets.

      • PeterRKnight 4:17 am on November 8, 2013 Permalink | Log in to Reply

        drag and dropping a position vertically is easy (on desktop), the issue with the current widgets screen that this improvement solves is about making it much easier to add widgets to widget areas without having to do acrobatics. Try dragging and dropping a widget on a screen that requires scrolling because there’s so many widgets and so many widget areas. This however is a major usability improvement for desktop as well as mobile.

    • bfintal 2:08 pm on November 11, 2013 Permalink | Log in to Reply

      I like it. This would solve the drag and drop problem in mobile versions also.

      This is just me, but a method of duplicating a widget would be helpful.

      • shaunandrews 2:46 pm on November 11, 2013 Permalink | Log in to Reply

        Yup, part of the goal with this was to improve the experience of adding widgets on mobile.

        This is just me, but a method of duplicating a widget would be helpful.

        This isn’t the first time I’ve heard this request, so you are not alone. :)

      • Weston Ruter 6:20 pm on November 11, 2013 Permalink | Log in to Reply

        Regarding duplicating a widget, there is this Duplicate Widget plugin and there is the Clone Widgets plugin. The former does a shallow-copy/symlink/reference for the widget, and the latter seems to do a clone or deep copy of the widget. Which use case are you interested in? Do these plugins do what you want?

← Older posts

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