ibm-js / deliteful Goto Github PK

List is not accessible on FF because you cannot tell which list item is focused.

See for example list_singleSelection_markAfter.html.

ViewStack sets up a listener on DOMNodeInserted, to support native calls to create ViewStack children such as Element.appendChild() , setting innerHTML , or calling insertAdjacentHTML(), rather than just supporting our custom Container.addChild() method.

Supporting Element.appendChild() is a nice API, especially since delite widgets are DOM nodes, so users may expect the standard Element methods to work.

However, we intentionally avoided listening to DOMNodeInserted in register.parse() due to performance concerns. The issue would be if one of the ViewStack's panes contained, for example:

• a dgrid object that asynchronously gets populated with 2000 DOM nodes
• a chart that gets populated with thousands of SVG nodes

If we do want to support appendChild() across the board then it may require changes in other code like Container and KeyNav.

Hi,

should we define a standard way to document - in the widget source code / widget API documentation - the tag to use to create a widget in markup ?

We need to be sure we don't drop features that were available in 1.x when switching to deliteful. Or at least, that the features that are dropped, if any, were the results of a decision or expected.
@dmandrioli could you make a comparaison of the new deliteful containers capabilities vs their dijit counterparts ? (ex: LinearLayout vs BorderContainer, ViewStack vs StackContainer?)

Just try runsauce.sh:

Initialised internet explorer 10 on WINDOWS
Test main - ScrollableContainer - scroll with animation (via button, inside LinearLayout, scrollDirection=vertical) FAILED on internet explorer 11 on WINDOWS:
Error: Timeout reached on main - ScrollableContainer - scroll with animation (via button, inside LinearLayout, scrollDirection=vertical)
    at Error (<anonymous>)
    at new ErrorCtor (/ws/deliteful/node_modules/intern/node_modules/dojo/errors/create.js:13:21)
    at null._onTimeout (/ws/deliteful/node_modules/intern/lib/Test.js:164:21)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
Test main - ScrollableContainer - scroll with animation (via button, inside LinearLayout, scrollDirection=vertical) FAILED on internet explorer 10 on WINDOWS:
Error: Timeout reached on main - ScrollableContainer - scroll with animation (via button, inside LinearLayout, scrollDirection=vertical)
    at Error (<anonymous>)
    at new ErrorCtor (/ws/deliteful/node_modules/intern/node_modules/dojo/errors/create.js:13:21)
    at null._onTimeout (/ws/deliteful/node_modules/intern/lib/Test.js:164:21)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

It also fails on chrome:

Test main - ScrollableContainer - scroll with animation (via button, inside LinearLayout, scrollDirection=vertical) FAILED on chrome 27.0.1453.116 on windows:
waitForCondition failure for: document.getElementById('scrollContainer').scrollableNode.scrollTop=='100'

I feel like we discussed this before, but it's still broken.

See how https://github.com/bryanforbes/dojo/blob/intern-conversion/tests-intern/intern.js defines a default intern configuration and then https://github.com/bryanforbes/dojo/blob/intern-conversion/tests-intern/intern.local.js
customizes it. We should do that, or something like that, to avoid duplicating settings between the intern configuration files.

Christophe did an alternate proposal in https://github.com/cjolif/delite/compare/intern?expand=1.

This applies to both delite and deliteful.

cc @cjolif @lbod @sbrunot

ProgressIndicator

ProgressIndicator is a round spinning graphical representation that indicates the current task is ongoing.

Features

• Allow to start/pause animation (default: infinite clockwise animation)
• Allow to set the duration of a spinning cycle (default 1 second)
• Allow to set a numeric value from 0 to 100%: value is shown in the center of the widget and the round spinning displays accordingly
• Variable size
• Supports a11y high contrast

Note: visual aspect is the same for all themes/all browsers.

The basic architecture for the List widget, currently studied on branch https://github.com/sbrunot/deliteful/tree/list-dev, is the following:

The List widget uses a dojo object store as the source of its entries (items).

It provides one default memory store that can be defined with markup:

<d-list>
    <d-list-store>
        <d-list-store-item item="{a="...", ...}"></d-list-store-item>
        <d-list-store-item item="{a="...", ...}"></d-list-store-item>
        ...
    </d-list-store>
