On 06/10/2006, at 9:06 AM, Ian Hickson wrote:
On Thu, 5 Oct 2006 [EMAIL PROTECTED] 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.
