@Alex
Good to see that the Dojo people have at least thought about the semantics. Now, if the browser vendors would add solid support for XML namespaces in XHTML documents, then Dojo could keep its information cleanly separated from the HTML, and there would be some order. But until then (if it ever even comes that far), I would personally always choose the Behaviour-approach.

Dojo provides a behavior library as part of Core, and you can easily use that to describe how you’d like your nodes to be upgraded, thereby moving all of this logic out of the markup if that’s how you roll. It’s orthoginal to this parser system, and you can use the behavior system to get what you want without ever touching widgets.

That said, markup turns out to be tremendously useful in terms of noting the intended structure. In this case, we’re decorating markup with what we *mean*, which is about as semantic as it gets. It also degrades well and scopes the configuration to the instance. Moving that configuration elsewhere seems to have limited value unless multiple instances could/should share those changes. We’ve considered multiple types of “property” or configuration cascades for instances based on rules, but their application looks to be expensive. They also tend to mirror the prototype chain’s cascade…if you want to change defaults globally, just modify the class prototype. No need for extra syntax.

I am leaning toward a default “mix in values from these objects” property on instances…should be fast enough and space efficient to implement. Thoughts on what that should be called?

Regards