</d-list>

The style of the list is defined by its baseClass attribute. Two styles are provided: d-round-rect-list and d-list (to achieve the same styling than the dojox.mobile.RoundRectList and dojox.mobile.EdgeToEdgeList widgets).

How items are rendered within the List is defined by an itemsRenderer widget. A default one, that renders items similarily to dojox.mobile.ListItems is provided. Custom one can be created by extending a base class and redefining a renderItem(item) method.

The list support categorized items: user has to define the name of an item attribute to use as the items category, and the list will take care of creating category headers for its items.

How categories are rendered within the List is defined by a categoriesRenderer widget. A default one, that renders categories similarily to dojox.mobile categories is provided. Custom one can be created by extending a base class and redefining a renderCategory(category) method.

The List widget supports single and multiple selection through the delite/Selection mixin.

The List widget supports keyboard navigation though the delite/KeyNav mixin.

The List is by default scrollable (it will use the future delite/Scrollable mixin for that), but scroll can be disabled.

Two additional sets of features are provided through specific mixins:

1. Pagination through the List/Pageable mixin

This mixin provides pagination (of both store items and dom node) and infinite scrolling for the list.

2. Edition through the List/Editable mixin

This mixin provides a user interface to remove and or move items within the list. This mixin may not remove / move the elements itself but send events that must be processed by the user application to react to the deletetion / move request of the user.

I suggest to put the widget samples on each widget folder, under a sample folder, such as:

deliteful/ProgressBar/samples

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

Design draft

• layouts its children horizontally, creating "columns". All columns have the same width (using a LinearLayout with class=fill on all children).
• Number of columns is controlled by breakpoints in LESS file.
• Choice of breakpoints: reuse breakpoints of bootstrap ? http://getbootstrap.com/css/
• Rely on DisplayContainer architecture

I think we decided most of our properties should be changeable at runtime. There must be a very good/strong reason for not doing that.

In Slider I see that min, max and step are not changeable at runtime (at least they say "const"). I think they would be good candidate to be changeable because the slider might be connected to some backend and sometimes interact with data between a and b and sometime between c and d and you don't want to rebuild the widget for that.

A few other remarks:

