Add new API info to each plugin page #2161

toddparker opened this Issue Jul 28, 2011 · 14 comments

7 participants


We have an planned addition to our docs pages that adds theAPI options, methods and events. An example of the new format is here:

We're looking for help with adding this format to all the other plugin pages so if you'd like to help, here's how:
1. Add a comment to this issue indicating what plugin pages you want to tackle so there is no duplication of effort
2. Update the docs pages following these guidelines:
3. Submit as a pull request.

Bask in the glow of contributing such a helpful thing to the project. Any takers?


I'll take an easy one ""


Thanks ovargas27! Let me know if you run into issues or questions.


I'm working in radio buttons so I'll work in checkboxes


I'll take the


Please take a look at
I started this project with JQMalpha2 and I was planning on putting it up on a real domain when 1.0 is released.
You might be interested in adding this as an element of the new docs.

My project works like this:
I automatically fetch every occurance of a 'data-something' attribute and collect all its values that I find. A separate file contains descriptions so that the automated fetching won't force me to do any merging with old versions.

If you decide to host this as a part of your docs I will keep maintaining it.


Edit: Sorry, confused a little, I'll try out the instead (buttons seem to exist outside of the forms folder)


I have some additional ideas for the documentation. I think the documentation pages should use a multiple page setup, or at least links with the data-prefetch attribute set to true. People reading these API docs typically use a desktop computer and want to navigate fast without having to wait. Clicking the tabs now generates a request and after that a fading page transition happens. I would like to see no request and no transition to make the API docs as responsive as possible.

Apart from that, I'm charmed about how the jQuery UI documentation is written (e.g. You see a demo first, some information about the demo, an expandable div which contains the source and 5 tabs (overview, options, methods, events and theming). I personally use it quite often and it works really good for me, maybe the documentation of the jQuery mobile API can be (a little bit) like this?


I'll take the "flip toggle switch" next


@Toverbal - I think adding the prefetch attributes to the tabs is probably a good idea. I like the UI docs too (I helped design them) but the more narrative style on the landing page is better for less technical users IMHO. It's similar in that we have options/method/event tabs, just like UI.

@caseyjustus - thanks!


@toddpaker - okay, I can live with that, but as am developing now I often visit the API pages and when I view the source to check how certain elements are designed html-wise I often am seeing the wrong code, because the navigation uses Ajax, that is kinda frustrating. That's why I think best is to get a multi-page setup and navigate without Ajax, so the thing you see on screen is always the source you see when you hit ctrl+u (in FireFox or Chrome).


We're very close to landing pushState so you will be able to simply refresh, then view source on a browser that supports this. Even now, you just need to edit the URL to be the path for the page, refresh and view source. Making this a multi-page wouldn't really solve the problem and would prevent us from being able to deep link to one of the tabs.


@toddparker - I understand. I actually am editing the url to get to the right page, so I figured that one out, thanks for mentioning. The pushstate will be fine. The deeplink argument makes sense, so it'll be fine the way it is :)

jQuery Foundation member

Thanks for all the help everyone!!

@toddparker - shall we remove (or update) this page

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment