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).
I doubt this'll be fixed anytime soon unless someone steps up and provides a patch.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: FreeBSD → All
Hardware: PC → All
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.
(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
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?
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).
Assignee: hyatt → general
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.