The Shadow Tree

shadow tree The baseURI of a node in a shadow tree is the same as its template counterpart.
The xml:base data of the cloned template element must be set so that the baseURI of nodes in the resulting shadow tree is the same as their pre-cloning counterparts

shadow tree The ownerDocument property on a shadow tree node points to the binding document's Document node
All shadow nodes' ownerDocument pointers are left pointing at their binding documents' Document node(s).

js, shadow tree, internal object, assumption The shadowTree member of the internal object of a binding is a reference to the shadow tree generated by the binding
the shadowTree member of the internal object must be set to be a reference to the template element clone (the root of the shadow tree). Will probably assume this in a bunch of tests
def 'internal object': http://www.w3.org/TR/xbl/#internal

shadow tree No mutation events fire because of shadow tree generation.
No mutation events must be fired during the above steps.

shadow tree When a shadow tree is generated from a template element, any bindings that apply to elements in the shadow tree are applied.
Any bindings that apply to elements in the shadow tree must be applied When are they applied exactly? needs better assertion

shadow tree, main assertion The shadow tree is a deep copy of its corresponding template
its first template element must be deeply cloned.

Template element

shadow tree A shadow tree is generated if a template element is added to a binding element that had no template element.
A shadow tree must be generated if a template element is added to a binding element that had no template element.

shadow tree The shadow tree is destroyed if a template element is removed from the binding and the binding had one template element.
If the template element is removed, then the shadow tree must be destroyed.

shadow tree A shadow tree is regenerated if its corresponding template element or any of its descendants is mutated in any way
when a template element or any of its descendants is mutated in any way, any bindings whose shadow tree was constructed from that element must be regenerated.

shadow tree Only the first template child of a binding is used to generate shadow tree content on a bound element.
The template element used to generate a binding* is always the first such element in a binding element 'binding' should be 'shadow tree' maybe

shadow tree If the binding element is mutated in a way which changes which template element is the first child, then the shadow tree is regenerated to match the new first template.
If the binding element is mutated in a way which changes which template element is the first, then the corresponding shadow tree must be regenerated.

shadow tree If a binding element has no template element, then no shadow content is generated for that binding.
If the binding element has no template element, then no shadow content will be generated for this binding.

Destruction

shadow tree, explicit children distribution, final flattened tree When the shadow tree is destroyed the explicit children of the bound element are re-distributed according to the remaining shadow trees' content elements (or, if there are none, putting the nodes back directly under the bound element).
The destruction of a shadow tree consists of recreating the final flattened tree without the influence of that binding's shadow tree by redistributing the explicit children to the remaining shadow trees' content elements (or, if there are none, putting the nodes back directly under the bound element). def 'explicit children': http://www.w3.org/TR/xbl/#how-nodes

js, shadow tree When a shadow tree is destroyed the shadowTree member of the internal object is set to null.
the shadowTree member of the internal object must be set to null.

xbl:attr

attribute forwarding If an item from the space-separated list from xbl:attr does not match the BNF pattern [s1 ':'] s2 ['=' [s3 ':'] s4] ['#' s5] (where s1..s5 are strings of characters not containing any of ":". "=", or "#") then it is ignored and not forwarded.
The xbl:attr attribute's value must be parsed as follows. First, it must be split on spaces (treated as a space-separated value). Next, each resulting item must be matched against the following pattern (given here in pseudo-BNF, where square brackets indicate optional terms): xbl inherits item := [s1 ':'] s2 ['=' [s3 ':'] s4] ['#' s5] ...where s1..s5 are strings of characters not containing any of ":". "=", or "#". If any item does not match this pattern, then the item is in error and must be ignored. Other items in the list, if any, are not affected by this.

attribute forwarding If an item from the xbl:attr list is not a valid QName or QName=QName pair, then that item is ignored.
The values s1:s2 and s3:s4 (if present) must be resolved to fully qualified names using the attribute QName resolving semantics and the namespaces prefix declarations in scope on the element on which the xbl:attr attribute is found, at the time that the attribute is parsed. Any value in the list that does not resolve to a fully qualified name is in error and must be ignored. def 'QName': http://www.w3.org/TR/2006/REC-xml-names-20060816/#ns-qualnames

attribute forwarding Changes to namespace prefix definitions in the shadow tree that affect QNames used in xbl:attr attributes take effect the next time the attribute is parsed (which must be the next time the attribute is changed, but may be earlier).
Changes to namespace prefix definitions in the shadow tree that affect QNames used in xbl:attr attributes take effect the next time the attribute is parsed (which must be the next time the attribute is changed, but may be earlier)

attribute forwarding, xbl:text When xbl:text is specified on the left hand side of a =-separated item, the value of the attribute specified by the right-hand side on the bound element is represented as a text node underneath the corresponding shadow element in the final flattened tree.
When specified on the left-hand side of the pair it indicates that the value of the attribute on the right-hand side are to be represented as text nodes underneath the shadow element in the final flattened tree.

attribute forwarding, xbl:text If xbl:text is specified on the left-hand side of a =-separated item in xbl:attr and the shadow node has any child nodes in the DOM, then the text is not forwarded.
If the element* has any child nodes in the DOM (any nodes, including comment nodes, whitespace text nodes, or even empty CDATA nodes) then the pair is in error and UAs must ignore it, meaning the attribute value is not forwarded. Otherwise, a text node must be created, and that text node will be placed under the element in the final flattened tree. which element?

attribute forwarding, xbl:text The parentNode, nextSibling, previousSibling, childNodes, firstChild, and lastChild attributes of text nodes created by xbl:text forwarding are null or empty.
Text nodes created in this way are orphans; their parentNode, nextSibling, previousSibling, childNodes, firstChild, and lastChild attributes are all null or empty

attribute forwarding, xbl:text The ownerDocument attribute of a text node created by xbl:text forwarding is set to the same as the shadow content node that generated it.
Their ownerDocument attribute is set to the same as the shadow content node that generated them.

attribute forwarding, xbl:text When xbl:text is specified on the right hand side of a =-separated item in xbl:attr, then any text nodes (including CDATA nodes and whitespace text nodes) that are explicit children of the bound element must have their data concatenated and the resulting value stored as the attribute on the left-hand side.
When used on the right-hand side, it indicates that any text nodes (including CDATA nodes and whitespace text nodes) that are explicit children of the bound element must have their data concatenated and the resulting value stored as the attribute on the left-hand side.

attribute forwarding, xbl:attr If xbl:text occurs by itself as an item in xbl:attr (not in a =-separated item), then it is ignored.
The xbl:text value cannot occur by itself in the list. If it occurs by itself, it is in error and UAs must ignore that value in the space-separated list that is the xbl:attr attribute.

attribute forwarding, xbl:lang When xbl:lang is specified on the right-hand side of an =-separated item in xbl:attr then the attribute specified by the left hand side is set to the natural language of the bound element or the empty string if no language is defined.
When used on the right-hand side, it indicates that the value to be copied is the natural language of the bound element, typically given by the attribute xml:lang of that element or an ancestor, or by HTTP headers, or similar. If no language is defined, then the value to be copied must be the empty string.

attribute forwarding, xbl:lang When xbl:lang occurs by itself or on the left-hand side of an xbl:attr, it is ignored.
The xbl:lang value cannot occur by itself or on the left-hand side. If it does, it is in error and UAs must ignore that value in the element's xbl:attr attribute.

attribute forwarding If an element in the XBL namespace other than xbl:text or xbl:lang is an item in xbl:attr, then it is ignored.
Any other values in the XBL namespace in the list are in error and must be ignored. (In particular, trying to change or set the value of xbl:pseudo or, worse, xbl:attr, must not result in any changes to any attributes.)

attribute forwarding If an attribute is listed multiple times on the left hand side of an xbl:attr item or on its own, then the last listing is forwarded.
If an attribute is listed multiple times on the left hand side (or on its own), then the last designation wins (as if the attributes were each forwarded in turn, an earlier forwarding being overwritten by a later one).

attribute forwarding If an item in the xbl:attr list is followed by a #url, then the value of the attribute on the shadow node is set to the value of the attribute from the bound element, resolved into an absolute URI using the base URI of the bound element.
The value must be resolved to an absolute URI using the base URI of the source element before being forwarded.

attribute forwarding If an item in the xbl:attr list is followed by a #text designation, then the value of the attribute on the shadow element is set to the value of the attribute on the bound element.
The value is forwarded unchanged.

attribute forwarding If an item in the xbl:attr list is followed by a designation other than #url or #text, then that item is ignored.
The attribute must not be forwarded. The value is in error and UAs must ignore that value in the element's xbl:attr attribute.

attribute forwarding, main assertion If an item in the xbl:attr list is a valid single item without a type designation, then the value of the attribute on the shadow node is set to the value of that attribute on the bound element.
whenever the attribute is set or removed on the bound element, the corresponding attribute on the shadow content is also set or removed.

attribute forwarding, main assertion If an item in the xbl:attr list is a valid =-separated pair without a type designation, then the value of the attribute specified by the left-hand side is set on the shadow node to the value of the attribute specified by the right-hand side on the bound element.
whenever the attribute is set or removed on the bound element, the corresponding attribute on the shadow content is also set or removed.
When two names are specified, the attribute to be added on the shadow content node is listed first, and the attribute of the bound element is second.

attribute forwarding When the value of xbl:attr is applied, if an attribute to be forwarded exists on the bound element and it's corresponding attribute exists on the shadow tree element, then the shadow tree element's attribute is changed to the appropriate value.
Whenever attribute forwarding happens: existing attributes to which values are being forwarded must have their values changed

attribute forwarding When the value of xbl:attr is applied, if an attribute to be forwarded exists on the bound element, but not on the shadow tree element, then it must be added to the shadow tree element
attributes that are being forwarded that do not yet exist on the shadow tree element must be added to the shadow tree element

attribute forwarding When the value of xbl:attr is applied, if an attribute to be forwarded is not present on the bound element, then that attribute is removed from the shadow node.
attributes to which values would be forwarded but whose source attributes are not present on the bound element must be removed from the shadow tree element.

attribute forwarding The value of xbl:attr is applied when the shadow tree is generated.
It must be applied (causing the relevant attributes and text nodes to be updated) when the shadow tree is generated

attribute forwarding The value of xbl:attr is applied when the xbl:attr attribute itself is changed.
It must be applied (causing the relevant attributes and text nodes to be updated)...when the attribute is changed

attribute forwarding The value of xbl:attr is applied whenever any of the bound element's attributes or text nodes referred to by the xbl:attr attribute change.
It must be applied (causing the relevant attributes and text nodes to be updated)...whenever any of the bound element's attributes or text nodes referred to by the xbl:attr attribute change.

content

explicit children distribution If an element stops matching a content element that it is assigned to, then the bound element's explicit children are re-distributed.
If an element stops matching a content element that it is assigned to, then the bound element's explicit chlidren must be redistributed.

explicit children distribution If no includes attribute is specified on a content element, that content element will match on all content.
If no includes attribute is specified, a content element is considered generic and will match on all content, including text nodes, CDATA nodes, comments, and so on.

