I really think this should be moved higher in priority.
In real word usage the grid component is central (for instance I can't imagine a simple CRUD application without a grid component.

The grid is surely a plugin in high demand. And key for creating a lot of applications, as you mention. One reason it's not higher in priority is not because we don't think it's valuable or important, but because it's complex and we want to do it right. Doing so means depending on some lower-level plugins/utilities that aren't started/finished yet. We'll get there. And in fact, some work is already being done on it in http://jquery-ui.googlecode.com/svn/branches/dev/grid/. The priority we have set should not discourage anyone from doing any work on any plugin. Just a way to answer the questions, "Where is the team focusing the most efforts right now?" "What is most likely to be finished next?" and "Why are you all working on X before/instead of Y?"

Something else that might be considered is the plugin/widget and parser abilities of tablesorter. http://tablesorter.com. It's a fantastic plugin and allows for some great extensibility. It's flexibility for late-bound sorting and initialization has been key for our uses. (ie. having a serverside script generate a table, and then applying the plugin to the table).

May be we should consider 'content grouping/panel' plugin as another basic component of 'grid/table', since the later, as it seen from the pictures, also has a title bar with custom controls and collapsible content.

I would say that a jquery ui grid should NOT contain features to draw a footer or header. I think the requirements as stated above should also not include the ability to create toolbars and associated menus, nor should it include pagination. Also the grid should not support remote sorting, filtering and pagination. A grid should also not have any logic about how to transform HTML, XML, JSON data, or whatever else.

All these things should be separate from the grid. The grid widget should concentrate on being a grid and only a grid.

I would therefor give +1 vote to slickgrid, because imo that plugin nails it. It's rendering engine is simply awesome.

@lawrence, whether the logic for those features is implemented inside the grid or in other plugins that the grid takes advantage of, these options totally make sense for a grid. These are all very real and very common use cases for a grid, so to say that none of those details belong in the design for a grid is a bit far-reaching.

I agree with Scott G. We need to have the grid do more than just client side sorting or it really isn't a grid, it's a table sorter. Where to draw the line is exactly what this conversation is all about. The grid may have a header and multiple toolbars snap in, but we'll have to figure out how baked in these are or if they are just tested to work in conjunction with a grid.

I think the grid needs to handle the internal scrollbar for the table body (it's very hard to do), maybe draggable column widths and a way to hide/show columns, row striping, maybe tree style first column (like MS Project) to hide/show rows, maybe a sub-row spindown for extra info, client-side search and/or filtering. Basically, taking a regular table and manipulating it's display.

From there, having mechanisms for fetching in a variety of data sources via AJAX for handling larger data sets would allow for pagination, searching, filtering tables that would have too many rows to display as a single html table. Even in these cases, we should engineer this to start with a populated table as much as possible. I hate AJAX apps that serve up an empty div where content will be sent in over the wire, it's terrible for mobile, SEO, and accessibility.

@Todd: it seems to me you're assuming a technical solution using tables, which then makes handling the scrollbar very hard indeed. It makes the whole thing dog slow, and therefor you must resort to pagination, etc.

Instead, if you apply incremental or virtual rendering techniques using absolute positioned divs and only show within the viewport those items that need be shown suddenly you can easily handle hundreds of thousands of rows on the client and scroll to the bottom within a few milliseconds. This technique is used by for example Sproutcore and SlickGrid.

Next to all those visual and functional requirements that are mentioned I would root for putting a performance requirement at the top of the priority list.

I would argue that a grid is only the container that contains the scrollbar(s). That's what the grid widget should excel at. Nothing more, nothing less.

All the rest surrounding the grid area are different plugins cq ui widgets imo. Integrating those directly into the grid would just be a distraction.

I think it's unnecessary if the grid had logic about how to fetch data in a variety of ways. That is not the concern of a grid. Instead a grid should expose an easy API that allows manipulation of the data (that for example a pagination plugin could take advantage of).

Separation of concerns would promote innovation imo. Instead of trying to squeeze everything into the grid, just focus on being a grid and promote several other projects that focus on for example being a filtering plugin, a data extraction plugin, a paginator, etc.

Another advantage of separating things out is that you can release a fully functional grid much earlier because you don't need to worry about unpolished pagination, filtering, data retrieval, etc. etc. features. Discussions about all the features for example a filtering plugin should have could take place somewhere else. Let's here focus on the grid only.

@lawrence I like the idea of having the grid be primarily focused on the the core grid interaction with an open and modular API so it can be easily extended. The performance of slickgrid is really impressive too.

My primary concern is that it should be an option to grid-ify a nice, well-structured table for accessibility, SEO and ease of implementation purposes. If you look at the slickgrid examples, it's just a bunch of scripts and an empty div and completely breaks w/o JS. Since we're trying to embrace accessibility and progressive enhancement, starting with a table should be an option. If that was part of the approach, there is a lot of merit in how slickgrid works. Maybe when you talk about a data extractor plugin, you're referring to the idea that this could rip the data from a table and pass it into the grid.

@Todd A fair concern you raise. I've submitted an HTML file to the slickgrid project which shows an example of progressive enhancement. I didn't change anything within the slickgrid code itself.

It basically does, in an extremely simplified way, what indeed I was referring to as a data extractor plugin: it basically rips the data from the table>tbody>tr's, passes it into the grid, hides the table and shows the grid.

@lawrence That's cool that you could in theory start with a table with slickgrid. Do you know how accessible the slickgrid is on a screenreader? I just tried the basic slickgrid example on JAWS and Firevox (a screen reader add in) and the big issue I see with using divs is that they lose any semantic meaning that a screenreader would be need to be useful -- you just hear the value, not it's scope or meaning. I also can't seem to get the keyboard navigation shortcuts to work right in the example.
http://slickgrid.googlecode.com/svn/trunk/example1-simple.html

Maybe there is a way to use ARIA attributes to add back in the descriptive bits to make this div-based approach work on a screenreader, but I'm wary of this approach overall. I'm torn because I really like the performance of the virtual grid approach but think the jQuery UI solution needs to be accessible, both w/o scripts and in the enhanced grid version. For tabular data, I think properly coded tables may be the only way to provide the necessary semantics for screen readers (and SEO and mobile devices...). My personal opinion is that using tons of positioned divs is just not a good technical approach for presenting tabular data, even if it is performant, because the content is tripped of any semantic meaning so it only makes sense visually. For tables with 10,000 rows, maybe you could take the "only render what is in the viewport" approach but use a series of stacked tables instead of divs. It's still a bit semantically broken because they are separate tables, but at least we could provide the necessary context and semantics.

Are there some a11y folks who can weigh in on this? I'm far from an expert, just a concerned party.

BTW - Here are a few guidelines for making tabular data accessible that we really should try to respect when building the grid (grabbed from http://jimthatcher.com/webcourse9.htm):
* Use caption element as a title for the data table and and/or use the summary attribute to give a brief overview of the structure of the table.
* And markup all table header cells
o Use the table header element, th, for all header cells and add the scope attribute when that scope is ambiguous (corners).
o Or use td together with the scope to specify header cells
o Or use id attributes on the header cells and the headers attribute on the data cells to explicitly associate header information with data cells. This is essential if there are data cells whose header information is not in the same row and the same column as that cell.

Two ago a very interesting article was posted on smashingmagazine going precisely into the details of the difference between table based and div based data: http://www.smashingmagazine.com/2009/04/08/from-table-hell-to-div-hell/.

This example is great: http://www.dhtmlx.com/docs/products/dhtmlxGrid/. I'm in love with the search boxes. And the advanced example of frozen columns is awesome.

I added this to section 1, but wanted to ask here as a question: should we use the HTML 5 spec for menus as a blueprint for our grid (at least where applicable):
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#datagrid

We have been working on Grid centric application development for last 4 years+, here are our set of requirements

support for %column width
support for % grid width
Column text should word-wrap if column width is smaller/ or you show complete text in tool-tip
Pagination Support
Filtering Support
Custom Column Rendering
Column Re-size
Keyboard/Mouse Navigation
Text Selection and copy Support
Out of Box good look and feel
Internationalization support
[NICE] column selection / re-arrangement
[NICE] Right Click Menu

We need a default demo with a local datasource for viewing it from SVN, without having to have a PHP backend. I'll look into that.

The last version of jqGrid (3.5) integrates jQuery UI natively and is a very powerful grid jQuery plugin
blog: http://www.trirand.com/blog
demos: http://www.trirand.com/jqgrid35/jqgrid.html
Thanks

It would be good if we can have data filtering as in Microsoft Excel.

Sample screen shot: http://img199.imageshack.us/i/excelfiltering.png/. Filter by color may not be required.

Thanks.

Please note that Datatables plugin now supports skinning with jQueru UI themes:
http://www.datatables.net/styling/themes/flick