jQuery Foundation 2014 roundup

In January 2014, now 11 months ago, the jQuery Foundation published its new mission statement:

To improve the open web, making it accessible for everyone, through the development and support of open source software, and collaboration with the development community.

I was one of the directors of the jQuery Foundation who worked on that statement, along with the more detailed explanations. There are two areas in particular that I want to go into, explaining what we’ve done in those areas in the past, this year in particular and what we’ve planned for the future. This is my own perspective.

Standards

Working with standards bodies, such as W3C, WHATWG, and TC39, to build the open standards that browser vendors and developers rely on.

The jQuery Foundation became a member of both W3C and ECMA when we founded it in early 2012. Since then we’ve had Yehuda Katz and Rick Waldron, as representatives of the jQuery Foundation, on the TC39 committee, which is responsible for the ECMAScript specification, also known as JavaScript. Rick has been publishing notes of the meetings, providing visibility into the complete proceedings. Yehuda has also been involved in various groups at the W3C, like the TAG (there’s a photo here with the TAG from 2013, including Yehuda and Tim Berners-Lee). There’s probably a lot more going on, but without a somewhat abstract overview, it is rather difficult to follow. This is one of the problems we’ve been discussing on the board: How can we communicate to the public what we’re doing for web standards? We want the attention and feedback of web developers that eventually have to use those standards, once implemented in web browsers. Following the many W3C and other standards mailing lists is hardly practical for most web developers.

I intend to write more about this in the future. Maybe I can interview Yehuda every once in a while and then write about his standards activities. Or work with Rick to create summaries of his meeting notes, that are more accessible to those not attending the meetings, by focusing on the higher level concepts, not so much the nitty gritty details of the language specification.

Libraries and tools

Working with individuals and organizations to implement libraries, frameworks and tools for web developers.

This is something I’ve been involved in much more directly. An important point here is that those libraries, frameworks and tools don’t have to be owned by the jQuery Foundation. In some cases that makes sense, but there are many projects where we collaborate with other projects.

jQuery Core

