- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Wed, 23 Mar 2005 14:56:58 -0800
- To: Peter Sorotokin <psorotok@adobe.com>, Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-svg@w3.org
At 10:45 AM 3/23/2005, Peter Sorotokin wrote: >At 12:30 PM 3/23/2005 -0600, Boris Zbarsky wrote: >>Peter Sorotokin wrote: >>>That would mean >>> - binding must happen before element is ever accessed (e.g at parse >>> time and in createElementNS or similar methods) >>> - bindings cannot be changed through styling >>>That seems to go against the direction of XBL2. We cannot have both >>>well-defined methods and dynamic binding attachment >> >>The thing is, in any sort of reasonable system you can't have objects >>randomly changing which interfaces they implement... The issue of >>binding attachment through styling has been a major weak point of Mozilla >>XBL all along, and causes so many problems that we are strongly >>considering moving to a different, not style-related, binding mechanism >>altogether. > >That's a good data point. This consideration was a primary motivation for >RCC to "bind" solely on the basis of the element name and namespace (which >sXBL retained). I was told that these kind of issues are never really a >problem in practice, but what you are saying indicates otherwise. However, >sXBL is a common activity with CSS group - and I wonder what that the >styling part of the TF would have to say. I agree that we need to have a >clear view on where we are headed in sXBL timeframe. > > >>So while attaching bindings that don't define methods or implement >>interfaces via style is a somewhat reasonable approach, bindings that >>actually implement interfaces probably need to be attached via some other >>mechanism. > >That makes sense to me. But I would expect that the most common scenario will be that XBL widget libraries will define widgets which expose methods and DOM attributes. (And generate events.) If that is indeed the case, then saying "widgets which expose interfaces cannot be bound with CSS" is not a good approach -- it wouldn't be worth the effort. Just extend the sXBL matching which is based on QName to an XPath expression which is evaluated at the time the custom element is added to the document. If the XPath expression matches, then turn the custom element's identity into what the binding defines. Jon >Peter > > >>-Boris
Received on Wednesday, 23 March 2005 23:00:01 UTC