explicit children distribution If the includes attribute is specified on a content element, then only explicit children that match the selector specified by the value of includes apply to that content element.
If the includes attribute is specified, it must be interpreted as a selector, and only elements that match the selector apply to that content element.

explicit children distribution If the value of the includes attribute is an invalid selector, the content element does not match any explicit children.
If the selector is invalid, the content element is in error and does not match any nodes.

explicit children distribution Matching of the elements to the selector is done without taking into account the shadow tree in which the content element itself is found.
Matching of the elements to the selector is done without taking into account the shadow tree in which the content element itself is found. don't understand why this is explicit, needs better assertion

explicit children distribution, locked, main assertion If before distribution a node was assigned to a content element that was locked, then after re-distribution, that node is still assigned to the same content element and only that content element.
If the node is already assigned to a content element for this binding, and the content element is locked, then that is the content element to which the node must be assigned, stop here.

explicit children distribution, main assertion If a binding's shadow tree contains a valid content element that is not locked and whose includes attribute matches an explicit child, then the first such element in a a depth-first, pre-order traversal of the shadow template is the content element to which that explicit child is assigned and is the only such content element to which it is assigned.
If T contains a correct content element that is not locked and to which the node in question applies, then the first such element in a depth-first, pre-order traversal of the shadow tree T is the content element to which the node must be assigned, stop here.

explicit children distribution If an explicit child does not match any valid content element that is not locked and the shadow tree has no valid inherited element, then it does not appear in the final flattened tree.
Otherwise, if this binding has no correct inherited element in its shadow tree, then the node is not assigned to a content element, and does not appear in the final flattened tree; stop here.

explicit children distribution, inheritance If an explicit child does not match any valid content element that is not locked and the shadow tree has a valid inherited elemen but it is the least derived binding with a shadow tree, then it does not appear in the final flattened tree.
Otherwise, if the binding has a correct inherited element in its shadow tree but it is the least derived binding with a shadow tree, then the node is not assigned to a content element, and does not appear in the final flattened tree; stop here. def 'least derived binding' : http://www.w3.org/TR/xbl/#binding1

explicit children distribution, inheritance If an explicit child is not assigned to any content element in the shadow tree and there is a valid inherited element in the shadow tree, then it is assigned to the first content element in the inheritance chain that matches the criteria
Otherwise, let T be the shadow tree of the next most derived binding with a shadow tree and return to step 4. assertion needs better wording needs better assertion, and does implicit inheritance count? def 'inheritance chain': http://www.w3.org/TR/xbl/#binding1

explicit children distribution If two nodes are assigned to a content element, their order in the xblChildNodes list of the content element is the same as their relative order in the childNodes list of the bound element
The explicit children must be processed in order, so if two nodes are assigned to a content element, their order in the xblChildNodes list is the same as their relative order in the explicit children list.

explicit children distribution Explicit children are assigned to content elements when a shadow tree is generated.
A shadow tree is generated.

explicit children distribution Explicit children are assigned to content elements when a shadow tree is destroyed and the bound element still has bindings with shadow trees.
A shadow tree is destroyed and the bound element still has bindings with shadow trees.

explicit children distribution Explicit children are assigned to content elements when the bound element has explicit children added, removed, or moved.
The bound element has explicit children added, removed, or moved.

explicit children distribution Explicit children are assigned to content elements when a shadow tree is modified in a way that affects the relative order of content elements or their includes attributes.
A shadow tree is modified in a way that affects the relative order of content elements or their includes attributes.

explicit children distribution Explicit children are assigned when an includes attribute in the shadow tree is mutated.
An includes attribute in the shadow tree is mutated.

explicit children distribution Explicit children are assigned when one or more of the nodes assigned to a content element in a shadow tree no longer match the element's includes attribute.
One or more of the nodes assigned to a content element in a shadow tree no longer match the element's includes attribute.

explicit children distribution, locked A content element with locked set to true cannot accept new children unless they are explicitly assigned to it using the setInsertionPoint() method.
A locked content element cannot accept new children unless they are explicitly assigned to it using the setInsertionPoint() method

Final Flattened Tree

final flattened tree, main assertion The final flattened tree is rendered
Rendering must be performed using the final flattened tree

final flattened tree Nodes that do not appear in the final flattened tree are not rendered
Nodes that do not appear in the final flattened tree must not be rendered

final flattened tree, main assertion The final flattened tree consists of the child nodes of the most derived shadow tree's root template element, where content elements are replaced by the nodes that were assigned to them (or their child nodes if none were assigned), and where the first inherited element is replaced by the final flattened tree of the next most derived binding or, if there is no less-derived binding with a shadow tree, with the child nodes of the inherited element itself and subsequent inherited elements are replaced by their contents.one big assertion or the little ones below?

final flattened tree, main assertion The final flattened tree contains the child nodes (excepting content and inherited elements) of the most derived shadow tree's root template element.
Otherwise, replace the child nodes of the bound element with the child nodes of the most derived shadow tree's root template element. def 'least derived binding' : http://www.w3.org/TR/xbl/#binding1

final flattened tree In the final flattened tree, content nodes are replaced by the nodes that were assigned to them (or their child nodes if there were none assigned)
Replace any content elements in the shadow tree with the nodes that were assigned to them in the previous section, unless there are no such nodes, in which case replace them with their child nodes.

final flattened tree, inheritance In the final flattened tree, inherited elements are replaced by their contents if they are not the first inherited element in that shadow tree
Replace the second and subsequent inherited elements in the shadow tree with their child nodes.

final flattened tree, inheritance In the final flattened tree, the first inherited element is replaced by the final flattened tree of the next most derived binding, or, if there is no less-derived binding with a shadow tree, with the child nodes of the inherited element itself.
Replace the first inherited element in the shadow tree, if any, with the child nodes of the next most derived binding's shadow tree's root template element, or, if there is no less-derived binding with a shadow tree, with the child nodes of the inherited element itself.
If the previous step added a shadow tree to the flattened tree, then return to step 3 to deal with that newly added shadow tree.

CSS

styling, allow-selectors-through, shadow tree The selector 'A>B' does not match a shadow tree node if it's parentNode (or parentNode.parentNode if the node is a content or inherited node) is the root of the shadow tree but the binding's allow-selectors-through attribute is not true.
If "B" is in a shadow tree and "B.parentNode" is a content element or an inherited element, let "X" be "B.parentNode.parentNode", otherwise let "X" be "B.parentNode".
Now if "X" is the root of a shadow tree, but the binding's "allow-selectors-through" is not true, the selector doesn't match "B"

styling, allow-selectors-through, shadow tree, inheritance Otherwise, if "X" is the root of a shadow tree and the binding's "allow-selectors-through" is true and the binding is the bound element's most derived binding with a shadow tree, then let "X" be the bound element for which the shadow tree was generated. Otherwise, if "X" is the root of a shadow tree and the binding's "allow-selectors-through" is true but the binding is not the bound element's most derived binding with a shadow tree, then let "X" be the parent node of the inherited element into which the shadow tree was placed during the construction of the final flattened tree; if this is itself the root of a shadow tree, then repeat the steps described in this paragraph using that element as "X". Then, the selector matches "B" if the "X" element is the "A" element. need assertion

styling, shadow tree The selector "A B" matches a node if B if that node matches B and either "A>B" matches "B", or "C>B" matches "B" and "A C" matches "C".
A B Matches "B" if either "A>B" matches "B", or "C>B" matches "B" and "A C" matches "C".

styling, shadow tree The selector "A+B" does not match if "B" is in a shadow tree and "B.previousSibling" is a content element or an inherited element.
If "B" is in a shadow tree and "B.previousSibling" is a content element or an inherited element, the selector doesn't match "B".

styling, shadow tree The selector "A+B" matches "B" if "B.previousSibling" is "A" and "B.previousSibling" is not a content element or an inherited element .
otherwise, it matches if "B.previousSibling" is "A".

styling, shadow tree The selector "A~B" matches "B" if either "A+B" matches "B", or if "C+B" matches "B" and "A~C" matches "C".
Matches "B" if either "A+B" matches "B", or if "C+B" matches "B" and "A~C" matches "C".

styling, shadow tree Pseudo-classes and pseudo-elements are unchanged in the presence of XBL. They operate exclusively on the core DOM.
Pseudo-classes and pseudo-elements are unchanged in the presence of XBL. They operate exclusively on the core DOM. tricky, see example http://www.w3.org/TR/xbl/#selectors

styling, final flattened tree Elements inherit CSS properties from their parent node in the final flattened tree.
The final flattened tree determines how CSS properties (e.g., fonts and colors) are inherited. Elements must inherit from their parent node in the final flattened tree, regardless of what their DOM Core parent node is.

styling, final flattened tree, shadow tree Elements not in the final flattened tree have no computed style and are not rendered
Nodes that do not appear in the final flattened tree have no computed style (as if they were orphan nodes) and are not rendered.

styling, bound-element The :bound-element pseudo-class, when used from a binding, matches the bound element of that binding
The :bound-element pseudo-class, when used from a binding, must match the bound element of that binding

styling, bound-element The :bound-element pseudo-class, when used in a place other than a binding's style sheet or a content element's includes attribute, matches any bound element.
If the selector is used somewhere other than in a binding's style sheet (i.e. with a style element in XBL) or in a content element's includes attribute, then it must match any bound element.

xbl:pseudo

xbl:pseudo If the value of the tt>xbl:pseudo attribute is not "value", "choices", "label", "repeat-item", or "icon", then the attribute is ignored.
The allowed pseudo-elements are: ::value ... ::choices...::label...::repeat-item...::icon
The pseudo must be given without its leading double colon.
If the pseudo-element name is not recognized, it is in error and the UA must ignore the attribute. User agents must not automatically recognize any pseudo-element (as this will break forwards-compatibility).

xbl:pseudo, UA specific, optional If the value of xbl:pseudo on a shadow node is valid then that value is used to specify the name of the pseudo element to associate with that element.
xbl:pseudo attribute (in the XBL namespace) can be used to specify the name of the pseudo to associate with that element. details left up to UA , http://www.w3.org/TR/xbl/#matching

xbl:pseudo If an element has multiple nodes with the same xbl:pseudo pseudo-element, then they all match a relevant selector.
If an element has multiple nodes with the same pseudo-element, then they all match the relevant selector

xbl:pseudo, apply-author-sheets A shadow tree node matches a relevant selector by its pseudo-element even if the apply-author-sheets attribute of it's cooresponding template element is not true.
Matching of nodes based on their pseudo-element is unaffected by the apply-author-sheets attribute.

xml:base

shadow tree Relative xml:bases on nodes in shadow trees are resolved relative to their parentNode, or the ownerDocument if there is no parentNode.
Relative xml:bases on nodes in shadow trees are resolved relative to their parentNode, or the ownerDocument if there is no parentNode.

ids

shadow tree If an id is referenced in shadow content, then it is associated with the element of that id in that binding if there is an element with that id in the binding
IDs used in shadow content, as seen on XML Events nodes, in XHTML on the html:label element's for attribute, and in many other places, must be resolved in the context of the shadow scope and (failing that) the binding document, not the scope of the document into which the shadow content is inserted.

