W3C home > Mailing lists > Public > www-svg@w3.org > January 2005

SVG12: Interfaces for custom elements

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 14 Jan 2005 19:45:43 +0100
To: www-svg@w3.org
Message-ID: <42020763.171651062@smtp.bjoern.hoehrmann.de>

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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT