Some things not prominent on your list, and maybe shouldn't be, but that I thought of in addition to what you wrote...

1. UI Polish... clean-up all the small things, from imprecise or inconsistent user interface experiences or theming issues, to things that don't work as expected like dealing with scroll bars and positioning bugs that seem to popup from time to time. Another example is how validation warning messages are displayed.
2. Additional high-quality themes (perhaps not in Dijit per se)
3. Editor refactor (it needs to get done)
4. More Tree features and bug fixing in general
5. More data integration (not all widgets are dojo.data aware, but are all of them that should be?)
6. Making it easier for people to understand how to use all of the difference ways of providing data for dojo.data aware widgets
7. Forms and form validation are still too hard compared with just rolling your own
8. Support for html 5's data-* attributes in markup?

If we're going to do the grid move, we should consider how grid extensions might work for things like tree-grids, spreadsheet like capabilities, etc.

What I can come up with so far, maybe not al 1.3 relevant

1. Dijit layout cleanup, AccordionContainer should just have any other layout containers or panes as children and use the same api as tabcontainer.Expando api should be discussed

2. Form control. Better way of defining validation for time/date spans

3. General CSS optimisation - CSS is bloated in some parts and needs optimisation

4. CSS documentation, theme documentation

Another thing that we've talked about before is moving DropDownSelect into dijit as well.

I'd also like to get a _FormSelectWidget (similar to _FormValueWidget) worked out fully (one sort of exists in dojox.form) and moved to dijit for all the "select-like" form widgets.

A "repeater" form widget would be nice too.

Thanks for the post bill, always good to plan ahead.

In no particular order, my list of items I'd like to see (some of which I might have mentioned in the 1.1 list you reference):

1. Expanded form widget validation - I would like to be able to say that a dijit.TextArea, dijit.Editor are required (form validation fails with empty content) - I guess I'd like to see a required=true param on any form control. I've been using dojo 1.1.1 for form validation instead of plugging in another 3rd party js lib like tmt:validator and I'm able to do about 60% of what I want to out of the box with dojo. See trac #6388

2. Date + Time combo widget (has this been done? I seem to remember something from the forums....)

3. Date widget - having an optional dropdown for the year so you can go back quickly to choose things like birthdays (ala jscalendar's but I think dojo could make it even better: http://www.dynarch.com/projects/calendar/) - I know that you can hold the mouse on the year in dojo's widget to go back without continuous clicking, but I don't think any of my users have figured out that they can do this.

4. Can some/all of dojox.image move into dijit? (Lightbox/Gallery/etc?)

5. Dialogs - I haven't really had a chance to look at what's new with 1.2 Dialogs (dojox.Dialog) but I really struggle sometimes with sizing dialogs. I would love to be able to say something like "Size this dialog to its content size, UNLESS it's going to cover more than 90% of either the width/height of the viewport, at which point scroll the content". A lot of times I have Dialogs where the content is dynamic so I don't know if the thing is going to take up all the viewport space or go beyond it where it cannot be closed anymore. But I don't want to absolute size it and have a bunch of blank space if the content winds up being smaller than the size I give. I'm such a needy little putz I guess. :)

6. Something to be done about the executeScripts issue? I don't like having to create copies of dijit.TitlePane, dijit.Dialog, etc to derive from dojox.layout.ContentPane so I can execute scripts again. It's not a huge deal, but it's a very common FAQ on IRC.

7. Editor updates that didn't make 1.2. :( Syntax highlighting (ala editarea) would be excellent.

8. A captcha / image validation form widget.

9. #5344 - DnD from Tree (or other widget) onto a TextArea

10. Can Textboxes automatically convert the size= param to style="width: xyz" (assuming that style hasn't also been set) so it's easier to migrate standard HTML inputs to dijits?

Thanks!

Josh

1. Move Grid to Dijit

As a new user of Dojo, this seemed logical to me in the first place and is where I first started looking for it; trying to use DojoML against it. It's a heavily used widget-type in any environment/toolkit just about and I'm glad it's getting focus.

I am working on forms at my day work :-) so I will definitely have something to share + I'll have some input on existing form widgets.

If I have time before 1.3 ships, I plan to tinker with Tree a bit to make sure that the DnD is in line with the generic DnD. Specifically I will look into seamless DnD between the Tree widget, list-based containers, and text containers (like TextArea).

We've just started serious usage of the Tree widget to replace our home grown clunky Tree. A couple of the extra things that would be nice in the base widget are:
1. Double click on a node to perform in place editing. We got the code to extend the base tree from the the forums which works well but I think it would be nice not to have to extend. In it's simplest form this could be the InlineEditBox but ideally could be any user specified control. For example some nodes depending on their type perform a simple toggle action on double clicking, some display the InlineEditBox while others require a small dialog to set the properties.
2. Select multiple nodes. I have seen some transcript documentation floating around that shows you have already considered this and at one point it was scheduled for 1.2. It would be nice to see this make it in.
3. Checkboxes for each node. Again we have extended as per the forums but it would be nice to have it as standard functionality.
4. Tooltip for a node that could display some additional attributes from the store.

Other than that:
1. Editor enhancements - yes, yes, yes. Although for us this is a bit of a pain as users want to report on the contents and working out how to convert formatting is not easy (but that's not your problem)
2. Online doco still needs some work but I guess you already know that. For Example: The tree doco lacks some very basic instruction on how to programattically add/remove a node without having to go searching through the test code or forums (OK I eventually found it in the Write API doc but maybe it should be in a separate "How to..." section for the tree with a working example/demo). This may overlap with the data store doco buts it's fairly fundamental to using a tree. Even something like opening a tree at a specific node (as per last selection) is I would think a common requirement as is returning the full path from the parent to the selected node. Each of these things are simple little pieces of code but every new user has to go searching around to find out how to do it.

Waiting eagerly for 1.2 release for grid changes.

One more thing

1. Support for more tabs than fitting into the tab container (currently they just wrap). This is already been worked on atm.

Dialog
---------

It will be nice to have these additional attributes for the dialog:

1. resizable: true/false (like in the 0.4 Floating Pane).

2. modal : true/false (false: non modal dialog).

----------
3. external: true/false together with url:http://mysite.com/dialog1.html

A dialog to be read at real time from an external html file.

dialog.show() . Will read the file from the given URL and add it automatically to the DOM.Should be synchronous so after the calling the widget is already in DOM.
dialog.destroy(). Will delete it from the DOM.
dialog.hide(). As usual

Even if a dialog can be dynamically created and destroyed programmatically, it is much easier to create it as HTML.

May be, this, can also be generalized for other container widgets (like bordercontainer), it will be of great help in dialogs diminishing memory consumption, specially for complex dialogs (containing grids and additional widgets).

thanks

Gant Chart like MS Project.

Including the following:

1. Successor/Predecessors lines and arrows.(end to start, start to start, end to end, etc)
2. Placing symbols (circle, rectangles, rhombus) at the beginning/ending of each bars.
3. Fill Area pattern/color for bars.
4. headings, titles, axis, etc customizations.

Yes .. Huge work

here's some things i wish for...

1/ DateTimeTextBox.

2/ Tree enhancements.
a) Make it easier to to add per node context menus and icons.
b) Support large data sets by batch fetching child nodes. Similar to grid virtual scrolling.

