ibm-js / delite

HTML Custom Element / Widget infrastructure

delite

This project provides a custom elements based UI Widget framework working both on desktop and mobile platforms.

Status

No official release yet.

Migration

For developers migrating a widget from dijit, migration will require manual steps listed here.

Issues

Bugs and open issues are tracked in the github issues tracker.

Licensing

This project is distributed by the Dojo Foundation and licensed under the "New" BSD License except the Bootstrap variables.less file which is distributed under MIT license.

All contributions require a Dojo Foundation CLA.

Installation

Npm release installation:

$  npm install delite

Manual master installation:

$ git clone git://github.com/ibm-js/delite.git
$ cd delite
$ npm install

Testing

$ npx intern

Documentation

See the introductory blog post to get started.

Then see the delite website including the documentation section.

delite's Issues

support native properties

Currently you can't setup a custom setter or watch() a property like tabIndex, even if tabIndex is defined in the widget itself, trying to override the one in the HTMLElement base class.

On Chrome, the custom setter will never be called because the DOMNode object itself, produced by document.createElement(), will have it's own tabIndex property that overrides the one on our prototype.

On IE and FF we hit an issue that dcl will eventually work around.

I'm actually not sure if we can support native properties or not. What I want is for mySlider.tabIndex="3" to set the tab index of the slider's handles, but to leave the root node without a tabindex setting. But DOMNodes have a magic mapping between properties and attributes, so perhaps it isn't possible.

If worse comes to worse we'll have to use a different name, like widgetTabIndex.

remove destroyRecursive()

destroy() should destroy recursively

rename tags to d-*

per decision in #16

delite/Store does not handle the case where an object from an observable store is moved (for stores that supports the before option for the put method)

When used with an observable store, the delite/Store mixin react to the following events:

• Item added to the store (addItem method is called)
• Item removed from the store (removeItem method is called)
• Attributes of an item updated (putItem method is called).