shadow tree If an id is referenced in shadow content and there is no element with that id in the binding, then it is associated with the element of that id in the binding document, if such an element exists. IDs used in shadow content, as seen on XML Events nodes, in XHTML on the html:label element's for attribute, and in many other places, must be resolved in the context of the shadow scope and (failing that) the binding document, not the scope of the document into which the shadow content is inserted.

script blocks

script script elements are evaluated in the context of the XBL subtree's document.
Therefore such elements must only be evaluated during initial parsing, in the context of the XBL subtree's document

attachment, script script elements are not evaluated during binding attachment.
Therefore such elements must only be evaluated during initial parsing, in the context of the XBL subtree's document, and not during binding attachment.

event handler blocks

event handling XML Events elements in the binding document result in event handlers being registered as event listeners on the nodes in the original bindings document
XML Events elements in the binding document must result in event handlers being registered as event listeners on the nodes in the original bindings document (including possibly the template node) as described in XML Events.

event handling If an XML Event is registered on a template element in the binding document and the template is cloned, the newly cloned even handlers cause new event listeners to be added to their new DOM Core parent nodes.
They may be included in shadow content templates, but when the shadow content template is cloned, the newly cloned event handlers must cause new event listeners to be added to their new DOM Core parent nodes needs better assertion

form controls

shadow tree Forms and form controls in shadow trees don't interact with form controls and form elements in the bound document.
Forms and form controls in shadow trees don't interact with form controls and form elements in the bound document. needs better assertion http://www.w3.org/TR/xbl/#html-forms

SVG

halp http://www.w3.org/TR/xbl/#svg

style sheets

styling, inheritance When a bound element has multiple bindings, the style sheets from each binding apply
When multiple bindings are applied to the same bound element, the sheets from each binding all contribute to the final set of style sheets to apply

styling, inheritance The style sheets of the most derived binding are walked first
the style sheets of the most derived binding being walked first does this imply something further, maybe assertion could say something about rules overriding other rules

styling Within a binding, sheets loaded with the xbl style element apply first, then sheets that are attached using the DOM or using <?xbl?> and author-level style sheets.
For each binding, the style sheets that apply are as follows, in the order given:
Scoped style sheets: A binding file can load style sheets using the style element...Author style sheets: While the apply-author-sheets attribute on the template element found at the root of the element's shadow tree is set to true, the rules specified in any author style sheets at outer shadow scopes (including those promoted to outer scopes using apply-binding-sheets, as defined below) must be applied to the shadow content...Style sheets used by bindings that are attached using the DOM or using <?xbl?> are treated as author-level sheets.

styling If the binding was attached using CSS, the scoped style sheets have the same CSS origin as the sheet with the rule responsible for the binding. If the binding was attached using CSS, the scoped style sheets have the same CSS origin as the sheet with the rule responsible for the binding

styling, main assertion, shadow tree Style sheets loaded with the style element are applied to the bound element and to all shadow content attached to the bound element.
These style sheets must be applied to the bound element and to all shadow content attached to the bound element.

styling When bindings from multiple levels are applied to the same bound element, the style sheets that apply cascade according to their own levels.When bindings from multiple levels are applied to the same bound element, the style sheets that apply must cascade according to their own levels.needs better assertion, see: http://www.w3.org/TR/xbl/#binding3

styling, apply-author-sheets, shadow tree When the apply-author-sheets attribute on the template element is true, the rules specified in any author style sheets at the outer shadow scopes (including those promoted to outer scopes using apply-binding-sheets) apply to the shadow tree.
While the apply-author-sheets attribute on the template element found at the root of the element's shadow tree is set to true, the rules specified in any author style sheets at outer shadow scopes (including those promoted to outer scopes using apply-binding-sheets, as defined below) must be applied to the shadow content.

styling, apply-author-sheets, shadow tree When the apply-author-sheets attribute on the template element is not true, only style rules matched through predefined pseudo-elements are applied to the shadow content.
Otherwise, only those matched through predefined pseudo-elements are used, and other author-level sheets in higher shadow scopes must not be applied to the shadow content.

styling The style sheets in higher shadow scopes always apply to the bound element.
(The bound element is always styled using the sheets of higher shadow scopes.)

styling style sheets specified in bindings do not apply to content other than the bound element or its shadow tree
By default, style sheets specified in bindings (as described above) are applied only to shadow content generated by bindings attached to the bound element and to the bound element itself possible duplicate with assertion above

styling, apply-binding-sheets, shadow tree When the apply-binding-sheets attribute on a content element is true then any nodes that are assigned to that element, and any descendants of those nodes, have the scoped style sheets of the binding (those that apply to the shadow content) applied to them too.
A second attribute, apply-binding-sheets, can be used to indicate that all descendants of the bound element, both shadow and explicit, can be styled by the sheets in the binding's document. This can be controlled on a per-insertion-point basis. While this attribute is set to true on a content node in the shadow tree DOM, any nodes that are assigned to that element, and any descendants of those nodes, must have the scoped style sheets of the binding (those that apply to the shadow content as described above) applied to them too, as if they had been promoted to the higher scope.

styling, shadow tree, shadow scope Style rules specified in inner shadow scopes are overridden by rules of equal specificity in outer shadow scopes
Sheets within each origin are always walked from the innermost shadow scope to the outermost shadow scope (with rules in the outermost shadow scope therefore overriding rules of equal specificity in the innermost shadow scope) def 'inner shadow scope' http://www.w3.org/TR/xbl/#shadow9

styling, inheritance On a bound element with multiple bindings, style rules specified in a more base binding are overridden by rules of equal specificity in an more derived binding.
For multiple bindings attached to the same element, the sheets are walked from the base binding to the most derived binding.

styling User agent style sheets and user style sheets are applied to all shadow content.
User agent style sheets and user style sheets: These are always applied to all shadow scopes.

attachment Infinite loops where an author style sheet binds an element to a binding, and that binding sets the binding to none or another binding don't prevent users from interacting with the user agent.
Since styles from both author style sheets and binding style sheets are applied to the bound element, it is possible for an infinite loop to form where an author sets the 'binding' property to a particular binding that then explicitly sets the 'binding' property to 'none' (or another binding)...In so far as XBL is concerned, authors must avoid constructing such loops, and implementers must ensure that such loops do not prevent users from interacting with the user agent. can this be tested?

attachment Infinite loops where a binding constructor calls removeBinding() and the binding's detachment listener re-attaches the binding don't prevent the user for interacting with the user agent.
This specification does not take any precautions to avoid this, any more than it takes precautions to avoid loops caused by binding constructors explicitly calling removeBinding() to remove the binding itself and binding detachment event handlers reattaching the bindings.
In so far as XBL is concerned, authors must avoid constructing such loops, and implementers must ensure that such loops do not prevent users from interacting with the user agent. can this be tested?

Implementation

implementation, xblBindingAttached If the implementation object of a binding element has a method xblBindingAttached() defined, that method is called after the binding is attached on the bound element.
The xblBindingAttached() method is called by the user agent after the binding has been attached. def 'implementation object' http://www.w3.org/TR/xbl/#binding4

implementation, xblEnteredDocument, shadow scope If the implementation object of a binding element has a method xblEnteredDocument() defined then that method is called when the bound element or one of its ancestors, or one of the elements in a higher shadow scope, is inserted into the document.
The xblEnteredDocument() method is called by the user agent in two cases:...When the bound element, or one of its ancestors, or one of the elements in a higher shadow scope, is inserted into the document.

implementation, xblEnteredDocument If the implementation object of a binding element has a method xblEnteredDocument() defined then that method is called when the binding is attached if the bound element is already in the document.
The xblEnteredDocument() method is called by the user agent in two cases:...When the binding is originally attached, if the bound element is already in the document.

implementation, xblLeftDocument If the implementation object of a binding element has a method xblLeftDocument() defined, then that method is called when the bound element or one of its ancestors is removed from the document.
The xblLeftDocument() method is called by the user agent when the bound element, or one of its ancestors, or one of the elements in a higher shadow scope, is removed from the document.

implementation, xblEnteredDocument, xblLeftDocument, xblBindingAttached If xblBindingAttached(), xblEnteredDocument(), or xblLeftDocument() is not defined on the implementation object, then nothing should happen when that method is invoked.
If the implementation does not define one of these methods, then when that method is invoked, nothing must happen (as if all bindings had default implementations of those methods that were no-ops).

implementation, xblImplementations The xblImplementations attribute on all elements returns an instance of an XBLImplementationList object (the same object for the lifetime of the element), which is a live list of the implementation objects provided by the bindings for that bound element at any particular point in time.
The xblImplementations attribute on all elements must return an instance of an XBLImplementationList object (the same object for the lifetime of the element), which is a live list of the implementation objects provided by the bindings for that bound element at any particular point in time.

implementation, xblImplementations The object returned by xblImplementations has a member length which returns the number of implementation objects associated with the bound element, or zero if the the element is not a bound element or if none of its bindings have implementations.
The length attribute must return the number of implementation objects associated with the bound element, or zero if the element is not a bound element or has none of its bindings have implementations.

implementation, xblImplementations The object returned by xblImplementations has a member item(n) the nth implementation object associated with the bound element - ordered from most base to most derived binding.
The item(n) method must return the nth implementation object associated with the bound element.
The list must be ordered such that the most derived binding is last, and the base binding has index zero.

implementation, xblImplementations If the item(n) method is invoked on an object returned by xblImplementations with an number not between zero and length - 1, then an INDEX_SIZE_ERR DOM exception is raised.
If the index is not a number between zero and length-1 (inclusive), then the method must raise an INDEX_SIZE_ERR DOM exception.

js implementation

js, implementation, xblImplementations Objects returned by xblImplementations have a getter method that when invoked with a property name that is a number, acts like the item() method would when invoked with that argument.
In ECMAScript implementations, objects that implement the XBLImplementationList interface must also have a Get method that, when invoked with a property name that is a number, acts like the item() method would when invoked with that argument. needs better assertion - tie in item() functionality

js, implementation, xblImplementations, main assertion Any attempt to access a member of an element that does not coorespond to a method or property on the object itself but do coorespond to the member of one or more of the implementations on the xblImplementations list is forwarded to the last implementation in the xblImplementations list that is so matched.
in languages that support dynamic dispatch (such as ECMAScript), any attempts to access members of ElementXBL objects that do not correspond to methods or properties on the object itself but do correspond to members of one of the objects in the xblImplementations list must be forwarded to the last object in the xblImplementations list that is so matched.

js, implementation The first implementation element is used to create the implementation prototype object for the binding.
The first implementation element child of the binding element must have its code compiled and run (see below). The return value of that script, if it is an object, must be forever associated with that binding element as that binding's implementation prototype object.

js, implementation, implementation prototype If a binding element doesn't contain an implementation element or it's implementation element does not evaluate to an object, then the binding's implementation prototype object is an empty object.
Otherwise, if the binding element doesn't contain an implementation element, or if it does but it does not evaluate to an object, then an empty object must be created (by invoking the Object constructor in the global scope of the binding document), and the binding element's implementation prototype object must be forever set to that object.

