(pasted from Alex's mail)

Sorry for the delay in my reply. I've been discussing and cogitating 
about what steps to take, and here's what's currently on my short list 
(many of which are ideas that others have proposed to me, so I can't 
take the credit for them):

CODE:
-----

	* simplify the widget construction syntax
		- remove the <dojo:whatever ...> style in HTML environments
		- remove the <div dojoType="..."> style in HTML environments
		- enhance the <div class="dojo-Whatever"> style to support parameter 
passing based on node ID and/or type
		- build a faster parser pass based on "behavior: expression()" syntax 
on IE and XSLT on FireFox. Combined with constrained construction (** see below)
semantics, it should yeild a significant performance win for page init.
	* unified L&F
		- default style sheet
			* must make default font, color, and spacing choices
				- setting the baseline is a feature, not a bug
			* provide single place to over-ride L&F "constants"
		- neutral colors (as per Torrey's suggestion)
		- completed keystroke and a11y hinting
			* policy of no new non-experimental widgets without a11y and L&F 
signoff (Becky and Torrey)
	* decouple the IxD project from 1.0
		- give the IxD project a direction, support, and the ability to carve 
out a new namespace, but make their development orthoginal so that they 
can ship independently of our release schedule
	* build theme and data binding infrastructure for 1.0
	* enhance the template syntax to support data binding (iteration, 
enumeration, repaint events, etc.)
	* testing
		- selenium
		- no new features without tests
		- "week of tests" in 0.5 timeframe where the only checkins to trunk 
will be tests

NON-CODE:
---------	

	* change download link to land users at a "background download" page 
which provides the immediate "getting started" info as well as links to 
other places to look for help
	* enhance the doc generation system to support formatting. We 
have "docs", but they're not useable right now since adding any 
non-trivial amount of information ensures that it gets lost in the 
resulting UI.
	* ensure that Andrew has the support he needs to get the website done 
and get it released
		- task-lists for work breakdown
		- coherent themeing of wiki, blog, and forums
	* policy enforcement for Feature Buddy system
		- checkin notices must either reference a bug ticket or a Feature 
Buddy (enhancement ticket ref or no ref) or checkin to trunk will be 
denied by the system
		- notification to buddies that checkins with their "signoff" have been 
made (trust, but verify)



There's more, but it's escaping me at 4:30 in the morning. I'll try to 
have a more coherent list when I return from Christmas.


-------

Faster Parser

Here's a straw-man API for registering a set of default 
properties of a widget type on a given page, based on the behavior API:

	// not sure if this should live under dojo.widget.*
	dojo.widget.add({
		"dojo:ComboBox": {
			width: "30px",
			complexProperty: {
				thinger: "value",
				blah: "value2"
			}
		},

		// individual widget configuration based on node ID
		"#id4": {
			dojoType: "dojo:ComboBox",
			// widget properties here
			...
		},

		...
	});

Of course, we still need inline configuration. Here's how:

	<div class="dojo-ComboBox"
		style="border:1px solid black; dojo-PropertyName: value; 
dojo-PropertyName2: value2; ...">
		...
	</div>

In this case, we would obey a cascade much the way CSS behaves today and 
if users specify all of their properties in the parser-advice block, we 
can avoid string casting and significant amounts of iteration.

Obviously, this syntax is HTML-specific, but as we've been finding out, 
being "agnostic" about rendering environment has real costs and parts 
of the world we planed for once-upon-a-time never materialized. Other 
parts did. Time to do minor course corrections to meet reality where it 
is.

Anyway, to clarify, here's why I'm favoring this approach:

	1.) we can implement it with behavior hacks until MSIE pulls it's head 
out of its ass or becomes irrelevant
	2.) XPath over the HTML DOM is a superset of the "query by CSS" things 
that some scripters are agitating for (why on earth they'd want 
castrated query syntax is beyond me, though). If the browser 
manufacturers do the wrong thing and implement "query by CSS", we still 
have a fast path.
	3.) it makes the CSS kiddies happy

I think the confluence of marketing, tech, and future-proofing makes 
this a pretty solid direction. Now we just need to determine in what 
timeframe to implement it.