XBL Task Force Issue: Includes attribute syntax

<svg:text ...><xbl:content/></svg:text>

This is how all the widgets in Firefox are implemented.

4.1.2 Arguments in favor

Arguments in favor of this proposal:

• Selectors are designed to be fast, which is critical for the XBL use case since shadow trees may need to be recomputed whenever the DOM changes.
• Selectors are designed for exactly this purpose: Given a node, they can tell you if it matches a selector or not. This is the model we need for XBL: for each child node of the bound element, we want to go through each of the insertion points and decide whether or not the node matches, and drop the node in the first matching insertion point. (See also counter-arguments to XPath proposal.)
• This is the selector language that Web browsers have already implemented, and thus it would be extremely cheap to re-use it in Web browser implementations of XBL.
• Using other languages would require redundant code that implements the same basic principle in different ways. On mobile devices we don't have room for redundant code.
• W3C Selectors is a mature language with a rich heritage, and is the modern standard for deciding if a node matches a condition.
• W3C Selectors is much more widely deployed than XPath. A huge portion of existing Web content is based on CSS, which uses W3C Selectors.
• W3C Selectors are well-understood by the Web authoring community.
• The use of Selectors will provide spec consistency across the W3C between XBL and CSS' similar feature (deciding if a style rule applies to an element).
• W3C Selectors offers greater long-term flexibility than XPath because Selectors syntax has a well-defined forward- and backward- compatibility model, allowing for flexibility in the face of future extensions.
• Selectors have an extension model that is carefully designed so that proprietary and experimental extensions are easy and can be made in a haphazard way without risk of clashing with the standards, while keeping all such extensions very clearly marked as such so that authors and UA implementors always know that such extensions are not "sanctioned". This means authors are not misled into thinking that the features they are using will interoperate widely when in fact they are using vendor-specific features.

4.1.3 Arguments against

Arguments against using CSS selectors:

• See the arguments in favor of XPath Subset, such as how other standards and initiatives are embracing XPath instead of CSS selectors, how XPath has a more modern heritage, and how XPath offers a better long-term migration path.
• CSS (and therefore CSS selectors) is an optional feature within some XBL language scenarios. For example, SVG Tiny 1.1 and 1.2 do not support CSS at all, and even for SVG Full CSS is an optional feature. On the other hand, SVG has already embraced a subset approach to XPath for URI referencing.
• The "nth-child" feature that is part of the CSS Selector proposal is not part of CSS2. It is only available in CSS3's Selector module, which has been a Candidate Recommendation since November 2001. This seems like a frivolous and unnecessary dependency.
• Namespaced element selection is a requirement in this modern day of namespaces. The compromise CSS Selector proposal does not support namespaces. The full CSS Selector proposal has two main down-sides: (a) funky CSS syntax for namespace prefixing using a vertical bar (i.e., foo|bar instead of foo:bar), and (b) the requirement that binding documents must include a CSS stylesheet in order to define the namespace prefix used by the selectors, which means that anyone who implements sXBL must also implement at least a subset of CSS stylesheet parsing just to understand the namespace prefix.

4.2 Proposal: Use XPath Subset (Bound element children only)

4.2.1 Proposal

Another proposal is to use a highly restricted subset of XPath, the expression language that originated from XSL in 1999. The normative reference for all of XPath 1.0 is:

• XPath 1.0

The proposed subset of XPath would match what was defined in RCC for its 'select' attribute on <refContent>:

• The select attribute defines an XPath selector for the node set that should be connected here. Only a small subset of XPath is allowed: "*", "qname", "*[#]", "qname[#]" where name is any identifier and # is a number

A key feature that offers XBL component developers important flexibility is the "*[#]" option. With this feature, it is possible for a component to analyze the content model of the custom element and use script to set the 'includes' attribute to point to a particular child element which was identified by scripting logic. For example, suppose the custom element is allowed to look like this:

<myNS:SkinnableWidget>
  <myNS:DropShadowSkin state="normal">...</myNS:DropShadowSkin>
  <myNS:DropShadowSkin state="hover">...</myNS:DropShadowSkin>
  <myNS:DropShadowSkin state="mousedown">...</myNS:DropShadowSkin>
  <myNS:BackgroundSkin state="normal">...</myNS:BackgroundSkin>
  <myNS:BackgroundSkin state="hover">...</myNS:BackgroundSkin>
  <myNS:BackgroundSkin state="mousedown">...</myNS:BackgroundSkin>
  <myNS:ToolTipSkin state="normal">...</myNS:ToolTipSkin>
  <myNS:ToolTipSkin state="hover">...</myNS:ToolTipSkin>
  <myNS:ToolTipSkin state="mousedown">...</myNS:ToolTipSkin>