It does not handle the case where an item is moved (for example after a store.put(existingItem, {before: anotherItem}).

Intern tests not running when launched using intern\runner.js

Intern tests are not running when launched using intern\runner.js.

The reason is that:

1. dui\widgetTests\intern\local.js is not referencing unit and functional tests correctly (it references dui\tests instead of dui\widgetTests

2. widgetTests\boilerplate.js and widgetTests\boilerplateOnload.js are missing.

support for empty-element tags?

It seems the parser doesn't support empty element tags like:
<d-a-widget widgetattr="attrvalue"/>

Stateful._set() should call Observable.getNotifier(widget).notify(changeRecord)

On platforms that support Object.observe(), or when Polymer is loaded, then it's necessary for _set() to call Observable.getNotifier(widget).notify(changeRecord) in order for Object.observe() to work correctly.

templates: array binding

Support looping in templates, for example:

<ul>
   {{#each employee}}
        <li>{{lname}}, {{fname}}</li>
   {{/each}}
</ul>

(The syntax could also be MDV, rather than handlebars; doesn't matter too much.)

Supporting arrays requires infrastructure support for something like ArrayObserver, rather than current simple watch() command. Or, do the poor man's solution: require a manual call to refreshRendering(), and make it just re-render everything.

An open question is whether the widget needs to declare the array property as a StatefulArray and access it through the allowed methods (push, pop, etc.), or whether we should somehow support native array properties that can be adjusted through subscripts (ex: this.ary[5] = ...)

Delite UI will ultimately fail, before the release date

rubbish

CSSState test failure

IE11 fails the CSSState.js test while trying to create a widget that defines the disabled property.

Happens even though the widget extends HTMLElement rather than HTMLInputElement. IIRC on IE, all DOM elements have a disabled property, not just form element.

I'm not sure why the CSSState test is failing while Slider works... or perhaps Slider is failing on IE11 too.

cc @doughays-dojo

Slider: leverage refreshRendering()

Slider should be updated to extend Invalidated and use refreshRendering().

Currently Slider is using buildRendering and startup for initial rendering (BTW startup() has code for removing the extra handle that will presumably never run.) It's refreshing properties in handleOnChange and refreshing the widget in a custom _refreshState method.

We want to standardize on instead using refreshProperties() and refreshRendering() from Invalidating.

buildRendering() can still be used for creating the DOMNodes that will exist regardless of widget property values, and then refreshRendering() doesn't need to worry about creating them. It might make sense to have <dui-slider> and <dui-range-slider> as separate widgets so that buildRendering() can build the handles. (Building them in startup() is non-standard.)

cc @pruzand @cjolif @AdrianVasiliu @dmandrioli

Remove underscores from module names.

Use documentation rather than _ naming in module names.

dui package renaming

The package name dui has been raised as a concern in US, as it is commonly known for "Driving Under the Influence", so it's recommended to come up with a simpler name. We also need to determine what the name will be for the package containing concrete web component implementations when it is separated from the core UI framework package.

Some initial proposals for the framework package to seed the discussion (in no particular order):

ui - Short for UI Framework
uif - Short for UI Framework
uifw - Short for UI Framework
d2ui - Short for Dojo2 UI Framework
uicore - Shore for UI Core Framework
wc - Short for Web Component Framework
wcf - Short for Web Component Framework
wcfw - Short for Web Component Framework

Some initial proposals for the web components package to seed the discussion:

wc - Short for Web Components
wce - Short for Web Component Elements
wcelements - Short for Web Component Elements
uielements - Short for UI Elements

Opinions?

jquery

I think we've agreed to build on jquery or zepto, with "or" meaning that the app can choose which one they want.

This task is to setup that infrastructure, and then also probably add a $() method to Widget, so widget code can do things like:

this.$(".duiHandle").attr("tabIndex", this.tabIndex);

A subtle point of the example is that the query is automatically rooted to this, rather than to <body>.

PS: The jQuery 2.0 release notes mention that:

The final 2.0.0 file is 12 percent smaller than the 1.9.1 file, thanks to the elimination of patches that were only needed for IE 6, 7, and 8. We had hoped to remove even more code and increase performance, but older Android/WebKit 2.x browsers are now the weakest link.

I guess that means that zepto is 10K and jQuery is 30K. Not sure if that's from the Android support or something else, but I know we aren't supporting Android 2.0.

StoreMap inheritance bug

StoreMap overloads mappedKeys to be both a user
defined value and a value computed in _introspect().

This presumably leads to problems if someone extends a subclass of StoreMap:

var A = register("my-widget", [... StoreMap], ...);    --> computes mappedKeys from introspection
var B = register("my-widget", A, ...);    --> just uses A.mappedKeys

Instead, you should probably make separate variables, for example this._computedMappedKeys.

I started to do this but noticed some other issues too. In itemToRenderId it does:

var mappedKeys = this.mappedKeys?this.mappedKeys:Object.keys(item);

AFAICT mappedKeys is never falsy. At the least, it will be set to [].

CSS files are not necessarily themes related, to be more agnostic rename "themes" into "css"

In the CSS directory we would have both the themes under the various ios, android etc... directories and some regular CSS that can be put in there and not linked to a particular theme.

client.js tests broken after directory re-org

e.g. running something like http://localhost/dui/myproject/node_modules/intern/client.html?config=dui/tests/client
I get 404's (as infrastructure dir removed).
Also, path dependencies have changed (baseUrl and test handlebar template location)

StoreMap.mapAtInit == false inefficient

When StoreMap.mapAtInit is set to false, StoreMap.itemToRenderItem() creates custom setters for every property every time it's called, and it's possibly called for every data store item. Wouldn't it be better to create the custom setters in a prototype and reuse them?

In _introspect() you could create a new _renderItemCtor class and then itemToRenderItem() becomes:

itemToRenderItem: function(item){
    return new this._renderItemCtor(item);
}

The _renderItemCtor class would look something like this, basically using the code currently in itemToRenderItem:

var self = this;
this._renderItemCtor = function(item){
    if(!self.mapAtInit){
        Object.defineProperty(this, "__item", {
            value: lang.clone(item),
            enumerable: false
        });
    }

    // special id case
    this.id = store.getIdentity(item);
    // general mapping case
    for(var i = 0; i < mappedKeys.length; i++){
        if(self.mapAtInit){
            this[mappedKeys[i]] = getvalue(this, item, mappedKeys[i], store);
        }
    }
    if(self.copyAllItemProps){
        for(var key in item){
            if(self._itemKeys.indexOf(key) == -1){
                this[key] = item[key];
            }
        }
    }
};

if(!this.mapAtInit){
    for(var i = 0; i < mappedKeys.length; i++){
        (function(key){
            Object.defineProperty(this._renderItemCtor.prototype, key, {
                get: function(){ return getvalue(self, this.__item, key, store); },
                set: function(value){ setvalue(self, this.__item, key, store, value); }
            });
        })(mappedKeys[i]);
    }
}

Having said all that, I don't see any tests for itemToRenderItem() and I'm not sure why you even want it; it seems like it returns something quite similar to the main class itself.

parser: support auto loading?

The parser doesn't do auto-loading anymore, mainly because:

• its asynchronous nature breaks the API of document.createElement("d-tree") and our sister function register.createElement("d-tree")
• auto loading doesn't match the web components spec
• it's more complicated than before since there's not an obvious mapping between tag name (ex: <d-tree>) and the widget (ex: dui/Tree or dtree/Tree or ...)

But we could support it by have each package provide something like an AdapterRegistry that would map a given name like d-tree to a widget definition if that package provides the widget, or return undefined otherwise.

At a minimum though the app would need to register each package w/the parser, which somewhat defeats the goal of being automatic.

A related issue is auto-loading of widgets declared in templates. That again though breaks document.createElement("d-tree") since it's supposed to be synchronous

can't specify baseClass as initialization parameter

css baseClass is added to the widget node in the buildRendering method, which means that if a custom baseClass is set for the widget, the default one has been already applied to the node before one get a chance to apply the custom one. As the value of the default one cannot be retrieved from within the widget code, it cannot be removed to apply the custom one instead.

Some StarRating tests uses star images that are not compatible with RTL mode

See dui/tests/test_StarRating.html?dir=rtl:

Tested on Chrome/mac.

Use dstore instead of dojo/store in Store*.js

Multiple selection modifier in Selection.js is colliding with context menu on a Mac

from @damiengarbarino

On a Mac, as mouse may have only one button, the control key + mouse click is showing the context menu.
As a matter of fact, it triggers the "oncontextmenu" event on a DOM element (on Safari at least).
In dojox.widgets.Selection, if the selectionMode is set to "multiple", the selectFromEvent function is using the MouseEvent.ctrlKey modifier to allow multiple selection. Unfortunately this MouseEvent.ctrlKey is the control key as well on a Mac (and not the command as one could have expected).
So a solution should be found for this particular use case.
It could be using a different modifier (only for Mac or not), using the command key instead (but it's not a modifier, see ​http://unixpapa.com/js/key.html)

fix StarRating tests

The StarRating tests in tests/bidi/, tests/doh/ and also in tests/ itself need to be updated to remove use of obsolete methods and modules:

• dojo/ready - use dojo/domReady!
• dojo/parser - use register.parse()
• dui/mobile/compat
• dui/registry - use dom.byId()

They also need to be changed to web components syntax for markup, and stop using the new MyWidget(props, srcNodeRef) syntax for programmatic creation; only new MyWidget(props) is supported.

StarRating tests fail

When running locally against Firefox/mac I get:

mac:ws bill$ node /ws/dui/node_modules/intern/runner.js config=dui/tests/intern/default-conf
Defaulting to "runner" reporter
Listening on 0.0.0.0:9000
# Registering StarRating tests
Initialised firefox 25.0.1 on MAC
# running test 'read only ltr'
# running test 'editable ltr'
Test main - StarRating tests - editable ltr FAILED on firefox 25.0.1 on MAC:
Error: expected 0 to equal '4'
expected 0 to equal '4'
# running test 'editable half values ltr'
Test main - StarRating tests - editable half values ltr FAILED on firefox 25.0.1 on MAC:
Error: expected 0 to equal '3.5'
expected 0 to equal '3.5'
# running test 'editable half values no zero setting ltr'
Test main - StarRating tests - editable half values no zero setting ltr FAILED on firefox 25.0.1 on MAC:
Error: expected 0.5 to equal '3.5'
expected 0.5 to equal '3.5'
# running test 'editable programmatic onchange ltr'
Test main - StarRating tests - editable programmatic onchange ltr FAILED on firefox 25.0.1 on MAC:
Error: expected 0 to equal '3.5'
expected 0 to equal '3.5'
# running test 'default'
# running test 'tab order'
# running test 'disabled'
# running test 'form values'

=============================== Coverage summary ===============================
Statements   : 45.31% ( 1909/4213 )
Branches     : 33.15% ( 1084/3270 )
Functions    : 42.32% ( 325/768 )
Lines        : 45.63% ( 1892/4146 )
================================================================================
firefox 25.0.1 on MAC: 4/9 tests failed

I'm going to push some changes to the intern/ test directory to allow for saucelabs testing etc. but I want to be clear that the failures are happening before my changes.

StarRating: support high contrast mode

StarRating uses background images and thus does not display in high contrast mode.

To test, use IE or FF on Windows after turning on high contrast mode: in Windows 7, do control panel --> change color scheme and select high contrast.

In high contrast mode, you need to use characters instead of background images; hopefully the CSS content: "..." rule will work.

Also, you cannot make any assumptions about the size of the characters because even if you did set a size, a user stylesheet may override it. Therefore you shouldn't even try to set a size.

I suggest using the ★ / ☆ characters to represent the stars, and for half stars perhaps the ⚫ / ⚪ characters.

parser: support data-dojo-mixin?

Should we migrate data-dojo-mixins attribute to the new custom element parser? Something like

<d-treemap data-mixins="dtreemap/Keyboard"></d-treemap>

If we want to continue to build components on this idea of pluggable mixins we probably need to have something similar like that in dui to make it easy to that in markup? If not we probably need to revise the idea because this would make it more complicated to use it.

I agree it's a nice feature in Dojo V1 but it doesn't fit into the web components philosophy. Eventually browsers will support document.register() natively, and if we use it then there won't be any way to do data-mixins because we won't see the data-mixins flag until too late.

So, it would require maintaining our own parser, and never registering d-treemap with document.register().

templates: binding delegate API

(idea from Akira Sudoh)

An important feature in MDV is binding delegate API, which allows us to do something akin to the dojox/mvc data converter.

In other words, it lets the app specify arbitrary bind variable strings such as {{ foo + bar ? foo : bar }} or more importantly something like {{date:dateProperty}}, where a binding delegate implementation can auto-convert JS Date object to formatted date.

The binding delegate API does not define the expression syntax. Instead it lets (user-defined) binding delegate parse the expression (what's inside {{ ... }}), which comes to the 2nd argument (path) in getBinding().

The plugin code is also responsible for notifying DUI whenever the computed value has changed.

Probably support for function calls (ex: {{func:arg1,arg2,arg3}}) should be built in to DUI.

To support something like {{ foo + bar ? foo : bar }} is nice too, but it's complicated to find out when it needs to be recomputed. (In this example it's when either foo or bar changes.) Perhaps a simple regex to find patterns matching [a-zA-Z_]+?

A current example from polymer is:

<html>
    <head>
        <script type="text/javascript" src="polymer-v0.0.20131003.min.js"></script>
        <script type="text/javascript">
            function onLoadHandler(){
                var template = document.querySelector("template");
                template.bindingDelegate = {
                    prepareBinding: function(expression){
                        var match = /(\w+):(.*)/.exec(expression),
                            bindingAccessor = {
                                format: function(value){
                                    return value + "";
                                },
                                parse: function(value){
                                    return +value;
                                }
                            };
                        if(match){
                            var path = match[2].trim();
                            return function(model){
                                return new PathObserver(model, path, null, null, null, bindingAccessor.format, bindingAccessor.parse);
                            };
                        }
                    }
                };
                template.model = {
                    numberProp: 0
                };
            }
        </script>
    </head>
    <body onload="onLoadHandler();">
        <template bind>
            <input type="text" value="{{number:numberProp}}">
            <input type="range" value="{{numberProp}}">
        </template>
    </body>
</html>

Add a CustomElement class on top of Widget

It would be great to have a CustomElement class, that widget would inherit from, that would allow creating a custom tag that is not a delite widget but could be parsed by register.parse.

This class would implement the "raw" custom element lifecycle (createdCallback, enteredViewCallback...), while the Widget class would extend it to add its own lifecycle methods (buildRendering, etc...).

StarRating: use refreshRendering()

After #26 is closed, StarRating should be updated to extend _Invalidated and use refreshRendering(). It's currently refreshing the rendering in the custom setters, but we want to standardize on refreshRendering(). So it's basically moving the code from the custom setters to refreshRendering().

cc @pruzand @cjolif @AdrianVasiliu @dmandrioli

API doc format (JSDoc vs. dojodoc)

At some point need to decide on our API doc format:

1. keep using the dojodoc format
2. use jsdoc format but keep using js-doc-parse; this would require updating js-doc-parse to understand jsdoc format and to parse our new constructs like dcl() and require()
3. use the JSDoc parser directly; this probably requires a lot of added markup with @extends etc. keywords because it doesn't understand declarations like require() or dcl()
4. drop API doc altogether and just put the info in the reference doc (markdown files)

For Heya we decided to just do reference doc, since (as you can see from Dojo V1 core) the reference doc and API doc are basically duplicates of each other. But are probably a different ball of wax due to all the inherited properties. I wouldn't want to redocument inherited properties for every subclass.

Tests are sometimes failing on FF ESR 24.2 (but working on FF ESR 24.1 or Chrome)

SVG declared in template is not interpreted

Replace ExampleWidget.html content with:

<div style="width: 50px; height: 50px;">
    <svg width="20px" height="20px" version="1.1" viewBox="0 0 30 30" preserveAspectRatio="none" xmlns="http://www.w3.org/2000/svg">
        <rect width="100%" height="100%" fill="red"></rect>
        <text x="49%" y="65%" font-size="14" font-weight="bold" fill="black" text-anchor="middle">10%</text>
    </svg>
</div>

Result with web inspector shows:

<d-example style="width: 50px; height: 50px;" class="d-example-widget" id="d-example-0">
    <svg xmlns="http://www.w3.org/2000/svg" preserveaspectratio="none" viewbox="0 0 30 30" version="1.1" height="20px"
         width="20px">
        <rect fill="red" height="100%" width="100%"></rect>
        <text text-anchor="middle" fill="black" font-weight="bold" font-size="14" y="65%" x="49%">10%</text>
    </svg>
</d-example>

But SVG is not interpreted by the browser (tested on FF and chrome).

dui/Slider.orientation should be a boolean

The dui/Slider.orientation property is defined as a string that accepts only 2 exclusives values ("H" or "V"). (https://github.com/ibm-dojo/dui/blob/master/Slider.js#L50)

orientation: "H",

Because of this, I think it would be better to define it as a boolean property named according to one of the orientation,for example:

horizontal: true,

It would also be consistent with other widgets that have the same use case like the LinearLayout.

use new standards for deliteful CSS classes

• prefix deliteful CSS class with d
• use hyphenated notation instead of camel case notation for CSS class names: d-star-rating instead of dStarRating, for example
• use a set of common css classes for some standard behaviours:
  • d-selected (to mark selection)
  • d-loading (to mark a state when loading is in process)
  • d ... (list to be completed)

Slider test updates

test_Slider.html needs to be updated to remove use of obsolete methods and modules:

• dojo/parser - use register.parse()
• dui/mobile/compat
• dui/registry - use dom.byId()

It also needs to be changed to web components syntax for markup, and stop using the new MyWidget(props, srcNodeRef) syntax for programmatic creation; only new MyWidget(props) is supported.

Manage a11y (high contrast) CSS resources

.dj_a11y descendent selectors are defined in delite/themes/common_template.less for all widgets that need a11y specific styling. I suggest that each component defines its a11y styles the same way it is done with RTL:

deliteful/{widget}/themes/{theme}/{widget}_a11y.less
deliteful/{widget}/themes/{theme}/{widget}_a11y_rtl.less

compiled CSS format

@cjolif is uneasy about compiling our LESS files into CSS wrapped in javascript because he's worried that it makes it harder for people to directly modify the CSS. Apparently people directly modify the compiled CSS files even though they aren't supposed to.

The reason the compiled CSS files are currently wrapped in JS is to:

• make it easy to load CSS cross domain, without the code-heavy approach used in other CSS loaders
• make it easy to do builds; users can create any layers they like, for example, ios-theme-for-widgets-im-using-on-landing-page, single-layer-with-all-widget-js-and-all-themes, etc.

So, if we compile LESS files into plain CSS files, then we would need to do one of:

• update dui/css! to load CSS via <link> tags, like the more full featured (and code heavy) CSS loaders mentioned in the dui/css! API doc
• keep loading CSS via XHR, except for builds, where the CSS would be rolled into the javascript, the same way that in Dojo V1, widget templates (accessed via dojo/text!) are rolled into the widget files

Doing builds with CSS is complicated though because of themes:

1. every widget will have multiple versions of its CSS corresponding to each theme (ex: Calendar iOS, Calendar Android, ...)
2. apps still need to be able to require() widgets that are not part of a layer

Presumably we don't want to roll the CSS for every theme into the main Calendar.js file?

Another approach is to not check in compiled CSS files at all, and compile then in the client on the fly. Again this is a question of builds vs. running against source, since we would presumably pre-compile the files in builds.

I tend to lean towards continuing the current JS wrapping, but do it during the build. Obviously this can't be done until we start supporting builds.

Key navigation is broken by Widget.enteredViewCallback method

This has been tested on Google Chrome 31 for Windows 7.

When dui/KeyNav is mixed with a dui widget, its postCreate method is setting the tabindex attribute of the widget node to the value "0", allowing it to receive focus when navigating the page using TAB keys.

Unfortunately, the Widget.enteredViewCallback method of the Widget class is reseting the tabIndex value to -1 (removing the tabindex attribute), so the widget node cannot receive focus anymore.

cleanup/refactor the theming dependencies

The current shared theming files (themes/common_templates.less and themes/theme/*.less) need to be cleaned up:

• they define global, common variables and rules that are based on "button" var/rule or named with 'button' in their names
• it defines button-specific rules, that are only used in delite to define more global var/rules.

migrate StarRating doh tests to Intern test

As Intern is the test framework that have been choosen by the community for dojo 2 automated tests, maybe we could start by migrating the existing StarRating doh tests to Intern ?

change how widgets declare which events they emit

If my component is firing an event (this.emit("event-name")) I would like to be able when using my component declaratively to do:

<my-component event-name="mylistener"></my-component>

or maybe

<my-component event-name="mylistener(event)"></my-component>

otherwise I have to declare it in markup and then in JavaScript do:

myComponent.on("event-name", mylistener)

which is not as convenient.

I guess this would require a mechanism for the component to "declare" in one way or another the events that it will fire?

EDIT:

as mentioned by @wkeese this is working (without the dash) if a onXXX method has been added the prototype. So this ticket is about this proposal:

1. to use emit()
2. to register events onto the widget so that they are accessible in markup ()
3. to have them documented using a proper technique and not a workaround using method names

StarRating should leverage FormValueWidget

To be properly integrated in an HTML form, StarRating should leverage the FormValueWidget mixin in order to use the readonly attribute instead of the current editable attribute, to support the disabled attribute and to transmit its value when a parent form is submited.

The maximum attribute should also be renamed max, to conform to the HTML input range naming scheme.

Use modular package structure for all UI web components

When dui common package is separated from the concrete widgets, I'd recommend that we refactor the concrete widgets so that there is a folder/package per web component that is self-contained in terms of templates, html, css, tests, docs rather than all widget code in a single directory. This will help enforce modularity of the widgets. A similar approach is being used on the polymer-ui-elements repository https://github.com/Polymer/polymer-ui-elements.

map properties to attributes

When you declare a custom element in Polymer, you specify a list of attributes:

<polymer-element name="a-widget" attributes="name,age">
...
</polymer-element>

Apparently that controls which properties are automatically mapped to its DOM attributes. So in the above example, calling

myWidget.name = "Bill";

will modify the DOM so it looks like:

<a-widget name=Bill>...</a-widget>

This doesn't work well for complex types, such as Tree.store, but it should work for booleans, numbers, and strings.

It could be useful if people want to query for widgets w/certain characteristics.

less vs. stylus

Need to decide on Less vs. Stylus. Stylus will make the dojo-contributors folks happy, but Less is supported in more tools (IDE's etc... Chris can comment more).

The decision may connect somehow with being able to use jQuery's themeRoller and/or bootstrap.

What dojo repo are you using?

I see 1.9.0dev in the package but suspect that's old docs? It doesn't seem to be https://github.com/csnover/dojo2-core.git as some tests are using _base
Almost got it working but require.js is in one of the tests so had to pull it manually.

Is it worth updating package.json with the correct deps?

Consider removing baseClass and rely on custom elements as CSS selectors

We have the opportunity to rely on custom elements, i.e.
For HTMLElement direct subclasses:
d-linear-layout {
...
}
instead of
.duiLinearLayout {
...
}

Otherwise:
button[is="d-button"]{
...
}
instead of
.duiButton {
color: white;
}

make separate core project

delite/Stateful is useful to more than UI widgets. Any of our projects that do not rely on the widget infrastructure might need this (example: gfx).

Define a policy for error handling

We need to decide how we properly handle and report errors in our delite/delitful code so that it is done in a consistent way throughout the lib.
Do we log every unexpected errors in a console.log ? Do we need a more "advanced" logging/tracing api ?

Regarding how to handle errors, I guess it depends on the context where the error happens, which make difficult to write a policy, but there should be some common guidelines. For ex:

• do not catch silently exceptions.
• throw Error instances, (as opposed to simple object) so that they are properly handled by the browser
• ?

But what should we do with the following contexts:

• Should public methods systematically check the validity of their parameters (for ex, assert it's not null/undefined, etc) ? Or should we document what it expects and then...
• If a parameter has an incorrect value, should it return silently or throw error ?

To summarize, we need to define a common policy for error handling and reporting.