What does type="Utility" mean in position entry? I guess it is a mistake and should be removed.

To help document how to contribute to the repo.

Most <desc> elements are auto-wrapped in <p> elements, which results in invalid output as the descriptions may contain any markup, such as lists. We should switch the <p> to <div>.

The generated pages contain some <desc> elements. We need to fix the copying of these elements so that only the content, not the <desc> element itself, is copied. In some cases, nested markup is being removed as well. For example, the option method has <code> elements in the source which do not exist in the output.

See http://api.jquery.com/jQuery.ajax/

For example, put Type on the right of the name, put default in smaller type below.

jquery.ui.core extends jquery with few functions like disableSelection, enableSelection, etc.
Do you plan to document those functions as they are implemented under jQueryUI?

Hi,

The following widgets have an event prefix diferrent than the widget's name. This seems undocumented on the website and in my opinion should be.

ui/jquery.ui.draggable.js: widgetEventPrefix: "drag",
ui/jquery.ui.droppable.js: widgetEventPrefix: "drop",
ui/jquery.ui.resizable.js: widgetEventPrefix: "resize",
ui/jquery.ui.slider.js: widgetEventPrefix: "slide",
ui/jquery.ui.sortable.js: widgetEventPrefix: "sort",
ui/jquery.ui.spinner.js: widgetEventPrefix: "spin",

For example for the slider, how a user knows he have to bind on 'slidestop' event instead of 'sliderstop'.
Some other widgets doesn't use this widgetEventPrefix and widget's name is used as a prefix, this is confusing to me.

So maybe would be a good to have 'event prefix' section on each widget doc (on the event section)?

Just an idea..

In the old page, widgets used to have a list of their dependencies (e.g. autocomplete requires the core, widget and mouse modules and so on), which was kind of handy for those of us who include the individual files one-by-one (and merge them later in the framework).

Also, it would be good if you could clarify external dependencies. Right now, I'm looking at the spinner documentation and I couldn't say if Globalize is mandatory or optional. The demos use it and some options kind of suggest it should be there, but it would be nice if you could just spell it out somewhere, so that we don't have to find out by trial and error

@flack jquery/jqueryui.com#14

The index page should provide an overview of the docs, mention which version the docs apply to, where to find older versions, link to intro tutorials on the learn site, etc.

Pending xinclude update from @rdworth

Why was chosen to have all public widget methods documented in each single widget entry instead of only in widget.xml?
Is it only to have simplicity during transformation or there is another reason? widget.xml lists only its private methods.

Possible solutions:

• Actually create an All category and put every entry into it.
• Create an empty /category/All page that uses a custom template.
• Write a hack to just make the URL work.

@nacin attempted writing a hack, but I couldn't get it to work locally.

We should just have a single XSL for jQuery UI and jQuery Mobile. Right now we have separate files with slight differences. Ideally we would merge with the jQuery Core XSL as well.

There needs to be a way to mark a method/option/event/whatever as being added and/or deprecated as of some version.

All widgets that build on top of form controls kill the ability to use the native change event since we programmatically change the field's value. We should mention this in the docs for each widget.

At least for jQuery UI we want to be able to write examples for individual options, something that shouldn't be done in demos (current state).

For some reason <code> elements in events have different styling than other <code> elements.

The documentation for the appenTo option of selectable is missing.

From: http://bugs.jqueryui.com/ticket/6688

Currently:

The Autocomplete plugin does not filter the results, instead the request parameter term gets added to the URL, which the server-side script should use for filtering the results.

I was expecting this behavior:

source: "http://myurl.com/json/";

After term is added:

source: "http://myurl.com/json/term";

But what actually happens is:

source: "http://myurl.com/json/?term=term";

There wasn't any indication it would definitely be adding it in the URI as a PHP GET request. I use clean URI's and initially it seemed to work perfectly for that. Had to troubleshoot, and didn't realize this was the problem for a little while.

Maybe change it to:

The Autocomplete plugin does not filter the results, instead the request parameter term gets added to the URL (as '?term=term'), which the server-side script should use for filtering the results.

Thanks!

