- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 14 Jan 2005 19:45:43 +0100
- To: www-svg@w3.org
Dear Scalable Vector Graphics Working Group, http://www.w3.org/TR/2004/WD-SVG12-20041027/binding.html the section between 3.12 and 3.13 (!) states: [...] All non-SVG elements within an SVG document support the xbl::NodeXBL interface defined in the sXBL specification and also support all of the same interfaces as the g element [...]. This allows, for example, the ability to call method getBBox() on a custom element which has renderable content in its shadow tree. [...] This seems weird in a number of ways. E.g., SVGExternalResourcesRequired does not make much sense on custom elements as externalResourcesRequired would always be the same unless there is a proprietary SVG extension or similar that would correspond to the externalResourcesRequired attribute in some magic way. Please change the specification such that either custom elements do not have interfaces that conforming implementations may implement virtually constant for all custom elements or such that it explains why there are such apparently superfluous interfaces and that implementations must not assume semantics for arbitrary attributes on custom elements, e.g. externalResourcesRequired="true" would not have an impact on element.externalResourcesRequired.baseVal as an implementation cannot know the semantics of the attribute unless it happens to support it as extension in some way. How this is supposed to interact with other interfaces on such elements is not clear to me, for example, the document may include an xhtml:p element and for the element the className property would be of type DOMString and of type SVGAnimatedString which does not seem to work very well. Please change the specification such that such conflicts either do not exist or that it clearly defines how to resolve such conflicts. The interaction of many of these interfaces with custom elements does not seem to be well-defined either, especially when there is no sXBL processing involved. A simple example would be the id attribute, the specification states "value of the id attribute on the given element" where "id" links to section 5.10.1 of SVG 1.1 which states 'Standard XML attribute for assigning a unique name to an element. Refer to the "Extensible Markup Language (XML) 1.0" Recommendation [XML10]' which does not make much sense to me. Can the property be used to refer to attributes named "id" which are not "standard XML attributes"? Or could it be used to refer to an attribute with type ID which is not named "id" on the custom element? Please change the specification such that processing in such cases is well-defined, especially if the document uses custom elements but no sXBL. The last sentence of the cited section does not make much sense to me either, the term "renderable content" seems undefined and whether this is an informative statement or normative in some way is not clear to me. Per the first part of the section one can use getBBox() regardless of whether the element "has renderable content in its shadow tree" so this statement seems superfluous. Please change the specification such that it is obvious what you mean here. regards. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Friday, 14 January 2005 18:45:38 UTC