Title: JavaScript Coding Standards
Author: K. Adam White
Published: November 5, 2013
Last modified: November 12, 2013

---

 [  ](https://profiles.wordpress.org/kadamwhite/) [K. Adam White](https://profiles.wordpress.org/kadamwhite/)
9:48 pm _on_ November 5, 2013     
Tags: [coding style ( 6 )](https://make.wordpress.org/core/tag/coding-style/),
[javascript ( 130 )](https://make.wordpress.org/core/tag/javascript/)   

# JavaScript Coding Standards

The PHPPHP The web scripting language in which WordPress is primarily architected.
WordPress requires PHP 7.4 or higher files in WordPress coreCore Core is the set
of software required to run WordPress. The Core Development Team builds WordPress.
become cleaner and easier to read with every release, thanks in part to our [standards for PHP code style](https://make.wordpress.org/core/handbook/coding-standards/php/).
Our JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming
language commonly used to create interactive effects within web browsers. WordPress
makes extensive use of JS for a better user experience. While PHP is executed on
the server, JS executes within a user’s browser. [https://www.javascript.com](https://www.javascript.com/),
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](http://tommcfarlin.com/wordpress-javascript-coding-standards/)
to the developer handbook. These [WordPress JS coding standards](https://make.wordpress.org/core/handbook/coding-standards/javascript/)
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 WordCampWordCamp WordCamps are casual, locally-organized conferences covering
everything related to WordPress. They're one of the places where the WordPress community
comes together to teach one another what they’ve learned throughout the year and
share the joy. [Learn more](https://central.wordcamp.org/about/). Boston’s core 
contributor dayContributor Day Contributor Days are standalone days, frequently 
held before or after WordCamps but they can also happen at any time. They are events
where people get together to work on various areas of [https://make.wordpress.org/](https://make.wordpress.org/)
There are many teams that people can participate in, each with a different focus.
[https://2017.us.wordcamp.org/contributor-day/](https://2017.us.wordcamp.org/contributor-day/)
[https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/](https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/)
I revisited this style guide with [@mattwiebe](https://profiles.wordpress.org/mattwiebe/)
and [Corey Frang](https://twitter.com/gnarf) (@gnarf37). It is important to identify*
and implement* conventions for JSJS JavaScript, a web scripting language typically
executed in the browser. Often used for advanced user interfaces and behaviors. 
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](http://jshint.com/) 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](https://make.wordpress.org/core/2013/11/04/the-state-of-inline-docs/)
effort).

After looking at [Idiomatic.js](https://github.com/rwaldron/idiomatic.js/) and several
other widely-adopted JS style guides, we feel the jQuery Foundation’s jQuery Core
[JavaScript Style Guide](http://contribute.jquery.org/style-guide/js/) 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 tracTrac An open source project by Edgewall Software that
serves as a bug tracker and project management tool for WordPress. 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.
  Adopting this guide means 
making two primary changes to the way that we have been writing JS:

 1. **Strict Equality**
 2. We need to move to using `===` instead of `==`. We’ve been getting away with using
    the double-equals in WordPress, but enforcing triple-equals (“threequals”) will
    avoid the unpredictability of type coercion. To quote the aforementioned Idiomatic.
    js, *evaluate for the most accurate result*. It is not intuitive that `"10" == 
    10` will be `true` despite the string/number type difference, and unintuitive code
    should be avoided.
 3. **Consistent curly braces**
 4. Every widespread JS style guide prefers enclosing single-line statements in curly
    braces, and we should too. If you always use brackets, adding other statements 
    to a blockBlock Block is the abstract term used to describe units of markup that,
    composed together, form the content or layout of a webpage using the WordPress 
    editor. The idea combines concepts of what in the past may have achieved with shortcodes,
    custom HTML, and embed discovery into a single consistent API and user experience.
    later is trivial; if they are not present, adding new statements can lead to bugs.
    We don’t require braces for single-line conditionals in our PHP standards, but 
    it is noted that having them “allows for fewer line edits for debugging or additional
    functionality later.” They also make the presence of blocks more obvious, particularly
    when the “single-line” statement is a complex jQuery operation.
 5. Consider:
 6.     ```notranslate
        // Two lines, one statement
        if ( someString === 'desired value' )
            $( '.class-name' ).show().value( someString + '!' )
                .on( 'click', doSomething );
    
        // Only three characters more, easier to "eyeball," and easier to add
        // additional statements to the conditional block later on
        if ( someString === 'desired value' ) {
            $( '.class-name' ).show().value( someString + '!' )
                .on( 'click', doSomething );
        }
        ```
    

We believe making these big changes and the other smaller consistencies found in
the jQuery style guide, will improve the reliability of our JavaScript and should
be integrated across the JS files in WordPress.

### Exceptions

There are two specific areas where we plan to *deviate* from the jQuery Core Style
Guide to maintain readability & consistency with existing styles:

 1. **We will use Single Quotes for strings**
 2. jQuery’s guide specifies double quotes for string declaration. The existing WordPress
    JS uses single quotes, and we prefer to keep this as-is: JS strings in WordPress
    will continue to use single quotes.
 3. **Iterator variables declaration**
 4. jQuery specifies that iterators should be initialized when the variable is declared,
    at the top of the function; this is done as a minified file size optimization, 
    but is extremely unintuitive for inexperienced JS devs. To quote Aaron Jorbin, 
    who raised this issue, “I would rather optimize for developer happiness.” Example
    below.
 5.     ```notranslate
        // Confusing
        var i = 0;
    
        // A bunch of lines of other code
    
        for ( ; i &lt; 100; i++ ) {
            // Expressions -- but how many? Where did `i` get declared, again!?
        }
    
    
        // Preferred / More readable
        var i;
    
        for ( i = 0; i &lt; 100; i++ ) {
            // Expressions
        }
        ```
    

## Next Steps

[@nacin](https://profiles.wordpress.org/nacin/) has [landed](https://core.trac.wordpress.org/changeset/25960)
an adaption of jQuery’s .jshintrc file in Core, and once we’ve gotten some comments
with feedback to this post I will update the Handbook’s JS standards page with examples
of the jQuery conventions.

Implementing these standards will need to be done in pieces. Much of our code is
pretty close, but JSHint can’t even fully process some of the older files in our
system due to the number of errors. We’d like to propose setting up some JSHint 
Compliance sprints to work through the codebase in a structured way.

Please leave a comment below if you would like to be involved in this process! Based
on a quick poll of known interested parties we will be meeting in IRCIRC Internet
Relay Chat, a network where users can have conversations online. IRC channels are
used widely by open source projects, and by WordPress. The primary WordPress channels
are **#wordpress** and **#wordpress-dev**, on irc.freenode.net. tomorrow on [November 6, 2013 19:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20131106T1900),
where we can continue the conversation and brainstorm how best to break up the work.

[#coding-style](https://make.wordpress.org/core/tag/coding-style/), [#javascript](https://make.wordpress.org/core/tag/javascript/)

### Share this:

 * [  Threads ](https://make.wordpress.org/core/2013/11/05/javascript-coding-standards/?share=threads)
 * [  Mastodon ](https://make.wordpress.org/core/2013/11/05/javascript-coding-standards/?share=mastodon)
 * [  Bluesky ](https://make.wordpress.org/core/2013/11/05/javascript-coding-standards/?share=bluesky)
 * [  X ](https://make.wordpress.org/core/2013/11/05/javascript-coding-standards/?share=x)
 * [  Facebook ](https://make.wordpress.org/core/2013/11/05/javascript-coding-standards/?share=facebook)
 * [  LinkedIn ](https://make.wordpress.org/core/2013/11/05/javascript-coding-standards/?share=linkedin)

 1.  ![](https://secure.gravatar.com/avatar/08f5251e656bb9e514f0991825afcfed1053665cc3b79036b6c229552fd6ccd0?
     s=32&d=mm&r=g)
 2.   [Pbearne](https://profiles.wordpress.org/pbearne/)  9:55 pm _on_ November 5, 
     2013
 3.  I will be happy do a bit of this.
 4.  ![](https://secure.gravatar.com/avatar/c5a8ef92e2c96e80ead10c58086bdbfcd803797e40e45a409a8ff50d83bfb586?
     s=32&d=mm&r=g)
 5.   [deltafactory](https://profiles.wordpress.org/deltafactory/)  9:57 pm _on_ November
     5, 2013
 6.  I’ve been thinking about threequals and curly-braces since Boston. It’s hard to
     break the habit.
 7.  I’d like to help with the cleanup effort. It would benefit me to familiarize myself
     with more of the JSJS JavaScript, a web scripting language typically executed 
     in the browser. Often used for advanced user interfaces and behaviors. bits of
     WordPress.
 8.  ![](https://secure.gravatar.com/avatar/ba62bd9438e4b28c6992ed05912f05c528bb97b5c3eef0369297fdc8a026083b?
     s=32&d=mm&r=g)
 9.   [Mike Bijon](https://profiles.wordpress.org/mbijon/)  9:58 pm _on_ November 5,
     2013
 10. 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.
 11. On the + side, adopting jQuery’s standards wholesale should reduce maintenance&
     debate. Plus, getting started sooner than later to *any* standard should help 
     speed JSJS JavaScript, a web scripting language typically executed in the browser.
     Often used for advanced user interfaces and behaviors. work & maybe help a few
     overly-debated JS tickets in TracTrac An open source project by Edgewall Software
     that serves as a bug tracker and project management tool for WordPress..
 12. Looking forward to seeing the sprint schedules
 13.  * ![](https://secure.gravatar.com/avatar/a498e093283b7b42aa63d5f75851cda7ec4c4e2137cb8482e02d3181b48eafa3?
        s=32&d=mm&r=g)
      *  [K.Adam White](https://profiles.wordpress.org/kadamwhite/)  10:02 pm _on_ 
        November 5, 2013
      * I’d welcome your help in figuring that schedule out, Mike! Hope to see you 
        in IRCIRC Internet Relay Chat, a network where users can have conversations
        online. IRC channels are used widely by open source projects, and by WordPress.
        The primary WordPress channels are **[#wordpress](https://make.wordpress.org/core/tag/wordpress/)**
        and **[#wordpress-dev](https://make.wordpress.org/core/tag/wordpress-dev/)**,
        on irc.freenode.net. tomorrow
 14. ![](https://secure.gravatar.com/avatar/82e095c8bc229017b128e53940ea534aa31f6624431bedee24c7e8756e42dd1c?
     s=32&d=mm&r=g)
 15.  [adamsilverstein](https://profiles.wordpress.org/adamsilverstein/)  10:27 pm 
     _on_ November 5, 2013
 16. Great post, thanks! I will try to make the meeting tomorrow and assist in the 
     cleanup effort.
 17. ![](https://secure.gravatar.com/avatar/691090f38918a05360981a204985d62e29ebfaaf6d94a2180e7bbae0954e8a48?
     s=32&d=mm&r=g)
 18.  [Matt Wiebe](https://profiles.wordpress.org/mattwiebe/)  10:46 pm _on_ November
     5, 2013
 19. I have another (virtual) meeting at the same time, but I should be able to chime
     in.
 20. Thanks for pushing this forwards [@kadamwhite](https://profiles.wordpress.org/kadamwhite/)
     🙂
 21. ![](https://secure.gravatar.com/avatar/0e1538b159a84627660256ac7b69a301ca2b9877a6643622d789f2503c5344d6?
     s=32&d=mm&r=g)
 22.  [ericsherred](https://profiles.wordpress.org/ericsherred/)  10:59 pm _on_ November
     5, 2013
 23. Sounds like fun to me.
 24. ![](https://secure.gravatar.com/avatar/62ed6669556644a294591975f01137cd76ea6d1dcd8bf8b3328c1e2bf6e2a80d?
     s=32&d=mm&r=g)
 25.  [Dion Hulse](https://profiles.wordpress.org/dd32/)  12:07 am _on_ November 6,
     2013
 26. 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.
 27.  * ![](https://secure.gravatar.com/avatar/73c1045212929211deda7262005831319397c68d340a8c41d53633b3f7e7f129?
        s=32&d=mm&r=g)
      *  [Andrew Ozz](https://profiles.wordpress.org/azaozz/)  1:12 am _on_ November
        6, 2013
      * 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.
         - ![](https://secure.gravatar.com/avatar/62ed6669556644a294591975f01137cd76ea6d1dcd8bf8b3328c1e2bf6e2a80d?
           s=32&d=mm&r=g)
         -  [Dion Hulse](https://profiles.wordpress.org/dd32/)  1:19 am _on_ November
           6, 2013
         - I thought I’d heard a rumour of an early IE bugbug A bug is an error or 
           unexpected result. Performance improvements, code optimization, and are 
           considered enhancements, not defects. After feature freeze, only bugs are
           dealt with, with regressions (adverse changes from the previous version)
           being the highest priority... but you’re probably right, defining it earlier
           is most likely only a parsing optimization, something we probably don’t 
           need to worry about.
         - ![](https://secure.gravatar.com/avatar/4a6c8596f55cd3c63ca03cf04f32027ab8cd3dd4e45fb743e74db5d5954e6c26?
           s=32&d=mm&r=g)
         -  [Tom McFarlin](https://profiles.wordpress.org/tommcfarlin/)  1:52 am _on_
           November 6, 2013
         - +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)[http://www.jslint.com/msgs.html](http://www.jslint.com/msgs.html)
         - ![](https://secure.gravatar.com/avatar/a498e093283b7b42aa63d5f75851cda7ec4c4e2137cb8482e02d3181b48eafa3?
           s=32&d=mm&r=g)
         -  [K.Adam White](https://profiles.wordpress.org/kadamwhite/)  2:14 am _on_
           November 6, 2013
         - 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 JSJS JavaScript, a web scripting language typically executed in the
           browser. Often used for advanced user interfaces and behaviors. engine).
           There’s actually a “onevar” parameter in JSHint to enforce this style.
      * ![](https://secure.gravatar.com/avatar/0fc544847c542eeb35059d95179a45d39f4b1f63cc37ad8ff41c04ec43fd499e?
        s=32&d=mm&r=g)
      *  [WraithKenny](https://profiles.wordpress.org/wraithkenny/)  2:10 am _on_ November
        6, 2013
      * I think it’s better, considering `for ( i = 0; i < 100; i++ ) { … } … var i
        = 2; alert( i );` would be confusing ('100') because of hoisting.
         - ![](https://secure.gravatar.com/avatar/0fc544847c542eeb35059d95179a45d39f4b1f63cc37ad8ff41c04ec43fd499e?
           s=32&d=mm&r=g)
         -  [WraithKenny](https://profiles.wordpress.org/wraithkenny/)  3:01 am _on_
           November 6, 2013
         - To be more clear `for ( var i = 0; i < 100; i++ ) { … } ` the `i` isn't 
           hoisted.
         - ![](https://secure.gravatar.com/avatar/0fc544847c542eeb35059d95179a45d39f4b1f63cc37ad8ff41c04ec43fd499e?
           s=32&d=mm&r=g)
         -  [WraithKenny](https://profiles.wordpress.org/wraithkenny/)  3:41 am _on_
           November 6, 2013
         - bah, it is hoisted.
 28. ![](https://secure.gravatar.com/avatar/73c1045212929211deda7262005831319397c68d340a8c41d53633b3f7e7f129?
     s=32&d=mm&r=g)
 29.  [Andrew Ozz](https://profiles.wordpress.org/azaozz/)  1:47 am _on_ November 6,
     2013
 30. Re-reading jQuery CoreCore Core is the set of software required to run WordPress.
     The Core Development Team builds WordPress. JavaScriptJavaScript JavaScript or
     JS is an object-oriented computer programming language commonly used to create
     interactive effects within web browsers. WordPress makes extensive use of JS for
     a better user experience. While PHP is executed on the server, JS executes within
     a user’s browser.
      [https://www.javascript.com](https://www.javascript.com/) 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 PHPPHP
     The web scripting language in which WordPress is primarily architected. WordPress
     requires PHP 7.4 or higher and current JSJS JavaScript, a web scripting language
     typically executed in the browser. Often used for advanced user interfaces and
     behaviors. coding standards. We also (used to?) have few more, like the strong
     discouragement of using nested ternary operators.
 31. 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?
 32.  * ![](https://secure.gravatar.com/avatar/4a6c8596f55cd3c63ca03cf04f32027ab8cd3dd4e45fb743e74db5d5954e6c26?
        s=32&d=mm&r=g)
      *  [Tom McFarlin](https://profiles.wordpress.org/tommcfarlin/)  1:58 am _on_ 
        November 6, 2013
      * I’m for the adoption of jQuery standards as much as possible; however, I do
        err on the side of keeping the JavaScriptJavaScript JavaScript or JS is an 
        object-oriented computer programming language commonly used to create interactive
        effects within web browsers. WordPress makes extensive use of JS for a better
        user experience. While PHP is executed on the server, JS executes within a 
        user’s browser.
         [https://www.javascript.com](https://www.javascript.com/) 
        closely-related to our PHPPHP The web scripting language in which WordPress
        is primarily architected. WordPress requires PHP 7.4 or higher 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.”
      * ![](https://secure.gravatar.com/avatar/a498e093283b7b42aa63d5f75851cda7ec4c4e2137cb8482e02d3181b48eafa3?
        s=32&d=mm&r=g)
      *  [K.Adam White](https://profiles.wordpress.org/kadamwhite/)  2:26 am _on_ November
        6, 2013
      * 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
        PHPPHP The web scripting language in which WordPress is primarily architected.
        WordPress requires PHP 7.4 or higher.
      * 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.
         - ![](https://secure.gravatar.com/avatar/73c1045212929211deda7262005831319397c68d340a8c41d53633b3f7e7f129?
           s=32&d=mm&r=g)
         -  [Andrew Ozz](https://profiles.wordpress.org/azaozz/)  2:47 am _on_ November
           6, 2013
         - 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 PHPPHP The web
           scripting language in which WordPress is primarily architected. WordPress
           requires PHP 7.4 or higher coding standard too, just not sure if it needs
           to be enforced.
 33. ![](https://secure.gravatar.com/avatar/4a6c8596f55cd3c63ca03cf04f32027ab8cd3dd4e45fb743e74db5d5954e6c26?
     s=32&d=mm&r=g)
 34.  [Tom McFarlin](https://profiles.wordpress.org/tommcfarlin/)  2:02 am _on_ November
     6, 2013
 35. I’m going to try to make it to the meeting – what server and channel will the 
     meeting take place?
 36.  * ![](https://secure.gravatar.com/avatar/a498e093283b7b42aa63d5f75851cda7ec4c4e2137cb8482e02d3181b48eafa3?
        s=32&d=mm&r=g)
      *  [K.Adam White](https://profiles.wordpress.org/kadamwhite/)  2:12 am _on_ November
        6, 2013
      * Good point, that’s something people need to know: Freenode, right in [#wordpress-dev](https://make.wordpress.org/core/tag/wordpress-dev/).(
        Note: That time was selected because I was not aware of any conflicting meetings;
        If anybody has a meeting in [#wordpress-dev](https://make.wordpress.org/core/tag/wordpress-dev/)
        scheduled at that time, please let us know and we’ll get another room!)
 37. ![](https://secure.gravatar.com/avatar/e34030960493c000a37fecd8a34be54f98c60a0f93914015c21f8feeddf51f6c?
     s=32&d=mm&r=g)
 38.  [Paul Clark](https://profiles.wordpress.org/pdclark/)  4:09 am _on_ November 
     6, 2013
 39. Count me in for a JSHint sprint!
 40. ![](https://secure.gravatar.com/avatar/9e6583bcbe4831c87f40523ded6be4ca1ad48833133bd542c4672d4ca4e54081?
     s=32&d=mm&r=g)
 41.  [Gary Jones](https://profiles.wordpress.org/garyj/)  9:22 am _on_ November 6,
     2013
 42. Not sure I can make it tonight, so I’m leaving my thoughts here that hopefully
     someone can take into consideration during the meeting.
 43. General adoption of the jQuery standards: +1
      Two exceptions to those standards:
     +1
 44. 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.
 45. 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.
 46. I’m up for helping out with some JSJS JavaScript, a web scripting language typically
     executed in the browser. Often used for advanced user interfaces and behaviors.
     tidying.
 47. ![](https://secure.gravatar.com/avatar/a498e093283b7b42aa63d5f75851cda7ec4c4e2137cb8482e02d3181b48eafa3?
     s=32&d=mm&r=g)
 48.  [K.Adam White](https://profiles.wordpress.org/kadamwhite/)  1:00 am _on_ November
     10, 2013
 49. Just a heads-up for everybody waiting for an update on this: Hang tight for a 
     day or two, I’m working with [@kpdesign](https://profiles.wordpress.org/kpdesign/)
     to get the JSJS JavaScript, a web scripting language typically executed in the
     browser. Often used for advanced user interfaces and behaviors. Standards handbook
     page updated and up to our standards.
 50. ![](https://secure.gravatar.com/avatar/0f2e7596b7dc9c730a4dc32c4498b1963ad03daa2ff6eb781a6b28a4a29f528b?
     s=32&d=mm&r=g)
 51.  [Lance Willett](https://profiles.wordpress.org/lancewillett/)  3:36 am _on_ November
     12, 2013
 52. Thanks for your work on this—more vigorous standards and cleaner code FTW.

Comments are closed.

# Post navigation

[← #22862: Consider a CSS preprocessor](https://make.wordpress.org/core/2013/11/05/22862-consider-a-css-preprocessor/)

[Open Sans, bundling vs. linking →](https://make.wordpress.org/core/2013/11/11/open-sans-bundling-vs-linking/)