• I'm not sure why defaults are NaN as well I guess 0, 100 or something like that would be reasonable and make by default the Slider working fine without having to set some min/max?
• we should be consistent in terms of how we name the min & max properties. Here that is max and in ProgressBar PR (#16) this is maximum. Slider coming first maybe ProgressBar should be "fixed" (@seb-pereira ?)

(Originally from email, but moving to a ticket.)

StarRating seems to do a lot of computation in JavaScript that's probably better handled in CSS or HTML. While it sometimes it makes sense to do computation in JavaScript, it's usually better to leverage the browser's built in functionality when possible.

The areas I see for improvement are:

(1) Use separate DOMNodes for left and right half of stars

Currently the code has one DOMNode per star, but allows clicking/hovering on the left or right of a star. It needs to track mouse position to tell if the user is hovered/clicking over the left half or right half of a star.
Instead you should just have two nodes, one for the left half of the star and one for the right half. This will simplify the code, the test script, and the sprite for the stars.

(2) Implement hover effect in CSS, not JavaScript

StarRating uses JavaScript to track mouse movements and control which stars have the duiStarRatingFullStar CSS class vs. the duiStarRatingEmptyStar CSS class. But this can all be done in CSS, without any JavaScript, by using the tilde operator:

.duiStarRatingHovered div { /* CSS for full hovered star */ }
.duiStarRatingHovered  div:hover ~ div { /* CSS for empty hovered star */ }

As a corollary, to display the widget when it isn't in hover mode, all you need is a class on one of the stars, not on N of them. For example, if there are three stars and the first two are supposed to be filled in, use markup like:

<d-star-rating>
    <div></div>
    <div class=duiStarRatingSelected></div>
     <div></div>
</d-star-rating>

Then you can fill the first two stars (but not the third) with CSS like:

.duiStarRating div { /* CSS for full star */ }
.duiStarRating  div.duiStarRatingSelected ~ div { /* CSS for empty star */ }

A larger principle here is to give apps as much ability to customize the look and feel as possible. In particular, the app may want to apply a separate style to the selected star than to the stars before it, or the stars after it.

Sebastian is reluctant though about implementing this because it increases the CSS the user needs to write for custom sprites, assuming they are writing CSS directly rather than generating it from .less files. Note that the CSS for custom font-icons (see item 4) is minimal.

Note that with (1) and (2), for event handlers all you should need is a click handler (to set the value and clear "hover" mode), and mouseover handle (to enter "hover" mode), and a mouseleave handler (to clear "hover" mode).

(3) minimize special code for RTL mode

There's a lot of code in bidi/StarRating.js, and almost all of it is unneeded. All you should need is code to reverse what the left and right arrow keys do.

The key is that the document ordering of the stars should be the same in LTR and RTL mode. The only thing that should change is how the browser positions the stars, and you can control that by putting dir=rtl on the widget root node. You shouldn't need to use float:left or float:right, but rather using display:inline-block for everything. Also, you shouldn't have loops that operate in reverse in RTL mode.

(4) use font-icons for at least some of our themes

The problem with sprites is that it's hard to change the color or the size, because you need to use photoshop etc. With font icons, both color and size are easily adjustable through CSS. So it's good to use font-icons for something like the custom theme, where the user is supposed to be able to adjust the color by setting less variables.

Sebastien said he would try to make the CSS for font-icons and sprites.

Sebastien did a prototype of (1) - (3) in https://github.com/sbrunot/dui/tree/starrating-css, and I've prototyped font-icons in http://bill.dojotoolkit.org/stars.html / https://gist.github.com/wkeese/8125097.

The css layout approach taken in deliteful excludes the cases where a child widget needs to react to a resize event. For example, a Chart would need to do some computation to rearrange its components (scale, plot, etc) according to the new size. In dijit, the containers notifies its children of a size change. With the css approach, there's no such notification.

samples/test_StarRating.html references lots of non-existant images, for example:

.d-cust5-star-rating-star-icon:before {
    content: url('images/star-6.png');
}

Those files are actually in the test/ directory, but test_StarRating.html is in the samples directory. Probably there shouldn't be a cross-reference like that, so the images should be moved.

On desktop, a common feature of SidePane-like containers is the ability to "pin" the pane, that is, stick it to its position to make it always visible.
Would be interresting to know how the deliteful SidePane handles this use case, or could handle it.

Currently, the List widget ends up generating DOM like below:

<d-list-category>Category A:</d-list-category>
<d-list-item>Category A Item 1</d-list-item>
<d-list-item>Category A Item 2</d-list-item>
<d-list-category>Category B:</d-list-category>
<d-list-item>Category B Item 1</d-list-item>
<d-list-item>Category B Item 2</d-list-item>

But according to the aria spec and in particular the definitions for list and group, a group's listitems need to be inside of the group. So something like:

<d-list-group role=group aria-labelledby=foo>
    <d-list-category id=foo>Category A:</d-list-category>
    <d-list-item role=listitem>Category A Item 1</d-list-item>
    <d-list-item role=listitem>Category A Item 2</d-list-item>
</d-list-group>
<d-list-group role=group aria-labelledby=bar>
    <d-list-category id=bar>Category B:</d-list-category>
    <d-list-item role=listitem>Category B Item 1</d-list-item>
    <d-list-item role=listitem>Category B Item 2</d-list-item>
</d-list-group>

@sbrunot is working on this, but I'm adding a ticket so it's not forgotten.

Version 1.4.0 of Intern is out, and provides a fix for theintern/intern#126, that we encounters in StarRating functional tests, along with a new html report that includes coverage (which might be good news at least for windows users !).

https://github.com/theintern/intern/releases

This will allow to style them with themeroller (ala dgrid).

Maybe this will require a minimal "blank" theme so that the default theme does conflict with what theme roller will do.

See: http://www.filamentgroup.com/lab/developer_your_own_jquery_themeroller_ready_components/ for the list of CSS classes.

See list-mark-1.html and probably some other samples and test files too:

<script type="text/javascript">
    require([
        "dojo/store/Memory",
        "dojo/store/Observable"
    ], function (MemoryStore, Observable) {
        globalStore = new Observable(MemoryStore({data: []}));
    });
</script>

<script type="text/javascript">
    var ready = false;
    require([
        "delite/register",
        "deliteful/list/List",
        "dojo/domReady!"
    ], function (register) {
        register.parse();
        ready = true;
    });
</script>
...
<d-list id="list-mark-1" style="height: 200px" selectionMode="multiple" store="globalStore" multiCharSearchDuration="5">

It's indeterminate which require()'s callback will execute first. It depends on how fast various modules load. If List completes loading before Memory and Observable, then it will evaluate the store="globalStore" before globalStore is defined.

I suggest again that you do it like this:

   <script>
       require(["dojo/store/Memory"], function (memory) {
           myStore = new MemoryStore({data: [...]});

         require(["delite/register", "deliteful/list/List"], function (register) {
            register.parse();
          }
       });
   </script>
   ...
   <d-list store="myStore"></d-list

Or an alternative would be to not set any store initially, but set it later:

    <script>
       require(["dojo/store/Memory", "delite/register", "deliteful/list/List"], function(memory, register) {
           register.parse();
           window.myList.store = new MemoryStore({data: [...]});
        });
   </script>
   ...
   <d-list id="myList"></d-list>

Note as usual that on Chrome the <d-list> widget will be instantiated as soon as List loads; it won't wait for the register.parse() call.

The List widget's Renderer, ItemRenderer, and CategoryRenderer widgets should be rewritten to work from templates. This will simplify their design and make it easier to subclass them.

The ItemRenderer template will look something like:

<div role="listitem" class="d-list-item">
   <span class="d-list-item-node">
       {{#if iconClass}}
            <span class="d-list-item-icon {{iconClass}}></span>
       {{/if iconClass}}
       <span class="d-list-item-label d-key-nav">{{label}}</span>
       ...
    </span>
</div>

Note that the template is marking the nodes that should be keyboard navigable via a d-key-nav class, eliminating the need for the widget to call setFocusableChildren().

Note also the <span class="d-list-item-node"> wrapper is there because according to @sbrunot it's a requirement of the Editable mixin.

This refactor has a lot of ramifications on the overall renderer and list architecture, including:

1. Renderer: I think you can get rid of all the existing code. You might want to add new methods to get the keyboard navigable fields, like _getFirstField(), _getLastField(), _getNextField(field), _getPreviousField(field). Those methods would be called by List. You could also set this.renderItem here, or alternately let the Editable mixin query for the node w/class d-list-item-node.
2. Get rid of ItemRenderer's render() and _renderNode() methods, as ItemRenderer's will just have a buildRendering() method defined by handlebars, based on the template. Update example custom item-renderers to use templates rather than depending on those methods.
3. The ItemRenderer widget will have scalar properties named label, iconClass, etc., rather than an Object property called item. Code and examples should be updated to match.

The feature works but the unit test mysteriously fail under IE11 (unit/ViewStack.js unit/ViewStack-prog.js).
The test has been commented for now.

ProgressBar
ProgressBar widget displays status for tasks that takes a long time.

• can be used on desktop and mobile browsers.
• displays the amount of completed task with a label (percentage or absolute value)
• indeterminate state: an animation indicates a task is underway but the amount completed is unkown.

Pull request
#16

Features

HTML structure

<div class="d-progress-bar d-progress-bar-empty d-progress-bar-full d-progress-bar-indeterminate"
    id="{widgetID}"
    role="progressbar"
    aria-valuenow="..."
    aria-valuemin="0"
    aria-valuemax="..."
    aria-labelledby="{widgetID}_label">
    <div class="d-progress-bar-background">
        <div style="width: x%" class="d-progress-bar-indicator"></div>
    </div>
    <div id="{widgetID}_label" label-right="..." class="d-progress-bar-label" >{label}</div>
</div>

CSS classes

d-progress-bar

d-progress-bar-background

d-progress-bar-indicator

d-progress-bar-label

d-progress-bar-indeterminate

d-progress-bar-empty

d-progress-bar-full

Customization
ProgressBar doesn't rely on template. Use CSS to customize L&F.

SidePane mysteriously extends Container. Since IIUC it doesn't contain a list of children, it should probably just extend Widget.

The character selection mark used to signal if a list item is selected or not (characters \2610 and \2611) does not display in android stock browser (tested with android emulator version 4.3).

Currently the category is focusable:

The category should not be focusable, and keyboard navigation should not stop at the category.

It is not necessary to focus the category for the screen reader to read it. That's why browsers do not focus <h1> elements or <fieldset> elements.

Note that even if you don't implement the proper DOM structure (using role=group elements for the list-items in each category), JAWS will still read the category names when using the up/down arrows to navigate the following list:

<div role="listbox" tabindex="0">
    <h1>fruits</h1>
    <div role="option" tabindex="0">banana</div>
    <div role="option" tabindex="0">orange</div>
    <div role="option" tabindex="0">apple</div>

    <h1>vegetables</h1>
    <div role="option" tabindex="0">lettuce</div>
    <div role="option" tabindex="0">tomato</div>
    <div role="option" tabindex="0">cucumber</div>
</div>

It'd be worth following what @bryanforbes has been doing at https://github.com/bryanforbes/dojo/tree/intern-conversion/tests-intern and using a similar grunt and test file structure (maybe even the services JSGI 'middleware')

I don't mind taking this on

The <d-list-store> tag is somewhat meaningless. It always occurs within a <d-list> tag:

<d-list>
  <d-list-store>
      {"label": "First item", "iconClass": "my-icon-class-a"},
      {"label": "Second item", "iconClass": "my-icon-class-b"},
      ...,
      {"label": "Last item", "iconClass": "my-icon-class-z"}
   </d-list-store>
</d-list>

It could just as easily be removed, simplifying the markup:

<d-list>
      {"label": "First item", "iconClass": "my-icon-class-a"},
      {"label": "Second item", "iconClass": "my-icon-class-b"},
      ...,
      {"label": "Last item", "iconClass": "my-icon-class-z"}
</d-list>

Alternately, it could exist independently as a top level node, like the dijit/form/DataList, something like:

<d-list-store id=myStore>
      {"label": "First item", "iconClass": "my-icon-class-a"},
      {"label": "Second item", "iconClass": "my-icon-class-b"},
      ...,
      {"label": "Last item", "iconClass": "my-icon-class-z"}
</d-list-store>
...
<d-list store=myStore></d-list>

See sbrunot@0abf3ac#commitcomment-5421652 for prior discussion.

Assigning to @pruzand since Sebastien wants him/@cjolif to decide.

See: https://docs.google.com/document/d/1r2NE5wMppBXJ9XmT-TnUtFtm6p5Z4KQoOmpiR9O8cHY/edit as something to be discussed and decide on or not.

We need as well to determine where to put various styles. I would say that:

1. things that are absolutely required by the widget for it to work (and that for this reason must not be changed by the user) should be set programmatically in the widget. The documentation should also say that the widget is hardcoding this particular style so this is clear to everyone.
2. things that can be changed by the user must be put in theming even if they are not necessarily meant to be different by theming (in which case they are in a component_template.less imported by the various themes).
   (is template the right name here? shouldn't it be component_common?)

SidePane needs functional tests for user interaction (i.e. where the user clicks to show/hide the side pane).

Also, the unit tests should be changed to check the position of the panes after the animation completes.

And, the unit tests and/or functional tests should check programmatic creation.

Check the new version of delite/Store[Map] that uses the new dstore api (provided by @cjolif on a branch) to see if List can be updated to use it. If it's ok, @cjolif will commit and @sbrunot will then commit an update of List that uses it.

It is not possible today to change the range of a slider in one interaction: one needs to adjust both min and max thumbs.
I would be great if we could drag the 'range' (the area between the two thumbs) to translate it as a whole.

ViewStack needs tests for programmatic creation, in particular to make sure that the first pane added is visible. AFAICT it currently doesn't work.

Also, the unit tests should be changed to check the state of the panes (which pane is hidden and which is shown) after the transitions complete.

What are we going to do about the dojo mobile dom buttoms (css under dojox/mobile/themes/common/domButtons) ? Are we going to release them as CSS files, are we going to release them "wrapped" into a domButton widget ? Something else ?

Slider should provide a specific style to reflect its disabled state. (This should be a general rules in fact for all the deliteful widgets).

ViewStack (actually DisplayContainer) has a show() method to display a pane. show() returns a Promise that resolves when the display is complete:

stack.show("foo").then(...)

This API is convenient for javascript code, but doesn't work well in markup, i.e. you can't say:

<d-view-stack selectedChild="foo"> ...

Also, the API seems not very HTML-ish, so it doesn't fit well with the idea of custom elements.

Contrast this with delite/Store, where you control the store by setting the store property (rather than calling a function), and async completion is reported through an event:

store.on("query-success", function () {
    ...
});
store.store = ..

DisplayContainer actually fires an event too, so you can already do:

stack.on("delite-display-complete", function () {
    ...
});
stack.open("foo");   // but not stack.selectedChild = "foo";

Note that show() takes optional settings to control the transition used, which would need to be handled something like:

stack.transition = ...;
stack.selectedChild = ...;

cc @cjolif @pruzand

A sample should be added that demonstrate a list of items that, clicked / tapped / receiving key SPACE or ENTER performs a transition to another view (a different view for each list item).

EDIT (CJ): Only the accessibility part seems to be incomplete on that one (last comment from @wkeese all the other items are completed)

Hi,

writing functional tests for deliteful widgets using the Intern promised based API is really difficult (try to make a loop, for example, you'll understand what I mean).

There is indeed a synchronous webdriver javascript API out there that we can leverage to ease the development of functional tests and reduce the overall cost and time to market of our widgets: wd-sync (https://github.com/sebv/node-wd-sync), from the same developers than wd.js (that is wrapped by Intern promised based API).

I've already developped a utility function to register to intern a test suite written with wd-sync, so it's just about adding this utility to deliteful/tests and using it when needed in our tests.

Note that an enhancement requests exists on the Intern project to add this kind of utility to the Intern framework, but there is no current milestone set to achieve this: theintern/intern#101, so I think we should lead the way on this.

Try list_singleSelection_markAfter.html using JAWS 14. The screen reader never announces which item(s) are selected. Thus, blind users have no way of knowing which item(s) are selected.

Contrast with the HTML below, where the selected item is announced when the list is focused:

<div role="listbox" tabindex="0">
    <div role="option" tabindex="0">goat</div>
    <div role="option" aria-selected="true" tabindex="0">frog</div>
    <div role="option" tabindex="0">horse</div>
</div>

I don't know how to get JAWS to announce which item(s) are selected without focusing the List itself, but the current code is not usable (if you don't have vision).

I'm not sure this comes from the Slider itself, this might well come from something in delite or polymer or requirejs.. However as of now I just reproduce this with Slider. Just run:

<html>
<head>
    <script src="../platform/platform.js"></script>
    <script src="../requirejs/require.js"></script>
    <script>
        require.config({
            baseUrl: ".."
        });
        require(["deliteful/Slider", "delite/register", "dojo/domReady!"], 
                     function(Slider, register){
            require([], function() {
                register.parse();
            });
        });
    </script>
</head>
<body>
    <d-slider value="50" min="0" max="100"></d-slider>
</body>
</html>

The slider visual representation will be broken.

If you don't load Polymer/platform and/or if you don't do a nested require call everything is working fine.

Tested on FF 27.0.1

For a user to be able to use the back/forward button on the browser w/out the StarRating widgets losing their values, StarRating should work similarly to Slider, where the designer can supply an <input> in the original markup:

<d-star-rating>
    <input>
</d-star-rating>

In dojo mobile, we used to provide pure CSS icons in the themes of our mobile widgets.

Following an informal proposal by @wkeese, I think it would be usefull to study the possibility to use a custom font file that defines icons to use in our deliteful themes.

What we need to assess is, at minimum:

1. Is it supported on all our target browsers and platforms ?
2. Will it be more performant than CSS icons (file size, ...) ?
3. Is it easy to do and maintain (creating and maintaining the font file) ?

See list_singleSelection_markAfter.html.

Clicking a list item's label w/the mouse focuses the label inside the list item rather than the list item itself:

Clicking anywhere on the list item should focus the list item itself. The label should not be separately focusable by mouse or keyboard, especially since this List is in selection mode, and the aria attributes (like aria-selected) are on the list item itself.