Features/Platform/XBL2
Status
| XBL2 | |
| Stage | Planning |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | ` |
Team
| Product manager | ` |
| Directly Responsible Individual | ` |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | Neil Deakin |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Improve XBL by implementing some or all XBL2 spec features.
2. Users & use cases
`
3. Dependencies
`
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
Broad set of features
Implementation Script
There is a desire to allow scripts to be associated with bindings using a script tag or some equivalent, allowing both inline and scripts from additional files to be used. JavaScript developers will tend to prefer writing all code using functions rather than dividing code up into markup blocks.
Disadvantages of this are the loss of semantics for visual editing, documentation, and the loss of some optimizations that may not be possible without JavaScript implementation knowledge.
The methods added by the script must have a mechanism to allow them to be specified as public methods that can be called externally, and private methods that can only be invoked by the binding itself. There is also a need for a 'package' type of access that allows only bindings declared in the same file access to internal properties. For example, a tab binding script that can access properties of the tabbox, allowing for more optimal implementation.
Shadow Content
Shadow content is not accessible to code outside of the binding. However, there may be a need for a special access mechanism needed for debug only or test only builds. Some manner of read only access could be provided for the use of development and debugging tools.
Content Include Filters
Insertion points are extended in XBL 2 to allow CSS selectors to be used to match elements instead of just tag matching. I'm not convinced that such complexity is necessary, and that matching only on a specific set of criteria is useful.
In addition, some useful match types are not possible with selectors, for example being able to include a specific number of some child, or place children depending on where they would be positioned onscreen, which would be useful for overflow lists, for example.
Inherited Element
The inherited element allows the generated content from a base binding to be inserted in a derived binding, much like a insertion point. This has impact on the existing code as it assumes in some places that only one binding generates content.
Bug 63372 covers this.
Dynamic XBL Documents
The XBL 2 specification implies that the XBL document itself is dynamic and that changes to it cause the generated content of any elements using those bindings are updated as well. This is one of the more complicated ascpects to implement and may limit some optimizations that could be implemented. This is worth investigating further to see whether this feature has any value, as the complexity may not be worth the cost.
Attribute Forwarding
XBL 2 extends the attribute forwarding syntax slightly to allow relative urls to be handled as absolute urls.
While attribute forwarding allows attribute changes on the bound element to be reflected onto a child within the shadow content, it currently isn't possible to listen for changes to the children and have the binding respond accordingly.
Pseudoelements
XBL 2 allows specific elements within the shadow content to match specific CSS selectors. This is a useful feature to allow styling of shadow content without needing knowledge of the internals of the binding, as is needed today. This will simplify theme work.
However, it should be noted that the specification only allows a specific set of six pseudoelements to be used.
Element Lifecycle
Bindings are attached currently using a CSS property. In XBL 2, a binding can also be applied on creation if a processing instruction that points to an XBL file is used. A selector attribute specified on each binding is used to match elements contained within the document to specific bindings.
The disavantage is that bindings can be removed at any time, an issue for the existing XBL implementation as well. Currently, there isn't a means to remove the properties and methods supplied by the implementation. Stability is impacted as an element can suddenly transform into an entirely different one due to a binding change simply by, for example, changing an attribute, or moving the mouse over it (via the hover selector). Also, binding loading is asyncronous so bindings could change if loading takes time.
For the built-in XUL elements, there is the advantage that we can process the bindings beforehand. These should have their bindings applied immediately when the element is created, either via markup parsing or creation by calling createElement. This avoids the common problem that methods are not available until the page is laid out again. Removing the element from a document should not remove the binding.
Ideally, there should be no distinction between a built-in element implemented in XBL and one implemented in C++. Thus, the binding should be hidden from outside users of the binding. For non-built-in bindings this distinction is less important. For these, the binding user knows that the binding exists, so should be able to know whether it is applied or not.
The goal here is remove the usage of CSS attachment from xul.css and use a separate table that maps tags to bindings. Currently, only the tag and type attribute (plus the older style editable and multiline attributes) need be used to identify almost all bindings. Some stylistic bindings may still use selectors, but they shouldn't need any script.
This latter concept is bug 740859
Binding Attachment Events
Add a method which is called when a node containing a binding is attached into a document. Similarly, a method which is called when a node is removed. This allows some initialization and uninitialization, for example, adjusting the selected state of a list when removing a selected item.
Constructors and destructors or equivalent should also be run when the binding is first attached to or removed from the element, as is mostly the case today.
The bug is bug 367400.
Default Phase Handlers
Handlers are extended in XBL 2 to allow them to be used as default handlers for specific events. This would be useful in existing implemented bindings. In addition, it would be useful to allow custom event names to be used so that custom events can be implemented. bug 740861
Binding Objects
DOM objects for XBLImplementation, XBLContentElement, Template elements are to be added. For XBL 2, some methods are altered for the document and element to load binding documents and attach and detach bindings via script. The 2010 spec also adds an object for the binding element and a binding element constructor.
Some of this may be covered by bug 206687.
Accessibility
Currently, accessibility information for bindings is provided by implementing nsIAccessibleProvider. A better way is to provide more details, likely using some additional tags and attributes to the binding of specifying how the binding maps to accessibility features. bug 740863
In addition, XBL doesn't address the need for being able to set default values of specific properties. For example, the default focusability or tab index. This will remove the need for the special -moz-user-focus and similar CSS properties. bug 474440
Native Code
Naturally, XBL 2 doesn't address being able to both invoke native code from script or implement native interfaces from the binding, both of which are needed for existing bindings. The former is currently implemented using box objects. It would be ideal if a portion of an API for a binding could be implemented using C++ for performance or when needing to access low level features not available to script (such as painting and layout information). This would remove the need for box objects.
The second part of this is the ability to implement native interfaces from the binding. This is currently implemented in XBL today and should still be available.
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
