W3C home > Mailing lists > Public > www-svg@w3.org > March 2005

Re: sXBL issue -- bindings getting notified when the bound element is inserted into a document

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
Message-id: <6.1.1.1.2.20050323142757.022a5e58@mailsj-v1.corp.adobe.com>

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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT