Developer documentation common to all jQuery projects
To build and deploy your changes for previewing in a jquery-wp-content
instance, follow the workflow instructions from our documentation on contributing to jQuery Foundation web sites.
Developer documentation common to jQuery projects
Home Page: https://contribute.jquery.org
License: Other
Developer documentation common to all jQuery projects
To build and deploy your changes for previewing in a jquery-wp-content
instance, follow the workflow instructions from our documentation on contributing to jQuery Foundation web sites.
We should have done this from the outset, but it makes more sense on .org than .com
This repo name needs to be changed, and the urls have to be changed in jquery/jquery-wp-content sites.php and menu_header.php, and the DNS entries have to be updated.
Importing this here instead of bugs.jquery.com/2
We need to document how to set your name and email address in Git. We should link to this from Contributing to Code, Commits and Pull Requests, and even the CLA page.
In page/community.md
, following the mold of the triage page, put together some information about contributing to the community, including explaining that (obviously) contributing to any of the areas of any project is contributing to the community. The page should go on to explain information about how to get involved with jQuery Events and running local meetups, and link to pages on the site explaining about IRC and support as well.
In page/support.md
, following the mold of the triage page, put together instructions on the basics of contributing support to other users of jQuery projects, e.g., the forums, IRC, stackoverflow, etc. Should include:
We provide information for contributors, but nothing for maintainers. While we don't add people to jQuery Core, we should generally give out more write access to spread the load. I've never seen anyone abuse that "power", while they usually become more engaged in the project, since they now have more authority and try to make that up in the necessary responsibility.
I've started putting together some guidelines for reviewing PRs, should be valid at least for QUnit and mostly jQuery UI: https://gist.github.com/jzaefferer/a93958b48faa55ff84c5
Do we just give maintainers read access to the CLA document? Or is there some other option?
Before we get too far down the road of actually setting up the subdomain (cc @gnarf37) , we should have one final discussion on whether the URL for this is contribute.jquery.com or contribute.jquery.org.
I don't have strong feelings either way. @dmethvin and I felt OK about .com but something about .org feels logical as well. Wanted to put this out there for discussion before it's finalised, however, so please give your thoughts on this.
Add a page that outlines the style guide for CSS across all jQuery projects.
Should either of these be violations:
a.snake_case
{
snake_case: a
}
Instead of /js-style-guide/ and /html-style-guide/ we should have a top-level /style-guide/ with /js/ and /html/ inside it. In the future, perhaps we'd add a /css/. This also allows us to have a single style-guide landing page that introduces the concept of sharing all the guides across all foundation projects, and would link to all. It's also consistent with learn.jquery.com/style-guide/
Just looking at the evidence: https://github.com/jquery/jquery/pull/1590/files
It seems like 100 characters might be a nice ideal, but that 120 characters would avoid some of the bending over backwards that we'd have to do.
Afaik they are only acceptable when a fall-through is needed. Otherwise use if/else.
Reference for formatting:
switch ( event.keyCode ) {
case $.ui.keyCode.ENTER:
case $.ui.keyCode.SPACE:
z();
break;
case $.ui.keyCode.ESCAPE:
y();
break;
default:
x();
}
On http://contribute.jquery.org/web-sites/, there's an anchor to "#exceptions":
with some exceptions <a href="#exceptions">*
but there is no corresponding target.
As per #14, there is now a top-level style guide page to give background information on our style guides, why following style guide is important, etc. At present, this page is not linked anywhere in the site but does exist.
https://github.com/jquery/contribute.jquery.org/blob/master/pages/style-guide.md
Need to look for the others, but the single string argument exceptions needs to go away:
// Nested calls
foo( bar(arg) );
Should be foo( bar( arg ) );
// Single argument string literal, no space
foo("bar");
Should be foo( "bar" )
.
// Inner grouping parens, no space
if ( !("foo" in obj) ) {
}
Should be if ( !( "foo" in obj ) ) {
Space omission is allowed when dereferencing an array:
array[0];
Should be array[ 0 ]
.
This is mostly for syncing with the Core team to see if there are any objections in dropping exceptions.
I would like to have a reference to JSCS options together with JSHint options.
That shoud be a good and quick reference to quick apply the style guide to external projects and to implement in jQuery projects that aren't entirely conformed with it.
Occasionally, the jQuery codebase goes over 100 characters a line for regexes (and potentially long urls in comments). E.g.:
bool: /^(?:checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped)$/i,
There are ways to split multiline regexes, but this involves using the constructor and having to double escape backslashes.
Should we make an exception for regex literals and comments? Note I'll be implementing this in JSCS no matter what we decide.
The CLA (http://contribute.jquery.org/CLA/) is not visible in the latest version of Firefox (21.0) on Mac OSX. it is also not visible on Safari 5.1.7 (which is old I admit, but is the latest on Mac OSX 10.6.8). However, it is visible with Safari 6.0.3 on Mac OS X 10.7.5. On both OSs, Chrome will show the form correctly (Version 27.0.1453.116). I am not too worried about Safari 5, but I am about Firefox 21.0.
Should we link to https://guides.github.com/overviews/os-contributing/ in our contributing docs?
We have this line in the style guide:
If the entire file is wrapped in a closure, the function body is not indented.
Since introducing UMD wrappers in jQuery UI, we use this inconsistently. The wrappers are indented: https://github.com/jquery/jquery-ui/blob/fd7e1e3040ec2c6edb4754135602b5c31678e659/ui/accordion.js#L12
The "factory" isn't: https://github.com/jquery/jquery-ui/blob/fd7e1e3040ec2c6edb4754135602b5c31678e659/ui/accordion.js#L27
We might as well not indent the UMD wrapper.
I noticed this while testing the latest esformatter version with jQuery UI files. esformatter's TopLevelFunctionBlock setting currently doesn't indent any top-level function scope, which used to work well before we introduced the UMD wrappers.
e.g. http://contribute.jquery.org/style-guide/js/#type-checks
The wiki supported this, which enabled nice link-ability such as:
http://docs.jquery.com/JQuery_Core_Style_Guidelines#Type_Checks
I'm not sure what format to use, WordPress' slug format would be best imho (to lower case, converting any special characters to dashes).
Maybe it can be done automatically on all content headings from jquery-wp-content, but for now adding here where it would be a regression from the wiki. Especially for coding styling, linking to sections is useful.
We skip indentation on the first level inside a function block that wraps the entire file.
At the bottom of this page http://contribute.jquery.org/markup-conventions/ there is a link to go to the reference docs for grid.
We'll have a reference eventually, but for now go here to see how to use the grid.
"go here" is a broken link.
Document how to write long blocks of chained method calls. Include rules for indentation from elements that change the stack.
Received via e-mail:
Howdy, I was reading the JavaScript Style Guide page on your site and found a couple errors.
Both are in the Multi-line Statements section:
That is all for now, Pete
In page/open-sourcemd
, we should have a page about the basics of getting started with open source, talking about things like
More ideas welcome. This page is not really supposed to be specific to jQuery and should be useful to anyone who's been using FOSS and wants some background on how to get involved and how to think about what they're signing up for :)
@Krinkle called me out for a possibly unclear NaN
test, and it seems worth including as a type check in the style guide.
Options:
name !== name
(more compressible; used in Sizzle funescape plus the just-added jQuery core condition)typeof name === "number" && isNaN( name )
(more comprehensible; used in jQuery.style and jQuery.isNumeric, the latter for lack of a variable)Would anyone object to implementing and documenting option 1?
We don't have rules on how to format ternary expressions. Accordingly we have quite a few styles for these:
// from core/css.js
// inline
parts = typeof value === "string" ? value.split(" ") : [ value ];
// from core/css.js
// line break after question mark and colon:
return rnumnonpx.test( computed ) ?
jQuery( elem ).position()[ prop ] + "px" :
computed;
// from ui/jquery.ui.progressbar.js
// line break after colon:
return this.indeterminate ? false :
Math.min( this.options.max, Math.max( this.min, newValue ) );
There's probably more variations.
@dmethvin @scottgonzalez @gibson042 do you have preferences on any of these?
In the "Chained Method Calls" section we have this special rule:
If the method changes the context, an extra level of indentation must be used.
This is extremely difficult (practically impossible) to check for automatically (jscs) or format automatically (esformatter).
Could we drop this rule?
How should this look like?
var eras = [ {
"name": "n. Chr.",
"start": null,
"offset": 0
} ];
According to the current styleguide, this should be correct. But I suspect the exception for whitespace around object expressions within function arguments also applies to array expressions. Which would look like this instead:
var eras = [{
"name": "n. Chr.",
"start": null,
"offset": 0
}];
We should add a note to let contributors know that their git config must match their CLA signature.
There is a typo in https://contribute.jquery.org/style-guide/
[…] rather than a a cacophony of competing coders […]
In page/code.md
, following the mold of the triage page, put together instructions on the basics of contributing code to any jQuery project, e.g., forking repos, making pull requests, writing tests, not removing tests, following the style guide, using grunt, etc, with links to all the project repos.
This should probably link to the Won't Fix page, among other things as well.
Most of http://learn.jquery.com/style-guide/ should be moved here as the prose style guide spans everything from READMEs to API documentation to articles and tutorials.
The index page will need to be updated as well, as that links to the various existing guides.
It would seem that a number of the issues discussed in the Won't Fix page are not up-to-date with and make reference a future, but now complete, Sizzle rewrite. This needs to be brought up to date with jQuery 1.8+
Since IRC is so crucial to involvement in our projects, should we have a explaining that very fact, and then links to all of our channels, and resources for getting set up, using a bouncer, etc?
Alternatively, this could be maintained as the content of irc.jquery.com.
We'd link to this page in the header.
The http://jquery.github.com/brand.jquery.org/ style guide is slightly out of date and, and should not be a standalone site anyway. It does not belong in the brand.jquery.org repo after all, as the content is more technical than brand-oriented. Everything else on jquery.github.com has gone to contributed, and this document essentially constitutes our markup conventions.
Regarding questions like this: "@qunitjs I would like to translate http://qunitjs.com/ pages into Japanese. Can I have a permission to do it?" https://twitter.com/cssradar/status/313666013185077248
Apart from pointing at the license for the content, we want to figure out how to organize translations. One idea that @rdworth or @gnarf37 had in Vienna was to have a repository per locale, with folders for each site repository (the domain names). That way translations can have their own release cycle and contributors.
This may also become work for brand and infrastructure, so this is just a starting point.
Perhaps on the triage page, or on a separate page linked from it, we should codify our example triage answers for various situations - will be useful for us and new prospective triagers.
This style guide for CSS looks pretty good to me: http://mdo.github.io/code-guide/#css
While that is online and actively maintained, we could just link to it. Its MIT licensed, so we could also integrate it here.
From the HTML section we could take over the sections on "Attribute order" and "Boolean attributes", if we want to adopt those.
In page/documentation.md
, following the mold of the triage page, put together instructions on the basics of contributing documentation to any jQuery project, e.g., forking repos, making pull requests, following the style guide, using grunt, etc, with links to all the project repos
http://contribute.jquery.org/bug-reports/ was ported from MediaWiki and updated to address all projects instead of just core. The content should be reviewed for completeness and links to latest releases and WIP builds for all projects should be included (preferably by linking to pages that will be updated when releases occur).
This page isn't currently discoverable without searching the site.
This site is going to supersede our developer documentation at jquery/jquery.github.com. Move the content here.
The description of this repo points to http://contrbute.jquery.org instead of http://contribute.jquery.org
I know, I know, screen shot or it didn't happen:
In page/web.md
, following the mold of the triage page, put together instructions on the basics of contributing to jQuery Foundation websites, including:
For jQuery UI we have an existing guide for commit messages: http://wiki.jqueryui.com/w/page/25941597/Commit%20Message%20Style%20Guide
We could just put that on this site as-is. We could try to standardise commit messages across our projects, probably something to discuss at the next Dev Leads meeting. Maybe we can gather some input here until that next meeting?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.