… would incorrectly be identified as (not) observable
…as being used to control decisions that were not obviously related to its name So, have eliminated it, and replaced it with the more specific variable "bindingContextMayDifferFromDomParentElement", which now is only used for decisions directly related to its name
…nal to bind descendant elements even if the supplied node is a comment node
…ing the parent context by not exporting ko.bindingContext (i.e., stop custom bindings from calling "new ko.bindingContext" directly)
…ew $parentContext variable Benefit #1: Can reach custom properties on *all* ancestor contexts, and are not limited to those that haven't been overwritten (e.g., if we had $index, would now be able to reach all ancestor $index values, not just the closest one) Benefit #2: Allows discrimination between properties at the current level and properties at the parent level, which is good because not all custom properties may make sense to inherit.
… invoked until the use case is clear. (Note that, in the future, the custom bindings API may change to become more object oriented, so each binding would become an object instance that can hold its own data. In case we proceed in that direction, it may be preferable not to be changing the "init" and "update" semantics in the meantime)
…nderstand what it was for)
…r than replacing with a new instance (just for consistency with other code in that method) Also make spec slightly more demanding to prove it works with multiple selections
…allowedBindings is now exported as is; remove extra space in spec test
…to work with non-template virtual elements
…ction (to ensure the contents don't change during iteration)
…; 'text' can be set from 'nodes' but not vice versa.
…rking from templates stored as document fragments) for simplicitly, as the perf appears indistinguishable
… a DOM node array instead of a docFrag. (Other template engines might inherit from it, and make assumptions about the result type)
… a value for text() (where needed, by constructing and caching the value lazily based on the underlying doc frag). This also simplifes code elsewhere. Also renamed createAndPopulateDocumentFragment to moveNodesToDocumentFragment to emphasize that it detaches the suppled nodes from their original parent