</myNS:SkinnableWidget>

The xblShadowTree might contain the following:

<xbl:shadowTree>
  <xbl:content includes="...ordinal reference to drop shadow skin..." />
  <xbl:content includes="...ordinal reference to background skin..." />
  <g display="none">
    <xbl:content includes="...ordinal reference to tooltip skin..." />
  </g>
</xbl:shadowTree>

The component would respond to events and change the value of the 'includes' attribute based on the current interaction state for the given widget. When no tooltip is shown and the widget is in a "normal view" state, then script would set the 'includes' attribute on the <xbl:content> elements to point to the relevant child elements by ordinal position within the custom element using "*[#]" syntax. For example, to reference the first child element, you would say includes="*[1]". This critical bit of flexibility when using fully encapsulated components is not available by tagname or ID matching.

4.2.2 Arguments in favor

Arguments for using a subset of XPath:

• XPath is the modern standard for referencing nodes within an Infoset. CSS selectors were defined (Rec in 1996) before XML happened (Rec in 1998). Since XPath was defined, many newer W3C standards have based themselves on XPath (XSLT, XQuery, XForms, DOM3 [in terms of DOM3 XPath]) whereas no W3C standards have chosen to based themselves on CSS selector syntax for referencing nodes within an Infoset. Within industry, major industry XML initiatives have embraced XPath APIs such as Java and .NET, whereas these environments have not embraced CSS.
• The use of XPath will provide spec consistency across the W3C between XBL and XSLT's similar feature: <xslt:apply-templates select="...xpath...">.
• XPath offers greater long-term flexibility than CSS selectors because XPath offers ability to reference any type of node, including text nodes, whereas CSS only can address element nodes. XPath includes an extensibility mechanism in the form of add-on function libraries which might be useful in the future for extra flexibility for use with the 'includes' attribute.
• The parsing logic to implement the proposed subset is a trivial programming effort, probably taking less time than it would take to read this document. The parsing logic is trivial enough that it could be implemented easily in ECMAScript.

4.2.3 Arguments against

Counter-arguments against proposals involving XPath:

• XPath does more than we need. For example, we would have to define how to handle XPath expressions that don't return node sets.
• XPath doesn't use the model we need. In XPath, you don't start with a single element, and decide whether or not it matches; you start with a node in a tree, and return all the other nodes in the tree that match a particular expression. In terms of XBL, this would mean we would have to define what happens when an insertion point tries to insert a node set with nodes that are not children of the bound element.

  It must be emphasized that this has a major effect on future extensibility. In particular, extending beyond the XPath "Step" production seems highly difficult, whereas extending to full selectors support (given an implementation of selectors) is trivial. This is because the operation we want to perform (determining whether each child is included or not) matches the model of selectors perfectly, but does not match the model of XPath. In other words, we're looking for a function that, given a value for the includes attribute, maps an element (one of the children) to a boolean (included or not included). Selectors performs exactly that mapping (selector * node in tree → boolean). XPath performs a mapping (expression * node in tree → list of nodes), which is not the function we want.

• XBL's use case differs quite substantially from the places where XForms, XSLT, XPointer, etc, use XPath. In XSLT, XForms, and XPointer, XPath is used as a way to find a node in a document. In XBL, we already have the node, what we want to know is which insertion point the node should be placed in.
• XPath is not familiar to the majority of Web authors.
• XPath's extension model leads to different UAs having different sets of functionality, which in an XBL context would cause bindings to act differently in different UAs.
• XPath has no defined error handling logic and no forwards-compatibility story.
• XPath is an entirely missing feature within some XBL language scenarios. For example, HTML and CSS or DOM2 do not support XPath at all, and not all browsers support XPath. On the other hand, Web browsers have already embraced CSS and its selector syntax across the board. XPath therefore seems like a frivolous and unnecessary dependency.
• Path's extension model is such that anyone can create extensions. However, standard extensions (e.g. XForms extensions) are not clearly differentiable from non-standard extensions (e.g. Mozilla extensions), meaning that authors and UA implementors will be easily misled into using extensions that have no likelihood of interoperability. A similar effect can be seen on the Web today: authors often use DOM extensions that Microsoft invented, because they are indistinguishable from standard, official extensions to the DOM.
• See the arguments in favor of W3C Selectors, such as how W3C Selectors are designed to be fast compared to XPath, how XPath has a more mature heritage, and how W3C Selectors offers a better long-term migration path.

4.3 Proposal: Use XPath Subset (Any descendants of bound element)

4.3.1 Proposal

