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

Behaviour of custom elements

From: Cameron McCormack <cam-www-svg@aka.mcc.id.au>
Date: Tue, 2 Aug 2005 14:35:51 +1000
To: www-svg@w3.org
Message-ID: <20050802043551.GB25652@port.mcc.id.au>

In the latest (readable) SVG 1.2 full spec, it states:

  Thus, when the custom element is within a rendering context (versus
  non-rendering contexts, such as described under sXBL bindings for SVG
  resources and sXBL bindings for visual effects), then the custom
  element behaves as if it were a g element with no attributes and the
  nodes on xblChildNodes were the children of the g.

I don't think it is clear what is meant by "behaves".  Does this mean
that the bound element implements all the same interfaces as
SVGGElement (SVGElement, SVGTests, SVGLangSpace,
SVGExternalResourcesRequired, SVGStylable and SVGTransformable) and uses
all of the information from these interfaces for rendering?

Presumably the reason that it says it "behaves as if it were a g element
with no attributes" is so that CSS presentation attributes on the bound
element (such as 'font-size') aren't used when computing the CSS values
for shadow tree.  Though this is the rendering behaviour, does this mean
that getting the computed styles with ViewCSS.getComputedStyle on the
bound element also doesn't take these attributes into account?  What
about the other interfaces whose functionality is affected by
attributes, such as with the SVGElement.id attribute: does calling getId
on the bound element actually return the value of the 'id' attribute on
that element, or should it always return null because the element is
behaving as if it were a 'g' element with no properties?  This could be
taken to further extremes, such as returning "g" from the .localName



  e-mail : cam (at) mcc.id.au    	icq : 26955922
     web : http://mcc.id.au/	        msn : cam-msn (at) aka.mcc.id.au
  office : +61399055779		     jabber : heycam (at) jabber.org
Received on Tuesday, 2 August 2005 04:36:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:04 UTC