51527 - filter content in XBL via attribute such as ID or class

Status: RESOLVED WONTFIX

(Core :: XBL, enhancement, P3)

Description

[andreww]

right now you can "filter" or "select" content nodes in XBL via in includes 
attribute (I believe).  This selection currently is limited to tagname.  It 
would be really useful to allow selection on ID as well...

And generically, it would be great to include selection via any arbitrary 
attribute like:

includes="id='foo'"
or
includes="width='400px'"

Which is a great goal, but just having selection via ID would be excellent. 

This would allow for things such as rearranging buttons and other content via 
XBL - to accomodate skins which need this.

Comment 1

[Peter Trudelle]

per hyatt, noting xbl1.0 and setting to Future 

Comment 2

[Peter Trudelle]

->moz0.9

Comment 3

[Peter Trudelle]

->future

Comment 4

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 5

[bugzilla.mozilla.org]

from the spec at http://www.mozilla.org/projects/xbl/xbl.html#children

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.

if implemented this would easily allow for things like the mentioned
includes="*[id=foo]" 

Comment 6

[Boris Zbarsky [:bzbarsky]]

Don't we implement some XPath stuff?

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, there's an xpath engine avaliable (as well as XSLT-patterns if that is what
you really want). Right now there is no XPCOM interface exposing the
xpath-engine but there are some internal interfaces that might be usable.

Comment 8

[Peter Van der Beken [:peterv]]

Er, there are the DOM Level 3 XPath XPCOM interfaces
(http://lxr.mozilla.org/seamonkey/source/dom/public/idl/xpath/).

Comment 9

[Jiri TRAVNICEK [:JITR]]

This seems to be a subset of functionality required in bug 174614, which was about full XPath support and was WONTFIXed. Perhaps this bug should be closed in a similar fashion?

Furthermore, XPath support is still being mentioned here:

    https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Anonymous_Content

May I suggest a brief update-fix of the docs (perhaps with a reference to bug 51527 or bug 174614)?

Comment 10

[Jiri TRAVNICEK [:JITR]]

(In reply to Jiri TRAVNICEK, alias JITR from comment #9)

> May I suggest a brief update-fix of the docs (perhaps with a reference to
> bug 51527 or bug 174614)?

Suggestion self-accepted, docs updated:

https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Anonymous_Content$compare?to=627189&from=627161

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, in practice this won't happen. We're investing in a web based solution instead in the form of Web Components.

Comment 12

[Jiri TRAVNICEK [:JITR]]

Thanks for closing this, I have slightly rephrased the previous doc update to better reflect this resolution.