Most interaction docs currently list their event properties in the <longdesc> element, that should be moved into each <event>. There's some related information like the stuff in draggable recommending something like $(this).data('draggable').offset.click.top -= x - need to review that.

There is logic in the XSL file to generate a placeholder for a live demo for each example. However, the code to make the demos work doesn't exist. Presumably this is supposed to run off of the same code that the existing jQuery API site uses.

XSL: https://github.com/jquery/api.jqueryui.com/blob/master/entries2html.xsl#L257
current script: http://static.jquery.com/api/demo.js?v=20110228

Bad description of Accordion.beforeActivate event. It says "Triggered directly AFTER a panel is activated" and it must be "Triggered directly BEFORE a panel is activated".

Fran

Widgets have <created> elements in the XML, but they're not used in the output.

Widget methods should support <signature> elements just like normal methods. This is important for methods such as option.

.scrollParent() needs a description and perhaps an example.

"botom" should be "bottom".

String: A string representing the position within the viewport. Possible values: "center", "left", "right", "top", "botom".

should be

String: A string representing the position within the viewport. Possible values: "center", "left", "right", "top", "bottom".

From http://bugs.jqueryui.com/ticket/8727

For some reason jQuery/$ is undefined in the demo frames.

Mention where its useful, like in the case of an autocomplete inside a fixed element.

It'd be nice if users could select easings to compare and have them animate side by side. Probably the best animation would be an element moving from the left side of the screen to the right side at a somewhat slow speed. The selected easings would all animate at the same time, stacked on top of each other like a race track. Linear should always be included for reference. There should be enough room on the left and right edge to properly show animations that overshoot the boundaries.

To start, move most of Menu's method into a separate section labelled "Internals" or "Extending". Keep only refresh and widget-inherited methods in the regular "Methods" section.

Implementation wise, probably just keep <methods> (or create around method elements if it doesn't yet exist, and add another element for the other methods, reusing the same template for both.

autocomplete

• _resizeMenu()
• _renderMenu()
• _renderItem()

dialog

• _allowInteraction()

menu

• _closeOnDocumentClick()

spinner

• _uiSpinnerHtml()
• _buttonHtml()

Th quicknav should have a link to the examples and more information section.

We don't yet have a proper index page. Will merge the work that currently goes into the api.jquery.com repo for that.

Entries already exist, they need descriptions and examples.

Docs for Widget are incomplete. The "spec" is also incomplete, we should finish that first: http://wiki.jqueryui.com/w/page/54092424/Widget

Dialog API lists "show" twice -- one should be "hide"

http://api.jqueryui.com/dialog/#option-show

Current effect docs are just an import of the old incomplete stuff. Figure out what's missing and add that.

See http://stage.api.jqueryui.com/widget/#option-hide

Shouldn't mention tooltip and either not include examples or have actual code in them.

This stackoverflow answer is pretty good: http://stackoverflow.com/questions/2382497/jquery-autocomplete-plug-in-search-configuration

We should cover that in our docs. Extend source docs to include the example given in the answer, and list escapeRegex.

Currently adding an icons demo, use that as a reference.

I can't put my finger on it, but it looks "wrong". It doesn't fit in very well with the rest of the theme.

^{(Also reminds me of those FrontPage wizard menus, remember those?)}

Tabs and tooltip had a few <example> elements that weren't handled correctly. As part of addressing #24 for the main demos, I commented those elements. We need to figure out what want to show there: Just an example line of code, or an actual demo?

Currently states "When the Deferred is resolved or rejected, progress callbacks will no longer be called," with no mention that progress callbacks are executed immediately when added to a resolved/rejected Deferred that has ever been notified, with the last notification's arguments.

Take language from here as template: http://dev.api.jquery.com/deferred.reject/

http://api.jqueryui.com/tooltip/#option-position

The default value for position changed: jquery/jquery-ui@7af1ec7

It would seem all the CSS class documentation has disappeared with the new site.

ie.
http://web.archive.org/web/20110524050102/http://jqueryui.com/docs/Theming/API

from jquery/jqueryui.com#18