Another proposal is a variation on the XPath proposal which would allow the XPath subset to reference any nodes under the bound element, not just child nodes. With this variation, allowable XPath expressions would be extended to allow the shorthand "/" syntax to represent a child axis and the "text()" syntax to allow selection of text nodes. For example, "a/b/text()" would be supported and would select all text nodes that are child nodes of b and grandchild nodes of a.

Additional rules would be added such that it would not be possible for one <xbl:content> element to reference a descendant node and then another <xbl:content> element to reference one of the ancestor elements of that descendant node. Here are proposed rules to achieve this:

• <xbl:content> matching is performed in document order within xblShadowTree
• Once an <xbl:content> element matches against an descendant element E of a bound element, all descendant nodes and ancestor nodes of E within the subtree of the bound element are unavailable for matching against other <xbl:content> elements

This extra flexibility is particularly useful for implementing XForms user interface controls. For example, suppose you want to implement the following <xforms:input> element using XBL with a shadow tree of SVG:

<xforms:input ref="...">
  <xforms:label>First name</xforms:label>
</xforms:input>

This extra flexibility allows the binding to use <xbl:content> on the text node for the label element as follows:

<svg:text x=... y=...><xbl:content includes="xforms:label/text()"/></svg:text>

Note that in some cases there is a way to use recursive XBL to satisfy the ability to apply XBL to nested child elements (such as in the <xforms:label> example above). However, this recursive approach is not a generally robust facility and can fall apart when child elements appear in multiple different contexts and require different shadow trees for each context. In the particular case of <xforms:label>, the shadow trees may need to be different depending on whether the parent element is a button control (<xforms:trigger>), a text entry control (<xforms:input>), or whatever. In one case, it might be sufficient to do a simple <xbl:content> to the content of the label, but in another case it might be necessary to copy/transform the textual content.

Also, the various textstring-oriented common labels in XForms (<xforms:label>, <xforms:hint>, <xforms:help>) all have the ability to either include text inline or use the 'model' and 'ref' attributes to bind to instance data. A desirable feature in the future would be to reference indirectly through an XForms model item property (with a possible calculation expression) which is then itself bound to the instance data. One way to pull this off would be to offer an XForms-knowledgeable XPath extension function which takes an XPath pointer to one of <xforms:label>, <xforms:hint>, <xforms:help> as a parameter (e.g., xforms-bound-data(xforms:label)). Such a growth path is only possible if XPath syntax is used as the technology foundation today.

trigger > label { binding: url(xforms.xbl#triggerLabel) }
input > label   { binding: url(xforms.xbl#inputLabel) }

hint[ref] { binding: url(xforms.xbl#hintWithRef);  }
hint { binding: url(xforms.xbl#hintWithoutRef);  }

4.3.2 Arguments in favor

Arguments for using a subset of XPath:

• The same arguments for the previous XPath proposal apply here also.
• This proposal's advantage over the previous XPath proposal is that the ability to reference nodes other than immediate children of the bound element would be available in sXBL rather than wait until a future release of XBL, such as XBL 2.0.

4.3.3 Arguments against

• The proposal is complex and inefficient to implement. In cases where scripting or animation might alter the shadow tree within a time-sensitive scenario (e.g., when requiring smooth animation), it is unacceptable if an expensive XPath expression must be computed within a tight loop. XPath is expensive both because it can traverse the entire shadow subtree, or, if full XPath is ever allowed, the entire document. For a correct and robust implementation of SMIL Animation, the insertion points need to be reapplied with each tick of the animation clock. The CSS model is simple enough to allow straightforward programming optimizations; however, XPath applied to the entire shadow tree is much more complex and make such programming optimizations either very difficult or potentially impossible within a compliant implementation of both XBL and SMIL Animation. (Note: SVG supports both XBL and SMIL Animation.)
• All the arguments against the previous XPath proposal apply here as well.

4.4 Proposed compromise: Use only single unqualified tag names

4.4.1 Proposal

A proposed compromise: Use only single unqualified tag names, with matches being determined purely by local name, ignoring namespaces altogether.

4.4.2 Arguments in favour

• This would be trivial to implement, without committing ourselves to either XPath or Selectors, and without closing the door on either option either.

4.4.3 Arguments against

• Arguably not powerful enough.

5 Outside Feedback

Kurt Cagle on 02 Sept 2004 argued for XPath. Here is a snippet:

<xbl:content src="bar[position() % 2 = 0]"/>

Tobias Reif on 02 Sept 2004 said the following:

Nigel McFarlane on 17 Oct 2004 gave lengthy feedback on various sXBL issues. Regarding this issue, here are some snippets:

Elliotte Harold on 06 Dec 2004 said the following: