- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 23 Nov 2004 00:15:41 -0600
- To: www-svg@w3.org
3.3.1: I'm not sure what "This specification only defines sXBL processing rules or stand-alone SVG documents" means. Should that "or" be a "for"? This specification should define error-handling for cases it does not cover (eg. when the bound element is not in a stand-along SVG document or the binding definition is not in a stand-alone SVG document). Otherwise future expansion of sXBL capabilities is likely to run into non-interoperable handling of what SVG 1.2 UAs would consider error cases. 3.3.2: Again, the error handling behavior for the case when sXBL is applied to SVG elements should be defined. If it's defined elsewhere in the specification, the "in error" text should link to said definition. Henceforth, any comments requesting that the error handling be defined imply that it's acceptable to link to the error handling if it's defined elsewhere. 3.4: "SXBL" (note capital 'S') seems to be a typo. 3.5: The error handling when there is more than one child element in the xblChildNodes and the custom element is the target of a URI reference needs to be defined. The error handling when a resource not in the given list is defined using sXBL custom elements needs to be defined. 3.6: The error handling for the case when xblChildNodes don't satisfy the described criteria (are not all of the same type, are not all vector effect primitives, etc, etc) needs to be defined. The error handling for the case when the animation elements in the xblChildNodes include an xlink:href attribute needs to be defined. 3.11: The error handling for the case when style elements or xml-stylesheet processing instructions are included in the shadow tree needs to be defined. 3.12: Should the "DOM interfaces for custom elements" part be its own subsection? 3.13: The error handling behavior for the situations described in this section needs to be defined. -Boris
Received on Tuesday, 23 November 2004 06:18:23 UTC