Talk:XUL Overlays

From MDC

[edit] Why Overlays Instead of Fragments?

This is a section of the original document, which is only interesting from historical perspective, so I'm moving it from the main article to the talk page. --Nickolay 09:03, 27 November 2005 (PST)

• XML is developing a much more complete fragment inclusion standard that XUL fragments were competing with. Rather than develop a non-standard fragment system, I decided it was better to wait until the standard develops and to implement that in a general way (so that it doesn't just apply to XUL) when it's ready to go. It is not ready to go now.
• There are ambiguities related to style sheets and scripts in fragments. A style sheet loaded by a fragment should presumably only apply to the fragment. It's undefined right now. There is no such scoping mechanism.
• Including the same fragment more than once in the same file can cause problems. This leads to the idea of needing a fragment cache in order to prevent multiple parses of the fragment.
• XUL fragments were being used in a way they weren't designed for. There was a tension emerging regarding trying to make the fragments function as everything from templates for building UI to a mechanism for UI reuse to a system for defining implementations.
• People wanted asynchronous XUL fragments that could stream in at a later date. This still isn't possible because of bugs in the form elements, bugs in the table code, bugs in the box code, and bugs in the menu code. So it seemed unrealistic to continue trying to make a system that works this way.