js, implementation, implementation prototype Any change to the implementation element after assigning to the implementation prototype object will have no effect on the implementation prototype object.
Any further changes to implementation elements will have no effect on the implementation prototype object of this particular binding.

js The prototype property of the internal object must be set to the external object
The Prototype property of the internal object must be set to the external object def 'external object' : http://www.w3.org/TR/xbl/#ecmascript

js, implementation prototype The prototype property of the external object must be set to the binding's implementation prototype object.
the Prototype property of the external object must be set to the binding's implementation prototype object.

js The internal object has the field external defined and is a reference to the external object.
The internal object must then have the following fields defined: This field's value must be set to a reference to the external object.

js The internal object has the field boundElement defined and it is a reference to the bound element.
This field's value must be set to a reference of the node object that is the bound element.

js The internal object has the field shadowTree defined and it is set to null before shadow content generation.

js The internal object has the field baseBinding defined and if the binding's extends attribute caused another binding to be attached to the bound element, then the baseBinding field is a reference to that binding's implementation object, otherwise it is set to null
If the binding's extends attribute caused another binding to be attached to the bound element, then the baseBinding field's value must be set to a reference of that binding's implementation object, if it has one (if that is an ECMAScript implementation as well, then that is that binding's external object). Otherwise, it must be set to the value null.

js When a function of an implementation object is called, this is a reference to the internal object associated with the external object on which the function was invoked.
When function code of an implementation object implemented in ECMAScript is called, the user agent must set the this value to the internal object associated with the external object on which the function was invoked.

Events

event handling, main assertion When an event passes through a bound element, whether during the capture, target, bubble, or default phases, any appropriate event listener attached to the binding's first handlers element is invoked.
Whenever an event passes through a bound element, whether during the capture, target, bubble, or default phases, the user agent must also invoke any appropriate event listeners attached to the binding's first handlers element.

event handling In the capture phase, a handler attached to the (first) handlers element fires after an event handler on the bound element itself fires.
When events are forwarded in this manner, the event handlers attached to the handlers element must fire after any event handlers on the bound element itself in the capture phase

event handling A handler attached to the handlers element fires after the event has been retargeted to shadow nodes.
after the event has been retargeted to shadow nodes, if appropriate be more explicit about when this happens, needs better assertion

event handling In the target and bubble phases, an event handler on the handlers element fires before any event handler on the bound element itself.
before any event handlers on the bound element itself in the target and bubble phases

event handling A handler attached to the handlers element fires before the event is retargeted to the bound element.
before the event has been retargeted to the bound element, if appropriate. be more explicit about when this happens in assertion, needs better assertion

event handling, inheritance Event handlers fire first on the most derived binding and then on its inherited binding, continuing all the way up the chains to the base binding
Event handlers must fire first on the most derived binding and then on its inherited binding, continuing all the way up the chains to the base binding

event handling, inheritance An event handler of a binding will not fire if the event handler of a more derived binding called the stopImmediatePropogation() method.
A derived handler then has a way of preventing the event from flowing to the handlers of the bindings it inherits from, by using the stopImmediatePropagation() method.

event handling, addEventListner, optional event handlers may be attached to the handlers by calling the addEventListener() method on the handlers element.
Event handlers may be attached to the handlers element using any method, including DOM3 Events' addEventListener() method.

event handling When the event or phase attribute of an handler element changes, or whenever a handler element's parent changes, any previous listener that was registered for that handler is removed and a new listener is registered on the element's parent element, if it has one.
Whenever the event or phase attributes of an XBL handler element change, or whenever a handler element's parent changes, an event listener must be registered on the element's parent element, if it has one; and if an event listener had previously been registered for that handler element, it must be removed.

missing - 'a handler element registers a handler on its parent element' - http://www.w3.org/TR/xbl/#registering is this an xml thing?

event handling If the event attribute of a handler is missing or its value is the empty string, it is ignored.
If the event attribute is missing or its value is the empty string, it is in error.

event handling If the phase attribute is present but has a value other than the literal strings capture, target, bubble, or default-action, it is ignored.
If the phase attribute is present but has a value other than the literal strings capture, target, bubble, or default-action, it is in error.

event handling, js The script content of the handler element is run in the context of the binding document
The script must be run in the context of the binding document (and not, e.g., in the bound document's context*). unless they are the same

event handling If the propagate attribute is specified on a handler element and its value is stop, then the event does not propagate after the handlers of the current node have been fired.
If stop is specified, then after the event handler has been fired, the event's stopPropagation() method must be called. inferring the result of calling stop propogation

event handling If the default-action attribute is specified on a handler and its value is cancel, then the default action for the event is not performed.
If cancel is specified, then after the event handler has been fired, the event's preventDefault() method must be called. inferring result of preventDefault

js, event handling, implementation object When the code of a handler is executed, this refers to the internal implementation object of the binding with which the handler is associated.
When a script of a handler element implemented in ECMAScript is executed the user agent must set the this value to the internal object part of the implementation object of the binding with which the handler element is associated

js, event handling, assumption When the code of a handler is executed, event refers to the Event object representing the event.
The script must be executed as a function body with one argument, called event, which is a reference to the Event object representing the event. Will probably assume this for a bunch of tests anyways

js, event handlingThe code executed when a handler is called reflects the current contents of the handler element.
The script must be compiled and executed each time it is accessed, so that any dynamic changes to the event handler code in the binding document take effect.

filters

event handling, filters, trusted If the trusted attribute of a handler is specified and its value is true, any event whose trusted attribute is not true won't fire the handler.
The trusted attribute is a filter that, if set to the value true, matches only events whose trusted attribute is true.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, phase If the phase attribute of the handler is specified and its value is capture, any event whose eventPhase attribute does not have the value CAPTURING_PHASE, then the handler does not fire.
If the attribute has the value capture, it must only match events whose eventPhase attribute has the value CAPTURING_PHASE
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, phase If the phase attribute of the handler is specified and its value is target, any event whose eventPhase attribute does not have the value AT_TARGET, then the handler does not fire.
If the attribute has the value target, it must only match events whose eventPhase attribute has the value AT_TARGET
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, phase If the phase attribute of the handler is specified and its value is default-action, any event whose eventPhase attribute does not have the value 0x78626C44, then the handler does not fire.
If the attribute has the value default-action, it must only match events whose eventPhase attribute has the value 0x78626C44 (2019716164).
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, phase If the phase attribute of the handler is specified and its value is anything other than default-action, target, or 0x78626C44, then any event whose eventPhase attribute does not have the value BUBBLE_PHASE, then the handler does not fire
If it is specified and has another value, it must only match events whose eventPhase attribute has the value BUBBLE_PHASE
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, phase If the phase attribute is not specified then an event whose eventPhase attribute does not have the value AT_TARGET or BUBBLE_PHASE does not invoke the listener for this handler.
If it is not specified, it must only match events whose eventPhase attribute has the value AT_TARGET (2) or BUBBLE_PHASE (3)
If any of them fail to match the event, then the invocation must not do anything else.

event handling, button If the event is a MouseEvent and the handler's button attribute is specified and the button attribute of the event does not match one of the values in the space-separated list of the handler's button attribute, then the handler does not fire.
A list of values, at least one of which has to match the button attribute on the event object for the XBL event handler to fire. If the attribute is not specified, then any value of the button attribute on the event object must be considered a match. If the value is specified, it must be a space-separated list of values, each of which must be one or more digits in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9). Each string must be interpreted as a base ten integer and then compared to the value of the button attribute on the event object. If none of the values match the button attribute, then the event handler must not be executed.

event handling, click-count If the event is a MouseEvent and the handler's click-count attribute is specified and the detail attribute of the event does not match one of the values in the space-separated list of the handler's click-count attribute, then the handler does not fire.
A list of values, at least one of which has to match the detail attribute on the event object for the XBL event handler to fire. If the attribute is not specified, then any value of the detail attribute on the event object must be considered a match. If the value is specified, it must be a space-separated list of values, each of which must be one or more digits in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9). Each string must be interpreted as a base ten integer and then compared to the value of the detail attribute on the event object. If none of the values match the detail attribute, then the event handler must not be executed.

event handling, key If the event is a KeyboardEvent and the key attribute of the handler is specified and the value of the keyIdentifier attribute of the event does not exactly match its value, then the handler does not fire.
If specified, the value must be an exact literal match of the keyIdentifier attribute of the event object. For example, Enter.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, key-location If the event is a KeyboardEvent and the key-location attribute of the handler this attribute's value must be a space-separated list of values from the four literal (case-sensitive) keywords standard, left, right, and numpad (with no duplicates), which map to the DOM values 0x00, 0x01, 0x02, or 0x03 respectively.
If specified, this attribute's value must be a space-separated list of values from the four literal (case-sensitive) keywords standard, left, right, and numpad (with no duplicates), which map to the DOM values 0x00, 0x01, 0x02, or 0x03 respectively. If specified, the event object's keyLocation attribute must have a value equal to the numeric value of one of the specified keywords.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, key-loaction If the value of key-location contains an item other than standard, left, right, and numpad or contains a duplicate item, then that item is ignored.
Unknown and duplicate values are in error and UAs must ignore them (although without dropping any correct values).

event handling, filters, text If the event is a TextEvent and the text attribute of the handler is specified and its value is not equal to the value of the event's data attribute, then the handler is not fired.
The text data to match. If specified, the value must be an exact literal match of the data attribute of the event object.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, prev-value If the event is a MutationEvent and the prev-value attribute of the handler is specified and does not equal the value of the event's prevValue attribute, then the handler is not fired.
If specified, the value must be an exact literal match of the prevValue attribute of the event object.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, new-value If the event is a MutationEvent and the new-value attribute of the handler is specified and does not equal the value of the event's newValue attribute, then the handler is not fired.
If specified, the value must be an exact literal match of the newValue attribute of the event object.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, attr-name If the event is a MutationEvent and the attr-name attribute of the handler is specified and does not equal the value of the event's attrName attribute, then the handler is not fired.
If specified, the value must be an exact literal match of the attrName attribute of the event object. The value of the attribute may be any string.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, attr-change If the event is a MutationEvent and the attr-change attribute of the handler is specified , this attribute's value must be a space-separated list of values from the three literal (case-sensitive) keywords modification, addition, removal (with no duplicates), which map to the DOM values 0x00, 0x01, or 0x02 respectively. If specified, the event object's attrChange attribute must have a value equal to the numeric value of one of the specified keywords, otherwise the handler is not fired.
If specified, this attribute's value must be a space-separated list of values from the three literal (case-sensitive) keywords modification, addition, removal (with no duplicates), which map to the DOM values 0x00, 0x01, or 0x02 respectively. If specified, the event object's attrChange attribute must have a value equal to the numeric value of one of the specified keywords.
If any of them fail to match the event, then the invocation must not do anything else.

event handling, filters, attr-change If the value of attr-change contains an item other than modification, addition, or removal or contains a duplicate item, then that item is ignored.
Unknown and duplicate values are in error and the UA must ignore them, although without causing correct values to be dropped.

