Confirmed users
162
edits
XBL:Dynamically Applied Shadow Trees: Difference between revisions
Jump to navigation
Jump to search
m
XBL:Dynamically Applied Shadow Trees (view source)
Revision as of 11:03, 23 March 2006
, 23 March 2006no edit summary
No edit summary |
mNo edit summary |
||
| Line 6: | Line 6: | ||
# The current teardown and rebuilding of the shadow tree whenever a binding is attached or detached means that bindings which modify the shadow tree using script would need to repeat such actions every time the teardown/rebuild process completes. This case may not be uncommon in cases where a language (such as XUL) is implemented with XBL, and author bindings are also used. How would a binding such as the [[XBL:Dynamic Use Cases|2dchart binding]] know when to rebuild its shadow content if external activities such as attaching derived bindings could overwrite its changes? | # The current teardown and rebuilding of the shadow tree whenever a binding is attached or detached means that bindings which modify the shadow tree using script would need to repeat such actions every time the teardown/rebuild process completes. This case may not be uncommon in cases where a language (such as XUL) is implemented with XBL, and author bindings are also used. How would a binding such as the [[XBL:Dynamic Use Cases|2dchart binding]] know when to rebuild its shadow content if external activities such as attaching derived bindings could overwrite its changes? | ||
# Keeping each binding's shadow tree separate allows for significant | # Keeping each binding's shadow tree separate allows for significant implementation optimizations; in particular the shadow tree could be a shared prototype until/unless it was accessed or manipulated via script. This is particularly important in terms of bindings which are part of a language and used frequently, as it has a direct impact on startup time. | ||
implementation optimizations; in particular the shadow tree could be a shared prototype until/unless it was accessed or manipulated via script. This is particularly important in terms of bindings which are part of a language and used frequently, as it has a direct impact on startup time. | |||
== Alternate Proposal == | == Alternate Proposal == | ||
| Line 14: | Line 13: | ||
# The term "shadow tree" and the .shadowTree attribute in the ECMAScript binding refer to the cloned shadow tree of a specific binding only. The term "flattened shadow tree" is used when referring to all the shadow content inserted under a single bound element via binding inheritance. | # The term "shadow tree" and the .shadowTree attribute in the ECMAScript binding refer to the cloned shadow tree of a specific binding only. The term "flattened shadow tree" is used when referring to all the shadow content inserted under a single bound element via binding inheritance. | ||
# The assignment of explicit children to content elements has changed slightly but significantly: instead of performing a treewalk over the flattened shadow tree, explicit children are first assigned to content elements from the "most base" to the most derived binding in order. | # The assignment of explicit children to content elements has changed slightly but significantly: instead of performing a treewalk over the flattened shadow tree, explicit children are first assigned to content elements from the "most base" to the most derived binding in order. | ||