WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from May, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 2:18 am on May 21, 2014 Permalink
    Tags:   

    Last Week in WordPress Core 

    Hi Everyone! This is the first Last Week in WordPress Core for WordPress 4.0! Last week, a minor update, 3.9.1 was released, and autoupdates started shortly afterwards. Development on 4.0 is ongoing, and you can see notes and meeting details posted by @helen on this blog as well.

    Media:

    • In wp.media.view.Settings::update(), when handling checkboxes, check for a value of false in addition to casting value to boolean. !! false evaluates to true. [28371] #23954
    • Allow users to set overrides for MediaElement instances by always passing _wpmejsSettings instead of just _wpmejsSettings.pluginPath. [28370] #25243
    • When pausing “all” players attached to MCE views, don’t reach into global scope and pause every player. Only pause the players bound to MCE views. [28364] #27971
    • In wp_read_image_metadata(), the values from exif_read_data() should only override values from iptcparse() that are empty. [28367] #23706
    • Support loop for [audio] and [video] shortcodes that specify files that are played using MediaElement’s Flash plugin bridge. [28363] #27368
    • MediaElement players need clear: both to play nice with adjacent floated elements. [28361] #27385

    Widgets:

    • Custom Navigation Widget: Force users to choose a nav menu in the custom nav menu widget, for a better customizer UX. Before, they had to make a dummy change to get it to render. Now they are made to choose a nav menu from the dropdown, which feels more natural. [28197] #27878
    • Recent Posts Widget: Use ob_end_flush() instead of ob_flush(). ob_end_flush() flushes the output buffer and turns output buffering off, same as ob_get_flush(). [28195] #28009

    Themes and Templates:

    • Prevent paged-* from being added to body classes and prevent Page %s from being added to page title on 404 error pages on default themes. [28249] #16468
    • Bundled Themes:Prevent Page %s from being added to page title on 404 error pages in bundled themes. [28250] #16468.
    • Bundled Themes: Use correct logic in IE conditional comments in header template. [28341] #28151
    • Set the proper value for wp_title() when is_author() and is_post_type_archive() are both true. post_type should always win due to the precedence indicated in get_queried_object(). [28251] #25398
    • Update the default (WP-defined) styles for MediaElement players to be more in-line with our flat aesthetic. Use the new official colors. [28365] #27516

    Custom Headers:

    • Allow to skip cropping header images if image width is smaller than or equal to theme width. [28219] #27936
    • Avoid hiding ‘Remove’ buttons unrelated to custom headers. [27882] #27848
    • Keep header image from being removed when background image is removed. [28269] #28046
    • Avoid warnings in the process_default_headers() method. #27850
    • Fix logic when a theme doesn’t set default-text-color. [28294] #28042

    Internals:

    • Move home option to the top of populate_options() to make it easier to find next to siteurls for manual changes. [28260] #28141
    • Scrutinizer Cleanup: @wonderboymusic has started the process of cleaning up core with Scrutinizer. Check out the full list of fixes so far on #27882.
    • Hack/HHVM Compatibility: More from @wonderboymusic. See #27881 and #22400.
    • Dev Tools: Introduce default wp-cli.yml for core development. [28221] #28036
    • Add .dfxp and .srt files to mime-type whitelist in wp_get_mime_types(). They are both captioning formats supported by MediaElement. [28259] #27643
    • Add .xps and .oxps extensions to list of supported document types. More about the types on Wikipedia. [28372] #15697
    • When $type is atom in get_the_category_rss(), use get_bloginfo_rss( 'url' ) when setting the scheme attribute for the <category> node. [28258] #24444
    • In WP_Date_Query::get_sql_for_subquery(), don’t parse duplicate parameters – only parse one of w and week or month and monthnum. [28252] #25835
    • Add a filter for wp_list_comments() arguments. [28285] #19581
    • In get_the_author_posts(), if there is no current $post, return 0 and bail. [28362] #27998
    • In WP_Terms_List_Table::single_row(), call sanitize_term() on the passed term ($tag). [28360] #16864

    Externals:

    TinyMCE:

    • First pass at wpview logic for the shortcode. URLs pasted on their own line are parsed as well. The toolbar will appear with the “remove” button when the view is clicked. Edit has not been implemented yet, nor have safety measures for non-iframe embeds. [28358] #28195
    • Audio, video, and playlist shortcodes: [28342] #22400, #27881
      • Convert all instances of variable variables to array properties
      • Stop using extract()
      • Rename $atts to $html_atts where collision with new $atts (shortcode atts holder) var might occur
    • Shortcode JS: Avoid errors when an escaped shortcode includes a newline between brackets. [28223] #27907

    Multisite:

    Thanks to @andrezrv, @arnee, @avryl, @azaozz, @boonebgorges, @celloexpressions, @Clorith, @danielbachhuber, @dimadin, @ebinnionm, @ehg, @ericlewis, @feedmeastraycat, @GaVrA, @gcorne, @greenshady, @helen, @hlashbrooke, @imath, @jartes, @jdgrimes, @jeremyfelt, @johnbillion, @jorbin, @jupiterwise, @mattwiebe, @MikeHansenMe, @m_i_n, @obenland, @ocean90, @pavelevap, @psoluch, @rob1n, @rzen, @sergej.mueller, @SergeyBiryukov, @t4k1s, @Tmeister, @westonruter, and @wonderboymusic for their help!

    For the complete list of commits to trunk, check out the log on Trac. We’ve been chatting about 4.0 plans, and things are shaping up. Come chat this Wednesday to continue the discussion, and please note if you encounter issues with 3.9.1 on Trac.

     
  • K.Adam White 9:48 pm on November 5, 2013 Permalink
    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  

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

    • Sofia Rose 7:35 pm on December 25, 2013 Permalink | Log in to Reply

      @helen Are you still working on a 3.8 Style Guide? If so where can i get a copy? I would love to help with this. :)

    • Cameron Roe 11:07 pm on January 26, 2014 Permalink | Log in to Reply

      As the web moves forward, how are devs keeping up WITHOUT SASS?? I feel like it’s a must nowadays, and it would be extremely helpful to have Grunt running watch and build tasks with Core. The beauty of Grunt is that LESS users could easily add their LESS plugin if they wanted, but the majority would see built-in SASS. Compass, Bourbon, and most of the dev community pushed for SASS. Bootstrap is the exception in my book.

      +1 SASS.

    • Cameron Roe 11:17 pm on January 26, 2014 Permalink | Log in to Reply

      The other awesome benefits of this are the use of partials within themes and the nature of reusable variable declarations. It would allow for a more modular approach for styles.

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