Of course we still maintain jQuery itself, often referred to as jQuery Core. The Core team recently published their plans for jQuery 3.0 and jQuery Compat 3.0 (note that its Compat, from Compability, not Compact). From the announcement:

  • If you need support for the widest variety of browsers including IE8, Opera 12, Safari 5, and the like, use the jQuery-Compat 3.0.0 package. We recommend this version for most web sites, since it provides the best compatibility for all website visitors.
  • If your web site is built only for evergreen leading-edge browsers, or is an HTML-based app contained in a webview (for example PhoneGap or Cordova) where you know which browser engines are in use, go for the jQuery 3.0.0 package.
  • Until we announce otherwise, both packages will contain the same public APIs in correspondingly-numbered major and minor versions. This should make it easy for developers to switch between the two and be maximally compatible with third-party jQuery plugins.
  • The point of the jump to 3.0 is mostly to change jQuery’s implementation of Promises, to make them compatible with the standard. The decision to make that change took a while, since the implementation in jQuery existed long before the standard was written, and breaking code that relies the implementation in jQuery is not something undertaken lightly. But for the sake of standardisation, its going to happen as part of the 3.0 major release.

    jQuery UI

    jQuery UI has been around almost as long as jQuery Core, though I think its future is much more exciting, and where jQuery could be considered almost done, we still have a lot of work ahead of us for jQuery UI. One of the efforts that has been going on for several years by now is the adoption of pointer events, to replace both mouse and touch events. Pointer events provide a sane unified event model, unburdened by Apple’s patent threat. While Chrome recently decided not to implement pointer events, we hope to change their mind by getting to the point where a pointer event polyfill (PEP) is only needed in Chrome, thus making it the slowest browser to handle pointer events, which they hopefully wouldn’t let sit for long.

    Another big effort is in the area of CSS frameworks. jQuery UI introduced its own CSS framework with 1.7, released in March 2009, but since that focused on styling widgets and not generic page elements like headers or forms, it never gained as much popularity as more recent projects like Bootstrap or Zurb Foundation. We’ve looked into adopting an existing CSS framework to replace the one in jQuery UI, and talked to many project teams for that. In the end we’ve decided to start a new effort, yet unnamed, to create a new CSS framework (the GitHub repo will probably be renamed once the project has a name), to be used by jQuery UI and jQuery Mobile, but also, hopefully, many other projects. Even if everyone still rolls their own, we hope to create at the very least naming conventions that can be shared. As Scott wrote:

    The first layer is a set of class names and DOM hierarchies for everyone to follow. Then we’ll build an implementation of that, which hopefully many will use. But the most important thing is that no matter how many implementations may exist, if they all use the same class names and DOM hierarchies, then they’ll all be interchangeable.

    Hopefully we end up with lots of “themes” built on top of our structural work, rather than lots of varying implementations of the structural parts, since we’re trying to reduce the amount of duplicated effort and the overwhelming choice that developers face today.

    Another important point of this new effort is to implement CSS performance testing. This is something the Topcoat team has been doing, and I’m excited about them joining our effort. Again, even if everyone is rolling their own, sharing tools to test and improve the performance of CSS frameworks will benefit everyone.

    QUnit

    A new release of QUnit is right around the corner, introducing better APIs for async testing, ala grunt with an assert.async() method and with direct support for Promises, and many other improvements. In parallel to the new release we’ve also started a project, lead by James Greene, to create a standard for reporters for testing tools. Let’s say you want to run your JavaScript unit tests on BrowserStack or SauceLabs or inside PhantomJS, or on Travis or Jenkins or other CI systems. In each case, you need to report the results back to the user. Currently each testing tool of the above has to write a separate custom integration layer for each unit testing tool, like Mocha, Jasmine or QUnit. This is something the js-reporters projects addresses. So far we’ve worked out a list of event names that can be used by all unit testing frameworks. There’s a lot more to do and as usual with standards efforts, it takes time.

    Globalize

    Globalize is another jQuery Foundation project that has been around for a while. It started with a culture database extracted from Microsoft’s .NET platform. This was a decent starting point, since it covered a lot of cultures, many more than gathering contributions from individual users would have provided. But there were also many issues in this database. Either entries were just wrong, or categories were missing, for example data to format relative time, like “5 minutes ago” or “in 2 years”. The idea to migrate to CLDR as the culture database came up in 2012. The ball got rolling when Rafael Xavier, a member of the jQuery UI project, started looking at the newly released JSON version of CLDR. Since then he rewrote Globalize on top of CLDR, significantly extending the available features, e.g. adding plurals and message formatting.

    A few months into this effort we realized that other projects could benefit from CLDR as well. We suggested collaborating with Moment, probably the most popular library for formatting and parsing dates. Moment still uses a culture database based on user contributions. The maintanence of that database caused the original Moment author, Tim Wood, to abandon the project. Unfortunately migrating to CLDR is a big effort that the current maintainers haven’t been able to make progress on.

    To reduce the effort of using CLDR, Rafael has published two modules: cldr-data makes it easy to specify CLDR as a peer dependency (in npm; in bower it’s a simple dependency), cldrjs simplifies traversal of the CLDR JSON data structure. Both can be used independently of Globalize, for which they’re dependencies. Rafael has started a pull request for IBM’s ECMA-402 (Intl) polyfill to use cldr-data. We’ve also had discussions with the team at Yahoo behind FormatJS to adopt cldr-data, and also to focus efforts on a single Intl polyfill.

    Recently Rafael started a mailing list, to discuss and collaborate on globalization projects for JavaScript. He also created a site and gathered many contributions to list globalization projects, their strength and weaknesses, along with a feature grid. This is both a great help for maintainers of these projects, since they can see what others are doing and where they should concentrate their efforts, and for users, since they don’t have to find and compare all the available solutions.

    We’re currently working towards Globalize 1.0. Once that is done we’ll spend more time looking at ECMA-402 aka Intl, to see if Globalize could wrap or use the formatting APIs (Intl has no parsing). We want to get everyone to use and contribute to a single Intl polyfill (there’s currently at least two). We’d still like to get Moment to switch to CLDR, and discussed them adopting Globalize for their date parser and formatter.

    There is more going on within the jQuery Foundation’s own projects. For the rest of this post, I want to cover one of the projects we’ve been contributing to.

    jscs

    jscs is the “JavaScript Code Style checker”. Unlike jshint, which looks at code semantics, jscs only cares about code style. Together they are very useful tools for writing consistent JavaScript. jscs was started by Marat Dulin. The two most active maintainers are now Oleg Gaidarenko and Mike Sherov, both members of the jQuery Core project. Within the various projects of the jQuery Foundation, we’re using jscs with its “jquery” preset, one of currently eight presets. The presets are a great way to start using jscs without spending much time configuring it. I’ve recently started using jscs on a project and tried several presets, then picked the one that produced the least number of errors. After fixing the remaining errors, I now have jshint and jscs preventing regressions in code semantics and code style, running locally on each developer’s machine and remote on a continuos integration system.

    There are many more projects we’re contributing to, but that’s also something for another day. For now I hope that this post gives a good idea of what the jQuery Foundation is doing for the open web and web developers everywhere.

    Release: Validation Plugin 1.13.1

    This is a patch release for the jQuery Validation Plugin. It contains a few changes, though most notable is the fix for the newly implemented aria-describedby-based behaviour for error elements introduced in 1.13.0. That turned out to have a few issues which are now addressed.

    Thanks to Markus Staab, who’s have been helping with ticket triage.

    Download this release.

    If you use the plugin, please donate or ask your boss to make a donation! This helps to run the plugin site and makes releases like this one possible.

    Click here to lend your support to: jQuery Validation Plugin and make a donation at www.pledgie.com !

    4 people contributed code to this release. A big thank you to: Barry vd. Heuvel, colemanw, Damian Mooyman and fernandopasse. Also thank you to everyone who reported issues on GitHub or commented on them.

    As usual:
    • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
    • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

    The full changelog:

    Additionals

    • Add postalcodeBR method (cc6c4a4)
    • Fix pattern method when parameter is a string (4cecd73)

    Core

    • Ignore readonly as well as disabled fields. (9f4ba10)
    • Improve id escaping, store escaped id in describedby (#1269, d36d1bc)
    • Escape id/name before using it as a selector in errorsFor (#1275, 20f3e9f)
    • Allow 0 as value for autoCreateRanges (fe14d00)
    • Apply ignore setting to all validationTargetFor elements (f1c611e)
    • Use return value of submitHandler to allow or prevent form submit (#650, 8b2f1e0)
    • Explicit default for focusCleanup option (#676, 0cb3c95)
    • Fix incorrect regexp (#1200, c054707)
    • Don’t trim value in min/max/rangelength methods (#1274, 452b823)

    Release: Validation Plugin 1.13.0

    I’m happy to announce a new release of the jQuery Validation Plugin. It’s been just three months since 1.12, yet this release brings lots of small and two big improvements. For those two I have to thank two people in particular.

    First, Damian Mooyman, heavily improved the error message display implementation. From the outside, nothing really changed (this is a minor release after all, so backwards compatibility is a given). Though once you switch the bad default for the errorPlacement option to something like a <span> (this default will change in 2.0), the error label gets associated to the element using aria-describedby. Along with the other ARIA attributes the plugin is already using, this gives screenreader users a much better experience. There’s lots of details involved, which don’t quite fit into this blog post. If you’re interested, check out the discussion for the two pull requests that made this happen, #1083 and #1140.

    The other big one is support for AMD, implemented by Lars Laade. While there was a lot less discussion, he had to update most of the source files. I especially like that the UMD wrappers are added as part of the build step, keeping them out of the source files themselves. Again, if you’re interested in the details, check out pull request #1106.

    I also want to thank Nick Schonning and Markus Staab, who have been helping out with ticket triage and lots of smaller details.

    Download this release.

    If you use the plugin, please donate or ask your boss to make a donation! This helps to run the plugin site and makes releases like this one possible.

    Click here to lend your support to: jQuery Validation Plugin and make a donation at www.pledgie.com !

    18 people contributed code to this release. A big thank you to: ado130, Damian Mooyman, Diego, J. Randall Owens, Jamie R. Rytlewski, jcare44, Jeremy Forsythe, Jyrki Lilja, Lars Laade, lboullo0, Manuel Dalla Lana, Markus Staab, Nano Taboada, NetImperia, Nick Schonning, paladox2015, pylover, Wing. Also thank you to everyone who reported issues on GitHub or commented on them.

    As usual:
    • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
    • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

    The full changelog:

    All

    • Add plugin UMD wrapper

    Core

    • Respect non-error aria-describedby and empty hidden errors
    • Improve dateISO RegExp
    • Added radio/checkbox to delegate click-event
    • Use aria-describedby for non-label elements
    • Register focusin, focusout and keyup also on radio/checkbox
    • Fix normalization for rangelength attribute value
    • Update elementValue method to deal with type=”number” fields
    • Use charAt instead of array notation on strings, to support IE8(?)

    Localization

    • Fix sk translation of rangelength method
    • Add Finnish methods
    • Fixed GL number validation message
    • Fixed ES number method validation message
    • Added galician (GL)
    • Fixed French messages for min and max methods

    Additionals

    • Add statesUS method
    • Fix dateITA method to deal with DST bug
    • Add persian date method
    • Add postalCodeCA method
    • Add postalcodeIT method

    Exporting ScreenFlow recordings for HD YouTube uploads

    ScreenFlow works pretty well for me for all kinds of screencasts. Its default settings are pretty bad though, when I want to upload the exported video to YouTube and have is played back with decent quality. The problem is the default scale setting: The “Web – High” preset suggests to scale the video down by 50%. That reduces the file size a lot, but also produces output that will show up as “240p” on YouTube, which looks pretty awful.

    For 720p videos, you want to set the resolution to exactly 1280×720. Export and upload that and YouTube will be able to play back the video with 720p “HD”, which looks so much better.

    I’m recording videos on my MacBook Air 13″, which has a native resolution of 1440×900. That’s not the same ratio as 1280×720. For a recent recording I resized the canvas of the recording from 1440×900 to 1440×810. That cuts of some stuff at the top, bottom or both, but that worked fine in my case. The end result is a ratio that matches the 720p ratio, so scaling it down won’t distort the result at all.

    Note that you need a verified YouTube account to upload videos longer than 15 minutes. Make sure you have that before attempting to upload an hour long screencast, and having to start over after the video gets rejected as too long.