Wrapping up this series from part 3 we have two members of the WinJS.UI namespace that match others in WinJS.Utilites for obscurity.
The first is WinJS.UI.scopedSelect, to which you provide a CSS selector and an element. This function is documented as “Walks the DOM tree from the given element to the root of the document. Whenever a selector scope is encountered, this method performs a lookup within that scope for the specified selector string. The first matching element is returned.” What’s referred to here as a “selector scope” is a property called msParentSelectorScope, which WinJS sets on child elements of a fragment, page control, or binding template. In this way, you can do a querySelector within the scope of a page control, fragment, or template without having to start at the document level. The fact that it keeps going up toward the document root means that it will work with nested page controls or templates.
The other is WinJS.UI.getItemsFromRanges, which takes a WinJS.Binding.List and an array of ISelectionRange objects (with firstIndex and lastIndex properties). It then returns a promise whose results are an array of items in that data source for those ranges. Simply said, this exists to translate multiple selections in something like a ListView control into a flat array of selected items–and, in fact, is what’s used to implement the getItems method of a ListView’s selection property. So if you implement a list control of your own around a WinJS.Binding.List, you can use getItemsFromRanges to do the same. The method is provided, in other words, to work with the data source as that it a separate concern from the ListView itself.