174614 - XBL does not support full XPath in <children includes="..."/>

Status: RESOLVED WONTFIX

(Core :: XBL, enhancement)

Description

[Eric Hodel]

In the XBL 1.0 Spec:

1.4. The children Element
...
includes
    The includes attribute can be used to indicate that only certain content
should be placed at the insertion point specified by the children element. Its
value is an XPath selector as described in the XPath 1.0 specification. For the
purposes of the evaluation, the bound element is treated as the context node. If
the selector evaluates to anything other than a node set, it is ignored. A child
can only be placed within the insertion point if it is matched by the XPath
selector. Only immediate children are matched against the selector.

The above URL references XBL document:
http://www.segment7.net/mozilla/xbl-sitenavbar/link.xml
which contains the following <content> element in the site-nav-bar bindings

<content>
  <xul:toolbox style="display:block">
    <xul:toolbar style="display:block">
      <children includes="link[@rel='prev']"/>
      <children includes="link[@rel='next']"/>
    </xul:toolbar>
  </xul:toolbox>
</content>

This should create a toolbar like this:
+-----------------------+
| +------+ +------+     |
| | Prev | | Next | ... |
| +------+ +------+     |
+-----------------------+

But instead creates no toolbar, just blank toolbarbuttons sitting by themselves
(not in a toolbox/toolbar).

P.S.:

I'm hoping this gets fixed soon so that the Site Navigation Bar can be fully
XBL-ifiied.  If there is a better way of explicitly ordering bound children by
attribute, I'd like to know about it (other than using
document.getElementsByTagName() and sorting ala the current Site Nav Bar).

Comment 1

[Hixie (not reading bugmail)]

I doubt this'll be fixed anytime soon unless someone steps up and provides a patch.

Comment 2

[Wesley Johnston (:wesj)]

Is there any chance at all of getting this fixed sometime soon? Before XBL2 perhaps? XPath is built into Gecko now, right? Sorry for the bugspam, but it's been a long time since someone looked at this.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #2)
> Is there any chance at all of getting this fixed sometime soon? Before XBL2
> perhaps? XPath is built into Gecko now, right? Sorry for the bugspam, but it's
> been a long time since someone looked at this.
> 

Afaik, XBL2 won't use XPath, but Selectors.
http://www.mozilla.org/projects/xbl/xbl2.html

Comment 4

[Wesley Johnston (:wesj)]

The XBL1 spec says it will support XPath selectors. The XBL2 spec says it will support selectors. In the end, it doesn't matter what they say if its never implemented, does it?

Comment 5

[Martijn Wargers (dead)]

Well, I get the feeling this bug is not useful anymore, and should be turned into a wontfix or invalid one.
I doubt current implementation of xbl in Mozilla will change much.

If/when Mozilla decides to implement xbl2, then on that moment a new bug can be created that describes what needs to be implemented for <children includes=""/> (or whatever it is called in xbl2).