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

RESOLVED WONTFIX

Status

()

Core
XBL
--
enhancement
RESOLVED WONTFIX
16 years ago
12 years ago

People

(Reporter: Eric Hodel, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
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.

Comment 3

12 years ago
(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.