W3C home > Mailing lists > Public > public-appformats@w3.org > October 2006

Re: [XBL] Address Extensibility in XBL 2.0

From: Dean Jackson <dino@w3.org>
Date: Thu, 26 Oct 2006 20:42:53 +1000
Message-Id: <3CC2EB75-9751-41AC-A586-C21A2EF30E4F@w3.org>
Cc: public-appformats@w3.org, Ian Hickson <ian@hixie.ch>
To: Karl Dubost <karl@w3.org>


On 06/10/2006, at 9:06 AM, Ian Hickson wrote:

>
> On Thu, 5 Oct 2006 karl@w3.org wrote:
>>
>> # User agents may support an additional attribute with the name
>> # vendor-binary (e.g. moz-binary="" or khtml-binary="") that contains
>> # information on native code implementations of the binding, if
>> # necessary.
>>
>> This is a clear statement of extensibility providing a mechanism.  
>> Please
>> address it in a specification called "Extensions". Address all XBL
>> requirements with regards to extensibility, specifically when the XBL
>> specification seems to say opposite things.
>
> This is the only extension mechanism allowed. Other extensions  
> would make
> a UA non-conformant. Content that uses the mechanism described  
> above would
> be non-conformant. The only reason this is mentioned at all is to  
> avoid
> two implementations using the same attribute name for that feature.
>
>
>> # For cases where unexpected attributes are found on XBL elements,  
>> or XBL
>> # attributes are found on elements other than those listed as the
>> # "Expected context", the error handling is similar: the  
>> attributes must
>> # be considered to be in error and the UA must ignore them,  
>> meaning that
>> # the presence of unexpected attributes in no way affects the XBL
>> # processing.
>>
>> The user agent may support additionnal attribute which have an  
>> undefined
>> syntax but MUST ignore them at the same time.
>
> No, all unexpected attributes must be ignored. If moz-binary="" is
> supported, it's clearly not unexpected, and therefore wouldn't be  
> ignored.
>
>
> It is unclear exactly what exactly you are asking for; if you could
> suggest some text that would be helpful. The intent of the spec is  
> that no
> extensions to XBL itself be made (though of course other languages  
> could
> be layered on top of XBL, just like XBL is expected to be layered onto
> HTML and SVG documents). Any such extensions would be non- 
> conformant and
> must be ignored, with one exception that is explicitly mentioned.  
> This is
> already explicit in the spec (in the text you quote above, e.g.).

The WG agree with what Ian says above. Karl, could you please respond to
say whether you accept this or not?

Dean, on behalf of the WAF Working Group.
Received on Thursday, 26 October 2006 10:43:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC