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

Re: [XBL] Address Extensibility in XBL 2.0

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 5 Oct 2006 23:06:45 +0000 (UTC)
To: karl@w3.org
Cc: public-appformats@w3.org
Message-ID: <Pine.LNX.4.62.0610052259230.19875@dhalsim.dreamhost.com>

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.).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 5 October 2006 23:06:57 UTC

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