event handling, filters, modifiers If the event is a KeyboardEvent or a MouseEvent and the modifiers attribute is specified and any item from getModifierState() method of the event is not accounted for by the modifiers attribute or one of the values made the filter fail, then the handler is not fired. See http://www.w3.org/TR/xbl/#modifiers for details on what modifiers are accounted for and which ones make the filter fail
The filter matches if all the modifiers that returned true are accounted for, and none of the values made the filter fail.
If any of them fail to match the event, then the invocation must not do anything else.

shadow content

event handling, shadow tree, shadow scope, target A UI event* originating from a shadow tree node passes through ancestors in the next highest shadow scope with target set to the bound element that contains that shadow tree.
Whenever events originating from a shadow tree flow from a shadow element in that shadow tree to the bound element, one of two actions occurs. Either the event is retargeted so that the bound element becomes the target, or the event is stopped and flow proceeds to the next phase. Whenever an event is retargeted, the event is cloned, with the clone's target field set to the bound element...The action taken (retarget vs. stop) is specific to the event type. In general, UI events must be retargeted and mutation events must be stopped
The target node, when the event is passing through a node at a higher shadow scope than the event target, is always the bound element in whose shadow content the event target lies. focus/blur and mouseover/out events have a special case

event handling, shadow tree, shadow scope A mutation event originating from a shadow tree node does not pass through ancestors in a higher shadow scope.
Whenever events originating from a shadow tree flow from a shadow element in that shadow tree to the bound element, one of two actions occurs. Either the event is retargeted so that the bound element becomes the target, or the event is stopped and flow proceeds to the next phase. Whenever an event is retargeted, the event is cloned, with the clone's target field set to the bound element...The action taken (retarget vs. stop) is specific to the event type. In general, UI events must be retargeted and mutation events must be stopped

event handling, shadow tree, target An event originating from a shadow tree node passes through its bound element with target set to the bound element
The target node, when the event is passing through a node at a higher shadow scope than the event target, is always the bound element in whose shadow content the event target lies
The bound element itself is in the shadow scope of the content around it

event handling, shadow tree, phase An event originating from a shadow tree node passes through its bound element only in the target phase.
When an event is retargetted at a bound element, the bound element's event handlers must see the event only in the target phase

event handling, shadow tree, target An event originating from a shadow tree node passes through the handlers element of the binding with target set to the target shadow tree node.
The timing of event retargeting is such that when the event is forwarded to the handlers element, the binding's handlers see the relevant shadow tree node as the target, rather than the bound element as the target.

event handling An event fired on a bound element's explicit child bubbles into the element containing the content element the element was assigned to.
an event fired on a bound element's explicit child bubbles into the element containing the content element the element was assigned to.

'event handling, shadow scope Any method invocations on any clones of the event object are forwarded to the original event and all the clones.
Any method invocations on any clones of the event object must also be forwarded to the original event and all the clones, so that attempts to stop propagation and cancel the default action affect the event regardless of how many scopes it has crossed. this implies more...needs better assertion

event handling, phase If an event bubbles through or is targeted at one or more bound elements, and the event is not canceled after the capture, target, and bubble phases have all completed, then the event's eventPhase attribute is set to the value 2019716164, and then the event is be forwarded to the relevant handlers elements of all the bound elements the event bubbled through or was targeted at in those bubble and target phases, in reverse tree order (starting from the target node and walking the tree towards the Document node), with currentTarget set to the relevant bound element each time.
If an event bubbles through or is targeted at one or more bound elements, and the event is not canceled (after the capture, target, and bubble phases have all completed, its defaultPrevented attribute is still false), then the event's eventPhase attribute must be set to the value 0x78626C44 (2019716164), and then the event must be forwarded to the relevant handlers elements of all the bound elements the event bubbled through or was targeted at in those bubble and target phases, in reverse tree order (starting from the target node and walking the tree towards the Document node), with currentTarget set to the relevant bound element each time

event handling If an event bubbles through or is targeted at one or more bound elements, then the UA default action (if any) is performed only if the defaultPrevented attribute is false after the capture, target, bubble, and default phases.
If the event has a UA default action, it must only perform it if the defaultPrevented attribute is still false after it has been so forwarded.

event handling, phase The stopPropagation() method has no effect during the default phase on the handlers element.
The stopPropagation() and stopImmediatePropagation() methods must have no effect during this "default" phase.

event handling, phase, inheritance If a default phase handler of the handlers element calls stopImmediatePropagation() it does not stop any other valid default phase handlers from firing.
The stopPropagation() and stopImmediatePropagation() methods must have no effect during this "default" phase.

event handling, shadow tree If shadow content underneath a focusable bound element loses focus and shadow content also underneath the bound element takes focus, then the cooresponding focus, blur, DOMFocusIn, and DOMFocusOut events do not pass through ancestors in a higher shadow scope.
If shadow content underneath a focusable bound element loses focus and shadow content also underneath the bound element takes focus, then both focus change events must be stopped.

event handling, shadow tree If shadow content underneath a focusable bound element loses focus and shadow content also underneath the bound element takes focus, then the bound element retains focus throughout the two events.
As far as the bound element is concerned, it retains focus throughout the two events.

nav-index, shadow tree, shadow scope The nav-index values used in one shadow scope are ignored by other shadow scopes.
The 'nav-index' values used in one shadow scope are ignored by other shadow scopes.

nav-index, shadow tree, shadow scope The tab order specified by the nav-index attributes of shadow tree nodes of the shadow tree is used in place of the tab order of the bound element in the bound element's tree.
Each shadow scope has a unique tab order. ... The tab order is resolved in the shadow tree first to produce a list of elements in the tab order. This list is substituted in place of the bound element in the bound element's tree tab order.

shadow scope, focus The :focus psuedo-element applies to every shadow node in the shadow scope chain from the original target of the focus event to the bound element in the highest shadow scope*.
Because content in multiple shadow scopes can be focused, the CSS :focus pseudo-element is hierarchical in the presence of XBL, with up to one element in each shadow scope matching the pseudo-class. might be assuming too much from the spec here...does 'up to one' mean 'either one from each or none from each scope'?, needs better assertion

event handling, shadow scope If the mouse moves out of an element in the shadow tree onto an another element also underneath the bound element, then the cooresponding mouseover and mouseout events do not pass through ancestors in a higher shadow scope.
If, however, the user has simply moved the pointing device from one element in the shadow tree to another element in the same shadow tree, without entering or exiting the bound element itself, then the event must be stopped.

Attachment/Detachment

attachment An element is bound after the binding document is loaded, the binding is known to apply to the element, and the element has been created.
Bindings must be attached as soon as the following conditions have all been met:...it is known that the binding applies to the element,...the DOM Element object for the element has been created, and...the binding document defining the binding has loaded. In particular, binding can happen before the element is inserted into its document.
If the binding document was already loaded when the element was created, or when it became known that the element matched the binding (e.g. because the binding's element attribute is mutated in a script), then the binding must be applied such that to any running scripts, notwithstanding those implementing xblBindingAttached()* notification methods, it appears that the binding was applied immediately why

attachment If the mutation of an element causes a binding to apply, the mutation events associated with that mutation fire after the binding is applied.
When mutation events are to fire, they must fire after the binding being applied.

detachment Bindings must be detached as soon as it is known that the binding no longer applies to the element
Bindings must be detached as soon as it is known that the binding no longer applies to the element...When it becomes known that a binding is to be detached, it must happen such that to any running scripts it appears that the binding was removed immediately,

detachment If a script detaches a binding from within xblBindingAttached() or xblEnteredDocument(), or a handler for xbl-bound then the binding is detached after all these methods have been called
If a binding stops applying to a document while the above steps are being applied, the binding is not removed until after the steps above have all been completed. Once they have been completed, any bindings that no longer apply must be detached. assuming this is what the spec means, what is the motivating use case?

bindings-are-ready

attachment, xbl-bindings-are-readyThe xbl-bindings-are-ready event is fired at the bound document's root if the bound document has finished loading, the bindings-are-ready counter is set to zero, all bindings have been applied to the bound document, and no scripts are running.
If the bound document is being parsed by the user agent, then, as soon as all the following conditions have been met, the user agent must fire an xbl-bindings-are-ready event on the document's root element. The conditions are: the document has finished parsing...the bindings-are-ready counter is at zero...all bindings that are known to apply to elements have been completely applied, and...no scripts are running. might be hard to pin down this state test-wise

xbl-bindings-are-readyThe xbl-bindings-are-ready event bubbles.
must bubble

xbl-bindings-are-ready The xbl-bindings-are-ready event is not cancelable.
must not be cancelable

xbl-bindings-are-ready The xbl-bindings-are-ready event does not have a default action.
and must not have a default action.

bindings-are-ready The bindings-are-ready attribute is initially zero.
Initially, the bindings-are-ready counter must be set to zero.

xbl-bindings-are-ready The bound document's xbl-bindings-are-ready event fires before the document's load event.
The bound document's load event must not fire until after the xbl-bindings-are-ready event has fired

xbl-bindings-are-ready The xbl-bindings-are-ready event fires even in the complete absence of any use of XBL in the document.
The xbl-bindings-are-ready event must fire even in the complete absence of any use of XBL in the document.

xbl-bindings-are-ready The xbl-bindings-are-ready event is only fired once per document load.
The xbl-bindings-are-ready event must only fire once per document load.

<?xbl?>

loading binding document If an <?xbl> processing instruction occurs after the root element's start tag in the document, then it is ignored.
<?xbl?> processing instructions that occur after the root element's start tag in the markup are in error
If a processing instruction is in error (as described in the previous few paragraphs) then it must be ignored.

loading binding document If an <?xbl> processing instruction is inserted into the DOM after the start tag has been parsed or the root element has been attached to the document, then it is ignored.
PIs that are dynamically inserted through the DOM after the root element's start tag has been parsed or the root element has been attached to the document are in error too.
If a processing instruction is in error (as described in the previous few paragraphs) then it must be ignored.

loading binding document If an <?xbl> processing instruction has a parsing error, it is ignored.
If there are any parse errors, then the entire processing instruction is in error.
If a processing instruction is in error (as described in the previous few paragraphs) then it must be ignored.

loading binding document If the href pseudo-attribute of <?xbl> cannot be resolved, or returns an error, or does not point to a resource with an XML MIME type, or has any other problem that makes it unusable then it is ignored.
If the URI cannot be resolved, or returns an error, or does not point to a resource with an XML MIME type, or has any other problem that makes it unusable, then the processing instruction is in error.
If a processing instruction is in error (as described in the previous few paragraphs) then it must be ignored.

loading binding document, main assertion If the href pseudo-attribute of <?xbl> is specified and it is valid, then the document refrenced by href is loaded unless it has already been loaded *. Any bindings defined by that document are applied to matching elements in the document that contained the PI.
Otherwise, the referenced document must be loaded (unless it has already been loaded), and any bindings defined by that document must be applied to matching elements in the document that contained the PI 'unless it has already been loaded' specified by: http://www.w3.org/TR/xbl/#binding5

loading binding document, bindingDocuments After a document is loaded from a <?xbl>, the document is in the bindingDocuments list of the document with the PI.
Once loaded, the binding document is added to the bindingDocuments list of the document with the PI. another assertion may cover this

loading binding document An imported binding document is live.
An imported binding document is live...For example, if new binding elements are added to an imported binding document (via the DOM), then the new bindings are immediately applied to the document that had the PI importing that binding document. another assertion may cover this

attachment An xbl binding applies to the document in which it is defined
XBL bindings are always implicitly imported into the document in which they are defined.

loading binding document, bindings-are-ready When a document is loading from an <?xbl?>, the document's bindings-are-ready counter is increased by one.
Whenever an <?xbl?> PI causes a binding document to be loaded, the document's* bindings-are-ready counter must be increased by one which document, both of them?

loading binding document, bindings-are-ready When a document has finished loading from an <?xbl?>, the document's bindings-are-ready counter is decreased by one.
Once the binding document is loaded, the counter must be decreased by one.

loading binding document If a file imports some bindings and the file containing those bindings has its own <?xbl?> processing instructions, that second PI only affects nodes in the binding document, not the original document.
If a file imports some bindings and the file containing those bindings has its own <?xbl?> processing instructions, that second PI only affects nodes in the binding document, not the original document.

binding CSS property

attachment, CSS binding A binding attached through the CSS binding property only remains on the bound element as long as the element continues to match the style rule.
Bindings attached through CSS must only remain on the bound element as long as the element continues to match the style rule.

detachment, CSS binding, inheritance If at any time a resolution of style on the element determines that a different binding should be attached, the old binding (and all bindings that it explicitly extends in its explicit inheritance chain) is detached.
If at any time a resolution of style on the element determines that a different binding should be attached, the old binding (and all bindings that it explicitly extends in its explicit inheritance chain) must be detached.

detachment, CSS binding Whenever an element is removed from a document, any bindings attached to that element via CSS are detached.
Whenever an element is removed from a document, any bindings attached to that element via CSS must be detached.

loading binding document, CSS binding Attaching a binding using CSS binding does not import the binding document.
Attaching a binding using CSS does not import the binding document. The element attributes of binding elements in the binding document do not take effect unless the binding document is imported.

bindings-are-ready, CSS binding Attaching using CSS binding does not affect the bindings-are-ready counter.
Attaching using CSS does not affect the bindings-are-ready counter.

CSS binding If the value of the CSS binding property is none, then no bindings are applied by CSS to an element matching the style rule.
No bindings are to be attached through CSS.

CSS binding, main assertion If the value of the CSS binding property is one or more URIs then the binding associated with each uri is attached, a binding earlier in the list is applied before a uri later in the list and a uri later in the list implicitly inherits from a binding later in the list.
The specified binding is attached. More than one binding can be specified, resulting in the bindings being attached in the specified order, with the last binding implicitly inheriting from the previous one, and so forth, up to the first binding.

addBinding

attachment, addBinding, inheritance When a binding is attached using the addBinding method, it inherits from the current most derived binding that is already attached to the element.
When a binding is attached using the DOM, it inherits from the current most derived binding that is already attached to the element not really a testable assertion by itself

attachment, detachment, addBinding Any bindings attached to an element using the addBinding() method will remain on the element until the element is destroyed or a corresponding removeBinding() call is made.
Any bindings attached to an element using the addBinding() method will remain on the element until the element is destroyed or a corresponding removeBinding() call is made.

attachment, loading binding document Attaching a binding using the addBinding() method does not import the binding document.
Attaching a binding using the addBinding() DOM APIs does not import the binding document

attachment, bindings-are-ready Attaching using the addBinding() method does not affect the bindings-are-ready counter.
Attaching using the addBinding() API does not affect the bindings-are-ready counter.

attachment

attachment, inheritance If a binding has an extends attribute, then the binding it references is attached first
If the binding has an extends attribute, then the user agent must immediately consider the binding that the attributes references (if any) to apply to the bound element as well, and must attach that binding first, recursively applying these steps to that binding how can we test without using xblBindingAttached? - shadow tree generation, handlers, or implementation perhaps?

attachement, inheritance if a binding directly or indirectly derives from itself through a chain of one or more extends attributes — each binding in the chain applies only once
if a binding directly or indirectly derives from itself through a chain of one or more extends attributes — then the user agent must only apply each binding in the chain once

attachment, xblEnteredDocument, xblBindingAttached When an attachment causes other binding attachments, the order that bindings on different bound elements have xblEnteredDocument() and xblBindingAttached() called is the relative tree order of all their bound elements, as returned by the compareDocumentPosition() function
The order that bindings on different bound elements have these methods called must be the relative tree order of all their bound elements, as returned by the compareDocumentPosition() function assertion could use better wording

attachment, inheritance, xblBindingAttached, xblEnteredDocument When an attachment causes other binding attachments, The order that bindings on the same bound element have xblBindingAttached and xblEnteredDocument called is the derivation order, with less derived bindings being initialized before more derived bindings.
The order that bindings on the same bound element have these methods called must be the derivation order, with less derived bindings being initialized before more derived bindings.

attachemnt, xbl-bound After attachment and the xblBindingAttached() and xblEnteredDocument() methods are called, an xbl-bound event is fired on bound element that just got bound, in the same order as their xblBindingAttached() methods were invoked.
After all the appropriate methods have been called, an xbl-bound event that bubbles, is not cancelable, has no default action, and uses the Event interface, must be fired on every bound element that just got bound, in the same order as their xblBindingAttached() methods were invoked.

attachment, xbl-bound The xbl-bound event bubbles.
an xbl-bound event that bubbles, is not cancelable, has no default action,

attachment, xbl-bound The xbl-bound event is not cancelable.
an xbl-bound event that bubbles, is not cancelable, has no default action

attachment, xbl-bound The xbl-bound event has no default action.
an xbl-bound event that bubbles, is not cancelable, has no default action

attachment, detachment' If a binding stops applying to a document while a binding is being attached, the binding is not removed until after attachment has been completed. Once it is completed, any bindings that no longer apply are detached.
If a binding stops applying to a document while the above steps are being applied, the binding is not removed until after the steps above have all been completed. Once they have been completed, any bindings that no longer apply must be detached.

attachment, xblEnteredDocument, xblLeftDocument If the xblEnteredDocument() and xblLeftDocument() methods are invoked due to a mutation, these methods are invoked after any associated mutation events fire.
These methods must be invoked as soon as the DOM is in a stable state, after any mutation events have fired

attachment, xblEnteredDocument, xblLeftDocument The xblEnteredDocument() and xblLeftDocument() methods are not invoked if a bound element is both removed then re-inserted into the document during the same script execution.
If a bound element is removed and then reinserted into a document (or vice versa) during script execution, or while mutation events are being fired, the user agent must coalesce all the notifications into zero or one method calls.

attachment The bound document does not fire its load event until all XBL dependencies have loaded
The bound document must wait until all XBL dependencies have loaded before firing its load event. what does this imply exactly and how could we test this?

attachment, loading binding document When a binding is added and the relevant binding document is not yet loaded, the load is started in the background and the binding only attached once the binding document is available
when a binding is added (either via style sheet, script, or some other method), and the relevant binding document is not yet loaded, the load must be started in the background and the binding only attached once the binding document is available how could we test this?

Inheritance

a lot of definitions used in other assertions http://www.w3.org/TR/xbl/#binding1 might be able to get some assertions for this, but inheritence doesn't mean much w/o context of events or explicit child distribution, etc.

Detachment

detachment, xblLeftDocument When a binding is detached, the xblLeftDocument() method is invoked.
When a binding is detached, the xblLeftDocument() method must be invoked on the binding's implementation

detachment, shadow tree When a binding is detached, its shadow tree is removed.
Then, the shadow tree must be removed an assertion may already cover this

detachment, xblImplementations When a binding is detached, its implementation is removed from the xblImplementations list of the bound element.
the implementation must be removed from the bound element's list of binding implementations an assertion may already cover this

detachment, event handling When a binding is detached, any forwarding of events to the binding is stopped for this bound element.
and any forwarding of events to the binding must be stopped for this bound element.

detachment, inheritance When a binding is detached, if it had an extends attribute when it was bound to the element, then the binding attached due to that attribute is detached.
If the binding had an extends attribute when it was bound to the element (it may have changed since then, in which case the binding is being detached precisely for that reason), then the user agent must then detach the binding that was attached because of that attribute (if any).

detachment, explicit children distribution When a binding is detached, if the binding had a shadow tree, the explicit children of the bound element are redistributed.
If the binding had a shadow tree, the explicit children must then be redistributed. (See: processing content elements.) an assertion might already cover this

DOM

DocumentXBL

bindingDocuments The bindingDocuments attribute returns a NamedNodeMap of all the binding documents loaded by the document.
The bindingDocuments attribute must return a NamedNodeMap of all the binding documents loaded by the document. Documents are referenced using their URIs as the node names, with null namespaces.

bindingDocuments The value returned by bindingDocuments is a live NamedNodeMap.
The NamedNodeMap must be live expand on 'live', needs better assertion

bindingDocuments Any attempt to modify the bindingDocuments attribute raises a NO_MODIFICATION_ALLOWED_ERR
and must raise NO_MODIFICATION_ALLOWED_ERR on any attempts at modification or deletion.

loading binding document, loadBindingDocument, main assertion The loadBindingDocument method synchronously loads the specified binding document and any binding documents required by that document by explicit inheritance and applies any appropriate bindings to the document implementing the loadBindingDocument method.
The loadBindingDocument method must synchronously load the specified binding document (unless it has already been loaded), as well as any binding documents that are required by that binding document due to explicit inheritance, and any bindings defined by that document must be applied to matching elements in the document that corresponds to this DocumentXBL object.

loading binding document, loadBindingDocument If the loadBindingDocument method is successful, it returns the binding document's Document object.
The method must then return the binding document's Document object.

loading binding document, loadBindingDocument If the loadBindingDocument method fails, it returns null.
If the load fails, this method must return null.

ElementXBL

attachment, addBinding, inheritance, main assertion The addBinding method attaches the specified binding to the element the method was called on.
The addBinding method must attach the specified binding (and any bindings that the binding inherits from) to the element. This call is not necessarily synchronous. The binding may not be attached yet when the call completes. not synchronous, how could we test this?

attachment, addBinding Calling the addBinding method on a node that is not an element raises a HIERARCHY_REQUEST_ERR
This exception must be raised if the node is not an element.

detachment, removeBinding, inheritance The removeBinding method detaches the specified binding (and any bindings that the binding inherits from explicitly using the extends attribute) from the element it was called on.
The removeBinding method must detach the specified binding (and any bindings that the binding inherits from explicitly using the extends attribute) from the element

detachment, removeBinding, addBinding If the removeBinding specifies a binding that was not bound with addBinding, then removeBinding does nothing.
This method can only detach bindings that were attached using addBinding. If the binding in question is not attached to this element (or was attached through another attachment mechanism) then the method must do nothing.

hasBinding The hasBinding method returns true if the specified URI matches the URI of a binding applied to the element, and returns false otherwise.
The hasBinding method must check the bindings applied to the element and compares each binding's URI with the parameter passed. If any of the bindings matches the specified URI, then the method must return true, otherwise it must return false.

shadow content accessibility

shadow tree Shadow content is not accessible via the childNodes list for the bound element.
The shadow content is not accessible via the childNodes list for the bound element

shadow tree Shadow content is not accessible using firstChild or nextSibling to iterate over the children of the bound element.
nor is it accessible using firstChild/nextSibling to iterate over the children of the bound element

shadow scope, shadow treeDOM methods that can be invoked on elements will only see nodes that are in the same shadow scope.
DOM methods that can be invoked on elements (e.g., getElementsByTagName()) will only see nodes that are in the same shadow scope

shadow tree Methods invoked on the document only see nodes that are not in shadow trees.
Methods invoked on the document (e.g., getElementById) only see nodes that are not in shadow trees.

shadow tree, shadow scope Ids need to be unique within each shadow scope.
Elements in different shadow scopes may have clashing IDs. IDs need only be unique within each shadow scope.

shadow tree Inserting the root of a shadow tree into a document raises a HIERARCHY_REQUEST_ERR.
Elements that are the root of a shadow tree (the cloned template elements) cannot be inserted into a document. Any attempt to do so must raise a HIERARCHY_REQUEST_ERR.

shadow tree, final flattened tree, mutating binding document Mutating the DOM of the template causes the final flattened tree on bound elements to be immediately updated.
Manipulating the DOM of a shadow tree (content elements being moved about or even removed altogether, xbl:attr attributes being attached and modified, etc) must immediately cause the final flattened tree to be updated.

shadow tree Mutating the shadow tree of a bound element does not effect any other shadow trees.
Because each bound element gets its own copy of the cloned template, changes to a bound element's shadow content only affect that bound element. Other bindings are unaffected.

shadow scope If an element is added to the DOM dynamically, its shadow scope is that of its parent element.
If an element is added to the DOM dynamically, its shadow scope is that of its parent element. more of a definition?

explicit children distribution Adding an element as a child of a bound element causes that element to be assigned to an appropriate content element.
Adding an element as a child of a bound element causes that element to be assigned to an appropriate content element another assertion may cover this

XBLContentElement

The xblChildNodes attribute of a content element returns a NodeList containing a live list of all the nodes that are currently assigned to the content element.
The xblChildNodes attribute must return a NodeList containing a live list of all the nodes that are currently assigned to the content element.

If a content element is not in a shadow tree, the xblChildNodes attribute returns null.
if the content element is not in a shadow tree, then this attribute must return null.

If the setInsertionPoint method is called with a parameter that is not the child of the bound element, then a HIERARCHY_REQUEST_ERR exception is raised.
The user agent must then check that the parent of child is in fact e. If it is not, then the method must raise an HIERARCHY_REQUEST_ERR exception.

If the setInsertionPoint method is called on a content element with no bound element, an INVALID_STATE_ERR exception is raised.
If there is no such bound element (e.g. the content element has been removed from its shadow tree), then the method must raise an INVALID_STATE_ERR exception.

If the setInsertionPoint method is called on a content element and the element's includes attribute does not match the argument to setInsertionPoint, then an TYPE_MISMATCH_ERR is raised.
If the attribute is present but the element does not match the selector it specifies (or if the selector is not syntactically correct), then the method must raise an TYPE_MISMATCH_ERR exception.

If the setInsertionPoint method is called on a content element and the element has no includes attribute or the argument to setInsertionPoint is an element that matches the selector specified by the value of includes, then the argument element is assigned to that content element, and unassigned from any content element it was previously assigned to.
Finally, the user agent must assign child to the content element, instead of whatever previous content element it was assigned to, if any.

If a node is assigned, using the setInsertionPoint method, to a content element that is not locked, then the element will only remain there until such time as the user agent redistributes the bound element's explicit children.
If a node is assigned, using the setInsertionPoint method, to a content element that is not locked, then the element will only remain there until such time as the user agent redistributes the bound element's explicit children. covered by another assertion, but good to have explicit testcase for this

The order of nodes assigned to a content element is always be the same as the relative order of those nodes in the original core DOM.
The order of nodes assigned to a content element is always be the same as the relative order of those nodes in the original core DOM.

XBLTemplateElement

The getElementById method of a template element returns an Element that has an ID attribute with the specified value and is a descendant of the template element.
This method must return an Element that has an ID attribute with the given value, and that is a descendant of the template element on which it is invoked

If the getElementById method is called on a template element and there is no descendant of the template element that has the specified id, then null is returned.
If no such element exists, this returns null.

EventXBL

The trusted attribute of an event is true if the user agent dispatched the event.
The trusted attribute must return true if the user agent dispatched the event (e.g. in response to user action)

The trusted attribute of an event is false if the user agent did not dispatch the event.
and false otherwise (e.g. if an author script dispatched a synthetic event).

Events fired by the user agent in response to untrusted events are themselved untrusted.
Events fired by the user agent in response to untrusted events must themselves be untrusted.

Resources

Nested documents and images with bindings do not share a reference to the same binding document.Such sharing of binding documents must be limited to binding documents loaded by a document, its binding documents, its scripts, and its style sheets. Nested documents and images do not share binding documents with each other or with their container document.

script

If a script or implementation object specifies a src attribute, the contents of that element are ignored.
In the case of script and implementation elements, if a src attribute is present then the contents of the element must be ignored (even if fetching the specified URI fails).

All descendant elements of script, implementation, or handler elements are processed before the XBL script block itself is executed.
All descendant elements must be processed, though, according to their semantics, before the XBL script block itself is executed.

If a script element specifies a src attribute, the resource specified by the attribute is fetched and any pending binding attachments from the same document are blocked as well as the evaluation of any other script blocks.when the element is evaluated, the resource specified by the src attribute must be fetched. For script elements, while an external script is being fetched, any pending binding attachments from the same binding document must block, as must the evaluation of any further script blocks.

If an implementation element specifies a src attribute, the resource specified by the attribute is fetched and the attachment of that binding blocks until the script has been fetched and executed.
For implementation elements, while the external script is being fetched, the attachment of that binding must block.

If a script specified by the src attribute on a script or implementation has a Content-Type other than the type specified on the xbl element's script-type attribute or the default, then it is ignored.
For implementation elements, while the external script is being fetched, the attachment of that binding must block an assertion may already cover this

Script in a binding is exectued in the context of the global scope of the document specified by the element's ownerDocument attribute.
Script must always be executed in the context of the global script scope of the document specified by the script's element's ownerDocument DOM attribute. This implies that scripts from different bindings in the same binding document bound to different elements in the same bound document share the same scripting scope. If the bindings were defined in the document itself, then the scope is the same scope as for that document.

A binding document inherits the security context of the document to which it is bound, not the security context of the domain from which it was fetched.
A binding document must inherit the security context of the document to which it is bound, not the security context of the domain from which it was fetched.

In binding documents, the location and history properties of the Window object, and the location and cookie properties of the DocumentWindow object return nullIn binding documents, the location and history properties of the Window object, and the location and cookie properties of the DocumentWindow object, must return null unless the binding document is the bound document

style

If a style element's src attribute is present, then the contents of the element are ignored.
If a style element's src attribute is present, the contents of the element must be ignored (even if fetching the specified URI failed)

If a style element's src attribute is not specified, then the element's contents are applied to the bindings.
XBL style elements describe the style sheets that apply to bindings...Otherwise, it is the element's contents that give the style sheet.

All descendant elements of the style are processed according to their semantics, before the XBL style block itself is parsed.
All descendant elements must be processed, though, according to their semantics, before the XBL style block itself is parsed.

For non-XML styling languages, if the content is inline, UAs must concatenate all the textual contents of text and CDATA child nodes, and the UA must ignore any other, non-text nodes (such as elements and comments) along with all their children.
For non-XML styling languages, if the content is inline, UAs must concatenate all the textual contents of text and CDATA child nodes, and the UA must ignore any other, non-text nodes (such as elements and comments) along with all their children

A style element labeled as containing a style sheet in a non-XML language yet containing element nodes is ignored.
A style element labeled as containing a style sheet in a non-XML language yet containing element nodes is in error.

If the content was in another resource, and the Content-Type (or equivalent for non-HTTP protocols), if any, was of the type specified on the xbl element (or implied by its absence), then the contents of that file must be used directly.

The src attribute of a style element is only examined once all of the element's children have been processed (if any).
The src attribute must only be examined once all of the element's children have been processed (if any).

binding URIs

If the URI used to specify a binding contains a fragment identifier that is not a binding element in an xbl as an ancestor, then it is ignored and that binding is not attached.
If the URI contains a fragment identifier, then it must be processed as described in the relevant MIME type definition. The element targeted by the fragment identifier must be a binding element within an XBL subtree in the specified document
When an attachment mechanism uses a URI that is in error (as per the last two paragraphs), then the user agent must act as if the attachment mechanism had not specified that binding.

If the URI used to specify a binding does not contain a fragment identifier and the URI points to an XBL document then the first binding element in the binding that is a child of the root xbl element is attached to the appropriate element.
If there is no fragment identifier and the URI points to an XBL document (not a non-XBL document) then the first binding element in the binding document that is a child of the root xbl element is selected. Otherwise, the URI does not point to a correct binding and is in error.
Otherwise, the specified binding is attached to the element, as described for the relevant attachment mechanism.

elements in namespace

xbl

If an xbl element is in a non-xbl document and it is the child of another element in the xbl namespace or the child of an element that does not allow an xbl child, then it is ignored.
Expected contexts:..In an XBL document, none (this is the root element)...In a non-XBL document, any non-XBL element whose specification allows the xbl element as a child.
When an XBL element is found inside an element other than those listed under the "Expected contexts" list in the definitions below, it is in error
being in error means that the UA must, for the purposes of XBL evaluation, treat the XBL subtree as it would if the erroneous node and all its descendants were not present in the DOM.

If an element in the xbl namespace other than binding or script is the child of an xbl element, then it is ignored.
Expected children (in any order):...binding: zero or more...script: zero or more...Any non-XBL element.
When an XBL element has a child node that does not satisfy the "Expected children" list in its definition (for instance because it is the wrong node type, wrong element type, or because too many elements of its type preceded it), the child is in error

An xbl element with another xbl element as its ancestor is ignored.UAs must consider any xbl elements that have another xbl element as an ancestor as being in error and must then ignore them, meaning those elements must never be considered to declare any bindings.
UAs must consider any xbl elements that have another xbl element as an ancestor as being in error and must then ignore them, meaning those elements must never be considered to declare any bindings.

An element in the xbl namespace that does not have a correct xbl ancestor is ignored.
XBL elements (other than the xbl element itself) that do not have a correct xbl element as an ancestor are in error too, and UAs must ignore them.

If the style-type attribute is specified on an xbl element, and its value is a supported MIME type, then that is the styling language used by all bindings specified by that xbl element.
The style-type attribute specifies the MIME type of the styling language used by all bindings and XBL style blocks in the XBL subtree. The value must be a valid MIME type.

If the value of the style-type attribute is not specified, the styling language for all bindings of that xbl element is CSS.
If the attribute is not specified, the default language is CSS

If the value of the style-type attribute of an xbl element is not supported, then the bindings are still applied.
If the UA does not support the specified styling language (or has styling disabled), it must still apply bindings as appropriate.

If the value of the style-type attribute of an xbl element is not supported, then style blocks are ignored.
only style blocks must be ignored.

If the script-type attribute is specified and is a supported MIME type, then that is the scripting language used by all bindings and scripts in that xbl element.
The script-type attribute specifies the MIME type of the scripting language used by all bindings and XBL script blocks in the XBL subtree. The value must be a valid MIME type

If the value of the script-type attribute is not a supported language, then the bindings are still applied
if the UA does not support the specified scripting language (or has scripting disabled), it must still apply bindings as appropriate

If the value of the script-type attribute is not a supported language, then script, implementation, and handler blocks are ignored.
if the UA does not support the specified scripting language (or has scripting disabled)...only script, handler and implementation sections must be ignored.

binding

If a binding element is not a child of an xbl element then it is ignored.
Expected context: xbl

If a binding element has a child in the xbl namespace other than implementation, template, handlers, or resources then the child is ignored.
Expected children (in any order): implementation: zero or one. template: zero or one. handlers: zero or one. resources: zero or one. Any non-XBL element

If the extends attribute does not refer to another binding, then the attribute is ignored.
If the URI is in error or does not refer to another binding, the UA must ignore it, meaning that this binding does not explicitly inherit from another binding.

If an element attribute is specified, it is interpreted as a selector and any elements (other than the binding's own shadow template elements) in the binding document, and in any documents that import the binding document, that match the given selector, are bound to the binding defined by this binding element.
This attribute, if specified, must contain a selector. All elements in the binding document, and in any documents that import the binding document, that match the given selector, must be bound to the binding defined by this binding element. (The element's own shadow tree, if any, must not be taken into account when determining if it matches a selector for the purposes of this attribute.)

If an element attribute contains an invalid selector, the attribute is ignored.
If an element attribute contains an invalid selector, it is in error and must be ignored, meaning that while the binding is still parsed and may be referenced using other attachment mechanisms, the binding is not attached to any element by its element attribute, as if the attribute had simply been omitted.

implementation

If an implementation element is not the child of a binding element, then it is ignored.
Expected context:...binding

If the src attribute is specified on an implementation element, then its contents are ignored.
The src attribute specifies the URI to a resource of the type given by the XBL subtree's script-type attribute. If the attribute is specified, the contents of the element must be ignored

If the src attribute specifies a resource that is unavailable then it is not used as an implementation definition for any binding.
if the implementation element points (using the src attribute) to a resource that is either unavailable...the UA must ignore it. In both cases, "ignoring it" means it must not be used as an implementation definition for any binding.

If the src attribute specifies a resource that is not of the type specified by the script-type attribute of the xbl element, then it is not used as an implementation definition for any binding.
or not of the type specified by the script-type attribute of the xbl element (or implied by its absence)...the UA must ignore it. In both cases, "ignoring it" means it must not be used as an implementation definition for any binding.

implementation blocks are evaluated once, on first use.
implementation blocks are evaluated once, on first use.

implementation block has no effect after the element has been evaluated.
Changes to an implementation element or its contents have no effect once the element has been evaluated.

template

If the template element does not have a binding element as a parent, then it is ignored.
Expected context:...binding

If the apply-author-sheets attribute of a template is not specified, or its value is not true, or false, then CSS rules from the bound document's author style sheets do not apply to shadow tree content.
The default behavior, which is used when the attribute is omitted or has a value other than the two allowed values, is to not apply the bound document's author style sheets (same as false)

If the apply-selectors-through attribute of a template is not trueor false or it is not specified, then CSS selectors do not cross shadow scopes.
The default behavior, which is used when the attribute is omitted or has a value other than the two allowed values, is to not let selectors cross scopes (same as false).

content

If a content element does not have a correct template element as an ancestor, then it is ignored.
Expected context:...there must be a correct template element somewhere in the ancestor chain

If a content element has another content element in its ancestor chain, then the descendant content element is ignored.
Expected context:...there must not be any content elements anywhere in the ancestor chain.

If the value of apply-binding-sheets is not true or if the attribute is not specified, then scoped style sheets loaded for this binding are not applied to explicit children assigned to this content element.
Its value must be either true (indicating that they are) or false (indicating that they are not). The default behavior, which is used when the attribute is omitted or has a value other than the two allowed values, is that they are not applied (same as false)

If the locked attribute is not specified or its value is not true, then new children can be inserted into this content element when it processed.
The default behavior, which is used when the attribute is omitted or has a value other than the two allowed values, is that they may be inserted (same as false)

Elements assigned to a content element whose locked attribute is dynamically changed are not removed from that element.
Elements already assigned to a content element whose locked attribute is dynamically changed are not removed from that element.

inherited

If an inherited element does not have a correct template element as an ancestor, then it is ignored.
Expected context:...Any, but there must be a correct template element somewhere in the ancestor chain.

xbl:attr

If an element with an xbl:attr does not have a correct template element as its ancestor, then it is ignored.

Expected element:...Any, but there must be a correct template element somewhere in the ancestor chain.

xbl:pseudo

If an element with an xbl:pseudo attribute does not have a correct template element as an ancestor, then it is ignored.

Expected element: Any, but there must be a correct template element somewhere in the ancestor chain.

div

If a div element is not the child of a template, content, inherited, or div element, then it is ignored.
Expected contexts: template...content...inherited...div

handlers

If a handlers element is not the child of a binding element, then it is ignored.
Expected context:...binding

If a handlers element has a child that is not a handler element, then that child is ignored.
Expected children:...handler: zero or more.

handler

If a handler is not a child of a handlers element, then it is ignored.
Expected context:...handlers

If the value of the phase attribute of a handler is capture, the event handler is only fired during the capturing phase of event propogation.
If capture is specified, then the event handler must only be fired during the capturing phase of event propagation

If the value of the phase attribute of a handler is target, then the event handler only fires during the target phase.
If target is specified, then the event handler must only be fired during the target phase.

If the value of the phase attribute of a handler is default-action, the event handler is only fired during the default phase if it occurs.
If default-action is specified, then the event handler must only be fired during the default phase (if it occurs)

If the value of the phase attribute of a handler is not specified or its value is bubble, then the handler only fires during the bubble phase.
Otherwise, the handler must only be fired during the bubbling phase

If the trusted attribute is not specified or value of the trusted attribute is not true, then the value of the event's trusted flag does not affect the handler.
Otherwise, the value of the trusted flag does not affect the event handler.

The value of the propogate attribute of a handler has no effect if the phase attribute has the value default-action.
It has no effect if the phase attribute has the value default-action

If a handler element is in a language that is not supported by the script-type attribute on the xbl element(or the default, if this attribute is not specified), then it is not used for the event handler definitions of any binding..
If a handler element is marked (via the script-type attribute of the xbl element) as being in a language that the UA does not support then the UA must ignore it

A change to a handler element takes effect the next time the event handler is fired.
handler blocks are evaluated each time they are fired. Changes to the handler elements therefore take effect the next time the event is fired.

resources

If a resources element does not have a binding as a parent, then it is ignored.
Expected context:...binding

If a resources element has a child other than a style or prefetch element, then the child is ignored.
Expected children (in any order):style: zero or more...prefetch: zero or more.

style

If a style element does not have a resources element as its parent, then it is ignored.
Expected context:...resources

If the media attribute of a style element is not specified, then there is no restriction on which media the style sheet is applied to.
If this attribute is not specified, then there is no restriction on which media the style sheet should be applied to (same as specifying media="all")

The media attribute is interpreted as a Media Query.
How the value of this attribute is interpreted is defined by Media Queries

If the src attribute of a style element is specified, the contents of the element are ignored.
If the attribute is specified, the contents of the element must be ignored (even if the resource could not be fetched or was of the wrong type).

If the src attribute points to a resource that is unavailable, then that style element is not used to style anything.
Similarly, if the style element points (using the src attribute) to a resource that is either unavailable, or not of the type specified by the style-type attribute of the xbl element (or implied by its absence), then it is in error and the UA must ignore it. In both cases, "ignoring it" means it must not be used to style anything.

If the src attribute points to a resource that is not of the type specified by the style-type of the xbl element (or of the type "text/css" if it is not specified), then that style element is not used to style anything.
or not of the type specified by the style-type attribute of the xbl element (or implied by its absence), then it is in error and the UA must ignore it. In both cases, "ignoring it" means it must not be used to style anything.

prefetch

If a prefetch element is the child of an element other than a resources element, then it is ignored.
Expected context:...resources

prefetch can be used to list resources that may be pre-loaded for performance reasons and its support is optional, may want tests for this

script

If a script element is the child of something other than an xbl element, then it is ignored.

If the src attribute is specified on a script element, then the contents of the element are ignored.
If the attribute is specified, the contents of the element must be ignored (even if the resource could not be fetched or was of the wrong type).

If the src attribute points to a resource that is unavailable, then then it must not be executed.
if the script element points (using the src attribute) to a resource that is either unavailable, then it is in error and the UA must ignore it. In both cases, "ignoring it" means that the script must not be executed.

If the src attribute points to a resource that is not of the type specified by the script-type attribute of the xbl element, then the script is not executed.
or not of the type specified by the script-type attribute of the xbl element (or implied by its absence), then it is in error and the UA must ignore it. In both cases, "ignoring it" means that the script must not be executed.

A script element is evaluated once on first parse or first insertion into the document.
script blocks must be evaluated when their end-tag is parsed, or, for dynamically created elements, when they are first inserted into a document. This is the case whether or not the elements are in error

Any change to a script element's content or attributes is have no effect.
Once evaluation has started, a script block is dead and changes to its contents or attributes have no effect.

id

If the value of the id attribute of an xbl element is the empty string, then no ID is set on the element.
If the attribute's value is the empty string, the attribute must not set an ID

If the value of the id attribute of an xbl element is specified and is not the empty string, then it is used as one of the element's IDs.
Otherwise, the attribute's value must be treated as (one of) the element's ID(s).

User:Harthur/XBL2/TestableAssertions

The Shadow Tree

Template element

Destruction

xbl:attr

content

Final Flattened Tree

CSS

xbl:pseudo

xml:base

ids

script blocks

event handler blocks

form controls

SVG

style sheets

Implementation

js implementation

Events

filters

shadow content

Attachment/Detachment

bindings-are-ready

<?xbl?>

binding CSS property

addBinding

attachment

Inheritance

Detachment

DOM

DocumentXBL

ElementXBL

shadow content accessibility

XBLContentElement

XBLTemplateElement

EventXBL

Resources

script

style

binding URIs

elements in namespace

xbl

binding

implementation

template

content

inherited

xbl:attr

xbl:pseudo

div

handlers

handler

resources

style

prefetch

script

id

Navigation menu

Search