3/ TreeGrid.

4/ gfx enhancements to draw lines that connect boxes, similar to yahoo pipes.

5/ dojo data api enhancement to support metadata that can be used by a grid to auto render store data.

I'd like to make some votes for tree additions already mentioned above:

- Support dropping between two tree nodes, rather than just dropping onto a node.
- Make it easier to to add per node context menus and icons.
- seamless DnD between the Tree widget, list-based containers, and text containers (like TextArea)

Those are feature/areas I'm currently struggeling or are missing.

Quick one: Ability to define a 'Default' item inside an ItemFileReadStore such that form elements using them can default to something rather than figuring this out manually?

Documentation. I know its quite boring, but its a must have for any serious framework.

I'm a PHP/AJAX developer and started using Dojo a cople of month ago, since Zend (Zend Framework being my favourite PHP framework) announced their partnership with dojo. Previously I worked with a lot of other JS-frameworks, but I must say that Dojo now is my framework of choice! :) There really is just one bad thing about it... Documentation. Where is it? I've read two books on dojo, and they have helped me a lot. But online documentation should be a priority. The popularity of the dojo-toolkit is imho in the hands of good documentation.

If the documentation isn't there:
You will struggle to get wider adoption.
You will struggle to spread the word on all the amazing features of this extensive toolkit
You will have a lot of people thinkin that dojo can't do what the other frameworks can (Though it propably can, and a lot better to ;)

(The above statements are partly built upon my experience from the ZF-maillists)

You should learn from PHP, and Zend Framework as I think that a lot of their success is due to excellent documentation!
I mean, how about this, this is what I call documentation: http://framework.zend.com/manual/en/

In my opinion, a feature that is not documented should not be a part of the toolkit.

I hope documentation will be a priority in the feature. Maby for the 1.3 release? :)

Thanks for an otherwise excellent framework!

We based several screens on the tree widget in dojo-before-0.9 using checkboxes. Even if there are instructions on how to do it in the forums, it should be officially supported in the product, so we can implement the feature with less fear that an update will break our applications.

1. Forms and form validation are still too hard compared with just rolling your own
2. Another thing that we've talked about before is moving DropDownSelect into dijit as well.
3. General CSS optimisation - CSS is bloated in some parts and needs optimisation
4. CSS documentation, theme documentation
5. Dialog : Permit to hide the "X" close button and disable the keytiping to make the Dialog really modal unless an event occurs (like a Xhr response...)